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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4703C08B.6040703>