Rafael: I see that the kacpi_notify_wq thread isn't freezable. This means we are subject to a race during system sleep transitions. If a PCI device is already runtime-suspended, then a PME# wakeup request could cause kacpi_notify_wq to attempt a runtime resume at the same time as the regular suspend or freeze method is running. (The same is true for non-PCI devices and ACPI-platform-specific wakeup requests.) Can kacpi_notify_wq be made freezable? (Are ACPI wakeup notifications handled by any other workqueues?) If not, should it call pm_request_resume() instead of pm_runtime_resume()? Also, can this be handled in a way that doesn't end up losing wakeup events? For quite some time, I've been thinking that any attempt to add a resume action to the pm workqueue should abort an ongoing system sleep, if device_may_wakeup() is true for the device in question. Alan Stern -- 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
