linux-kernel - Re: [patch 61/66] timers: Convert to hotplug state machine

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 26 Jul 2016 19:20:11 +0100
From:	Jon Hunter <jonathanh@...dia.com>
To:	Thomas Gleixner <tglx@...utronix.de>
CC:	<rcochran@...utronix.de>,
	Anna-Maria Gleixner <anna-maria@...utronix.de>,
	LKML <linux-kernel@...r.kernel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...nel.org>,
	Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
	"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>
Subject: Re: [patch 61/66] timers: Convert to hotplug state machine

Hi Thomas,

On 26/07/16 15:15, Thomas Gleixner wrote:
> Jon,
> 
> On Tue, 26 Jul 2016, Jon Hunter wrote:
>> On 25/07/16 16:35, rcochran@...utronix.de wrote:
>>> Just to be sure, this problem didn't exist before the HP rework, that
>>> is, suspend worked fine with and without CONFIG_PREEMPT, right?
>>
>> Correct. I test suspend on Tegra with both multi_v7_defconfig
>> (CONFIG_PREEMPT disabled) and tegra_defconfig (CONFIG_PREEMPT enabled).
>> Looking at the git history for these configs I don't see any changes in
>> this regard since they were added (unless some underlying Kconfig files
>> have changed).
> 
> Is that fully reproducible, i.e on every suspend?

No not every suspend. I run 10 suspend cycles on each Tegra board (5
boards total) and typically between 3 and 5 boards would see the stall
in the 10 suspend cycles. So it does appear to be timing sensitive.

> Can you please check whether this issue happens with just cpu offline as
> well? I.e. set a cpu (or all non-boot cpus) offline, wait long enough that the
> stall detector can trigger, set the cpu(s) online again and repeat.

I can, but it appears like Richard's patch has fixed this. I am happy to
do more testing if necessary.

Cheers
Jon

-- 
nvpublic