On Wednesday, 2 of January 2008, Ingo Molnar wrote: > > * Rafael J. Wysocki <rjw@xxxxxxx> wrote: > > > Hi, > > > > Some device drivers register CPU hotplug notifiers and use them to > > destroy device objects when removing the corresponding CPUs and to > > create these objects when adding the CPUs back. > > > > Unfortunately, this is not the right thing to do during > > suspend/hibernation, since in that cases the CPU hotplug notifiers are > > called after suspending devices and before resuming them, so the > > operations in question are carried out on the objects representing > > suspended devices which shouldn't be unregistered behing the PM core's > > back. Although right now it usually doesn't lead to any practical > > complications, it will predictably deadlock if > > gregkh-driver-pm-acquire-device-locks-prior-to-suspending.patch is > > applied. > > > > The solution is to prevent drivers from removing/adding devices from > > within CPU hotplug notifiers during suspend/hibernation using the > > FROZEN bit in the notifier's action argument. However, this has to be > > done with care, since the devices objects related to the nonboot CPUs > > that failed to go online during resume should not be present in the > > system. For this reason, it seems reasonable to introduce a mechanism > > allowing drivers to ask the PM core to remove device objects > > corresponding to suspended devices on their behalf. > > > > The first patch in the series introduces such a mechanism. The > > remaining three patches modify the MSR, x86-64 MCE and cpuid drivers > > in accordance with the above approach. > > btw., it would be really, really cool if there was a scriptable way i > could test suspend/resume functionality. First, there are patches queued for 2.6.25 that allow you to test various phases of suspend (specifically, patches 09-11 in the series at http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.24-rc6/patches/). With these patches applied you can do something like: # echo core > /sys/power/pm_test # echo mem > /sys/power/state and it will run the suspend code up to, but not including, entering the sleep state (it will busy wait for 5 sec. instead). Then, it will run the resume code. There are 6 testing levels available, documented in patch 11 and in the changelogs. Second, there's the rtc wakealarm thing that can be used to test the real suspend. > Pavel has this /dev/rtc thing to set up an alarm (not sure how functional it > is) - would it be possible to have it as a "suspend for 10 seconds then > resume" debug functionality? Well, we have the following test script in the userland suspend package that is supposed to work right now: #!/bin/bash date cd /sys/class/rtc/rtc0 echo $(( $(cat since_epoch) + 20 )) > wakealarm s2ram date provided that the new rtc driver code is compiled (and the old one is not). > That way any suspend breakage would be detectable (and bisectable) in > automated testing - if the resume does not come back after 10-20 seconds then > the test failed. Yes, but please note that some systems require user space manipulations of the graphics adapter for suspend to work and to detect a breakage of such a system you need to boot it into X and use s2ram to suspend. Greetings, Rafael - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
