Wakeup races, PCI, and ACPI

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux IBM ACPI]     [Linux Power Management]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux