Re: patch: change in acpi taskq behavior

On Wednesday 03 October 2007 12:17 pm, Dana H. Myers wrote:
> 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.

Ha, my laptop at work is Acer Ferrari 3400. :-)

> 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.

Precisely.

Jung-uk Kim