Date: Wed, 03 Oct 2007 09:17:15 -0700 From: "Dana H. Myers" <dana.myers@gmail.com> To: Nate Lawson <nate@root.org> Cc: freebsd-acpi@FreeBSD.org, freebsd-current@FreeBSD.org, Jung-uk Kim <jkim@FreeBSD.org> Subject: Re: patch: change in acpi taskq behavior Message-ID: <4703C08B.6040703@gmail.com> In-Reply-To: <4703BD8D.1080501@root.org> References: <470002B5.6030002@root.org> <200710031138.28820.jkim@FreeBSD.org> <4703BD8D.1080501@root.org>
index | next in thread | previous in thread | raw e-mail
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. Danahome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4703C08B.6040703>