Re: patch: change in acpi taskq behavior

From: Dana H. Myers <dana.myers_at_gmail.com>
Date: Wed, 03 Oct 2007 09:17:15 -0700
Nate Lawson wrote:

> 1. Run a task at some point in the future but "soon"
> 2. Queue a task to be run, definitely after boot is complete
> 
> Notifies are in the first class.  Initialization functions for the
> various drivers are in the second.  ACPI-CA is moving to making all
> Notifies completely synchronous (i.e. they wait for the thread to run).

Note that I've encountered an issue with synchronous Notify in the
Solaris port of ACPI CA on a particular machine.

Specifically, the Acer Ferrari 3400 deadlocks while delivering
AC/battery events, since Notify() is performed while holding
a mutex.  The AC/battery driver notify handler evaluates _STA
and _BST, and either of these attempt to hold the same mutex.

Bob Moore and I have been discussing solutions for this but
have nothing firm at this point.

While I suppose I *could* make the AC/battery driver Notify
handler behave like a high-level interrupt and simply schedule
yet another thread to run to handle the Notify, this scheme
generally ends up the same as asynchronous Notify in the first
place.

Dana
Received on Wed Oct 03 2007 - 14:42:23 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:18 UTC