From owner-freebsd-acpi@FreeBSD.ORG Mon Jan 7 21:39:20 2008 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED61116A419 for ; Mon, 7 Jan 2008 21:39:19 +0000 (UTC) (envelope-from nate@root.org) Received: from root.org (root.org [67.118.192.226]) by mx1.freebsd.org (Postfix) with ESMTP id B31BE13C457 for ; Mon, 7 Jan 2008 21:39:19 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 20739 invoked from network); 7 Jan 2008 21:39:20 -0000 Received: from adsl-76-200-162-190.dsl.pltn13.sbcglobal.net (HELO ?192.168.1.84?) (nate-mail@76.200.162.190) by root.org with ESMTPA; 7 Jan 2008 21:39:20 -0000 Message-ID: <47829C03.3010802@root.org> Date: Mon, 07 Jan 2008 13:39:15 -0800 From: Nate Lawson User-Agent: Thunderbird 2.0.0.9 (X11/20071122) MIME-Version: 1.0 To: Alexey Starikovskiy References: <200712311556.lBVFuVZf030567@freefall.freebsd.org><477916E0.2090702@root.org><200712311243.18123.jhb@freebsd.org> <47802510.3040203@root.org> <47826AAA.6040101@root.org> <47827291.60405@suse.de> <478272C3.5080704@suse.de> In-Reply-To: <478272C3.5080704@suse.de> X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org, "Moore, Robert" Subject: Re: GPE handler livelock X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2008 21:39:20 -0000 Alex, I had one question about your approach. It maintains two single-thread task queues (kacpid and kacpi_notify). It inserts each type of event on its own queue. So there is no strict ordering of handling notifies in priority to other acpi tasks unless you're assuming something about the linux task priority model. Do you have any expectation that notify tasks run before other tasks (perhaps by a special priority assigned to the kacpi_notify work queue)? In FreeBSD, we have a single task queue. However, we prioritize events in the queue in the following order (highest to lowest priority): * GPE * EC/global lock * Notify * Debugger If an event is inserted on the queue with a higher priority and a previous event has not started executing yet, this priority determines the order of insertion. Thus if GPEs keep arriving, the Notify won't be executed until they're done. Thanks, Nate Alexey Starikovskiy wrote: > Here is the patch... > Alexey Starikovskiy wrote: >> I proposed this patch some time ago, it moves _Lxx enabling to the end >> of Notify queue, thus all notifies must complete before event becomes >> enabled again. >> Hope it is readable to non-Linux people... >> >> Regards, >> Alex. >> >> Moore, Robert wrote: >>> No changes that I know of before 20070508. >>> >>> You'll need to figure out why you are getting another GPE before the >>> _Lxx method completes. There was something like this on Linux with an HP >>> machine, perhaps Alexey can help. >>> >>> As I recall, there was something nasty happening where the TZ trip >>> points had to be reset before the Notify() handler completed, but this >>> ended up causing another GPE, etc. etc. >>> >>> Bob >>> >>> >>>> -----Original Message----- >>>> From: Nate Lawson [mailto:nate@root.org] >>>> Sent: Monday, January 07, 2008 10:09 AM >>>> To: Moore, Robert >>>> Cc: Yousif Hassan; freebsd-acpi@FreeBSD.org >>>> Subject: Re: GPE handler livelock >>>> >>>> Bob, thanks for the reply. That's exactly what my investigation is >>>> showing also. It appears we're still on 20070320 so I'm not sure why >>>> this would affect us though. Perhaps a similar change was already >>>> present? In any case, we should see if an import fixes this. >>>> >>>> Thanks, >>>> Nate >>>> >>>> Moore, Robert wrote: >>>>> This sounds suspiciously like the changes we made to the Notify() >>>>> handling last year. We attempted to make the notify handler run >>>>> synchronously with the caller to Notify(), but this created more >>>>> problems than it solved. We ended up returning the behavior of Notify >>>>> handlers to be asynchronous: >>>>> >>>>> >>>>> >>>>> 19 October 2007. Summary of changes for version 20071019: >>>>> >>>>> 1) ACPI CA Core Subsystem: >>>>> >>>>> Reverted a change to Notify handling that was introduced in version >>>>> 20070508. This version changed the Notify handling from asynchronous >>> to >>>>> fully synchronous (Device driver Notify handling with respect to the >>>>> Notify >>>>> ASL operator). It was found that this change caused more problems >>> than >>>>> it >>>>> solved and was removed by most users. >>>>> >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: owner-freebsd-acpi@freebsd.org [mailto:owner-freebsd- >>>>>> acpi@freebsd.org] On Behalf Of Yousif Hassan >>>>>> Sent: Sunday, January 06, 2008 12:18 PM >>>>>> To: Nate Lawson >>>>>> Cc: freebsd-acpi@FreeBSD.org >>>>>> Subject: Re: GPE handler livelock >>>>>> >>>>>> Nate wrote: >>>>>>> Thanks for digging into this. I reviewed this and am trying to >>>>> figure >>>>>>> out why the _L00 handler never completes. It keeps getting >>> preempted >>>>> by >>>>>>> the next one. To help track this down, try removing these two >>> lines >>>>>>> from the _L00 method and recompile your ASL: >>>>>>> >>>>>>> Acquire (\_TZ.C173, 0xFFFF) >>>>>>> ... >>>>>>> Release (\_TZ.C173) >>>>>>> >>>>>>> For others who have this problem, instructions on how to recompile >>>>> and >>>>>>> load your custom ASL can be found here (11.16.4 and 5): >>>>>>> >>> http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/acpi-debug.htm >>>>> l