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
> 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
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 http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/