From owner-freebsd-acpi@FreeBSD.ORG Mon Jan 7 21:57:57 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 81CA416A419 for ; Mon, 7 Jan 2008 21:57:57 +0000 (UTC) (envelope-from astarikovskiy@suse.de) Received: from emea5-mh.id5.novell.com (charybdis-ext.suse.de [195.135.221.2]) by mx1.freebsd.org (Postfix) with ESMTP id AF2E613C457 for ; Mon, 7 Jan 2008 21:57:56 +0000 (UTC) (envelope-from astarikovskiy@suse.de) Received: from [192.168.101.12] ([149.44.162.75]) by emea5-mh.id5.novell.com with ESMTP; Mon, 07 Jan 2008 22:57:53 +0100 Message-ID: <4782A051.3050107@suse.de> Date: Tue, 08 Jan 2008 00:57:37 +0300 From: Alexey Starikovskiy User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Nate Lawson 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> <47829C03.3010802@root.org> In-Reply-To: <47829C03.3010802@root.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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:57:57 -0000 Nate, There are no debugger events in Linux, and all other deferred execution happens in kacpid (GPE, EC and GL included). Notify events used to be executed on this same queue until we noticed deadlocks with HP machines. All events are not prioritized in any way -- it is a simple FIFO. To avoid deadlock, we moved notify events to separate queue, but it had a drawback of enabling level GPE too early, thus I inserted a reschedule call to each completion on first queue, giving the notify queue chance to complete. Later, I was reminded that this approach is not bulletproof, so enabling of the level events was moved to notify queue as well. As it happens after all notify events for the gpe event were called, (but, probably, not executed), enabling of GPE will be deferred until these notify events have chance to complete. So, essentially, we had no priority for any event, but now notify event could preempt execution of any other event, and level GPE event does a flush of notify queue. Hope this helps, Alex. Nate Lawson wrote: > 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 >