patch: change in acpi taskq behavior

[Dana H. Myers]

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