Date: Wed, 3 Oct 2007 12:50:59 -0400 From: Jung-uk Kim <jkim@FreeBSD.org> To: freebsd-acpi@FreeBSD.org Cc: freebsd-current@FreeBSD.org Subject: Re: patch: change in acpi taskq behavior Message-ID: <200710031251.02304.jkim@FreeBSD.org> In-Reply-To: <4703C08B.6040703@gmail.com> References: <470002B5.6030002@root.org> <4703BD8D.1080501@root.org> <4703C08B.6040703@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200710031251.02304.jkim>