On Wed, Jul 06, 2005 at 04:38:45PM +0800, Shaohua Li wrote: > On Wed, 2005-07-06 at 12:20 +1000, Nigel Cunningham wrote: > > diff -ruNp 350-workthreads.patch-old/drivers/acpi/osl.c > > 350-workthreads.patch-new/drivers/acpi/osl.c > > --- 350-workthreads.patch-old/drivers/acpi/osl.c 2005-06-20 > > 11:46:50.000000000 +1000 > > +++ 350-workthreads.patch-new/drivers/acpi/osl.c 2005-07-04 > > 23:14:18.000000000 +1000 > > @@ -95,7 +95,7 @@ acpi_os_initialize1(void) > > return AE_NULL_ENTRY; > > } > > #endif > > - kacpid_wq = create_singlethread_workqueue("kacpid"); > > + kacpid_wq = create_singlethread_workqueue("kacpid", PF_NOFREEZE); > > BUG_ON(!kacpid_wq); > > I'm not sure but kacpid can run any kind of code (depends on BIOS, it > might touch some devices), is this safe?
FYI, the reason it's there is to do something about acpi events whilst resuming. If kacpid is not running the following bug occurs: - during suspend, prior to the atomic copy, a GPE fires (eg, a battery notification) - the GPE is disabled until it is serviced by kacpid, but as kacpid is not running, it isn't serviced - only disabled. - the disabled state of the GPE is recorded in the atomic copy, and written to disk - poweroff/S4 - on resume, ACPI initialises the GPEs and enables them all. - after the restoring the atomic copy, the GPE may fire. However, the kernel thinks it is already disabled and so refuses to disable it again. - this sends the machine into an interrupt-induced death as the GPE fires over and over and over ... I prepared a patch a while ago that simply omitted the check and disabled the GPE unconditionally (which was how things were before the big ACPI merge of 2.6.9), but this made the battery status unreadable for at least one user. I never followed that up, but instead some more general GPE suspend/resume handling was discussed, making GPEs system devices that were suspended and resumed accordingly. I don't think any code eventuated from this discussion though ... Letting kacpid run during suspend appeared to be a good compromise (but still racy if GPEs were to occur at exactly the right instant - just before the atomic copy). Implementing suspend/resume support for GPEs would be the more ideal solution. Bernard. -- Bernard Blackham <bernard at blackham dot com dot au> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/