* 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. 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? 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. Ingo - 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
