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? Bjørn -- To unsubscribe from this list: send the line "unsubscribe cpufreq" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
