On 6 January 2014 16:47, Bjørn Mork <bjorn@xxxxxxx> wrote: > Viresh Kumar <viresh.kumar@xxxxxxxxxx> writes: > >> On 6 January 2014 16:19, Bjørn Mork <bjorn@xxxxxxx> wrote: >>> I cancelled by pressing backspace while the image was being written. >> >> I will answer other queries on next mail, but a quick question: >> Do you get these warnings even if you don't cancel hibernation? > > Yes. Hmm.. I see. Now, I really don't believe that you wouldn't get these warnings on a suspend/resume but only on hibernation. > I believe the photo shows that you are right: This warning happens when > the failure path is entered, even if both the hibernation and following > resume is successful. We see __cpufreq_add_dev calling > cpufreq_policy_put_kobj here as well. @Rafael: I need your expert opinion here, I am not so good with these concepts :) Here is my theory about these warnings: - Bjorn gets these only when CONFIG_PROVE_LOCKING=y. - This feature enables the kernel to report locking related deadlocks before they actually occur. (lib/Kconfig.debug) - So, no locking issue has happened here but its just an warning that you might end up getting into such issue later. - Contention is between sysfs and cpu-hotplug lock. - While changing stuff from sysfs we do this: sysfs-lock (by kernel) cpu-hotplug lock (by cpufreq) - And while doing hibernation if add_dev fails then we do this cpu-hotplug lock (by kernel while adding CPUs) sysfs-lock (by cpufreq while removing sysfs directories) And kernel is recording all these sequences all the time. Because we first tried changing values from sysfs, kernel recorded that sequence. And as soon as it found another one it WARNed us? While on a suspend/resume, we will get into add-dev failure only in resume and probably by that time these recordings are refreshed? And that's why Bjorn isn't facing any issue there ? Just an wild guess. And if all above "virtual" theory is correct, then I don't know if we can/want to fix that.. > Thinking about this: This failure will always happen, regardless of > cancelling or not, won't it? Yeah. > But it happens *after* the freeze so it > doesn't matter if we resume from the frozen image. yeah.. So, even tests like this should give you this warning: Documentation/power/basic-pm-debugging.txt core - test the freezing of processes, suspending of devices, platform global control methods(*), the disabling of nonboot CPUs and suspending of platform/system devices > So you are probably right as usual: Really? Ask Rafael, he doesn't agree :) > This warning is related to the > acpi-cpufreq driver failing, and you cannot reproduce it without > simulating such a failure (or using that driver yourself). Which means > that the warning disappears with my patch in > http://www.spinics.net/lists/cpufreq/msg08714.html > which explains why I don't normally see it. I depend on being able to > cancel hibernation, so I use that patch most of the time. Except when > I'm testing one of your branches. Correct. -- 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
