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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |