Re: [PATCH 1/2] cpufreq: try to resume policies which failed on last resume

From: BjÃrn Mork
Date: Fri Jan 03 2014 - 06:55:48 EST

Viresh Kumar <viresh.kumar@xxxxxxxxxx> writes:

> On 3 January 2014 15:23, BjÃrn Mork <bjorn@xxxxxxx> wrote:
>> Note that "ondemand" and "1401000" are the default vaules, so I don't
>> actually change anything here. The write is causing the problem, not
>> the value. As expected, I guess.
>> Also note that boot vs non-boot cpu doesn't seem to matter. Nor does
>> cancelling the hibernation. The warning appears on hibernate - not on
>> resume.
> Hmm... I spent quite some time understanding whats going on and really
> couldn't get across anything as of now. I haven't tried reproducing it though.
> Few things that I can make out of this mail chain so far:
> - Apart from the log, everything is working fine. i.e. system is back in
> working condition.

Correct. And users not running a lock debugging kernel will of course
not even see the warning.

> - It only happens when cpufreq_add_dev() fails during hibernation while
> we enable non-boot CPUs again to save image to disk. So, isn't a problem
> for a system which doesn't have any issues with add_dev() failing on
> hibernation

Wrong. This was my initial assumption but I later found out that the
issue is unrelated to hibernation failures. Sorry about the confusion.

> - There is a contention of locks in the order they are taken. And the contention
> looks to be between, hotplug lock taken by cpu_online_cpus() and s_active
> lock for sysfs files. Don't know what's the role of previous write to
> sysfs files.
> As that should finish before hibernation starts and so all locks should be back
> in place.

Yes, that seems logical. But I guess this is where it fails?

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at