Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 7 Jan 2008 10:34:30 -0800
From:      "Moore, Robert" <robert.moore@intel.com>
To:        "Nate Lawson" <nate@root.org>, "Alexey Starikovskiy" <astarikovskiy@suse.de>
Cc:        freebsd-acpi@FreeBSD.org
Subject:   RE: GPE handler livelock
Message-ID:  <B28E9812BAF6E2498B7EC5C427F293A403F6087A@orsmsx415.amr.corp.intel.com>
In-Reply-To: <47826AAA.6040101@root.org>
References:  <200712311556.lBVFuVZf030567@freefall.freebsd.org><477916E0.2090702@root.org><200712311243.18123.jhb@freebsd.org> <47802510.3040203@root.org> <B2D86EF24E7E4BEF90BA00C945189463@kamino> <B28E9812BAF6E2498B7EC5C427F293A403F607B4@orsmsx415.amr.corp.intel.com> <47826AAA.6040101@root.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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
>>> I'm not sure if my situation is exactly what you're referring to in
>>> this note, but since my laptop is also an HP (nx6110), and since it
>> also
>>> hangs during thermal zone changes, I tried your suggestion.  It
didn't
>>> help, unfortunately.  I still get mutex problems when the thermal
zone
>>> increases.  My ASL did not have precisely the Acquire call you
listed,
>>> but it did have a similar one in method _L00 called
>>> Acquire (\_TZ.C170, 0xFFFF) and Release (\_TZ.C170).  Also this pair
>>> of calls was also found in one other place (further down) in the
ASL.
>>> I only removed the first pair in the method you instructed.
>>> FWIW, here are the debug error messages when the machine hangs:
>>>
>>> ACPI Exception (utmutex-0376): AE_TIME, Thread 28 could not acquire
>> Mutex
>>> [0] [20070320]
>>> ACPI Error (exutils-0180): Could not acquire AML Interpreter mutex
>>> [20070320]
>>> ACPI Error (utmutex-0421): Mutex [0] is not acquired, cannot release
>>> [20070320]
>>> ACPI Error (exutils-0250): Could not release AML Interpreter mutex
>>> [20070320]
>>> ACPI Exception (utmutex-0376): AE_TIME, Thread 28 could not acquire
>> Mutex
>>> [0] [20070320]
>>> ACPI Error (exutils-0180): Could not acquire AML Interpreter mutex
>>> [20070320]
>>> ACPI Error (psparse-0626): Method parse/execution failed
[\_TZ_.C242]
>> (Node
>>> 0xc321c220), AE_TIME
>>> ACPI Error (psparse-0626): Method parse/execution failed
>> [\_TZ_.TZ1_._TMP]
>>> (Node 0xc321b9c0), AE_TIME
>>> ... etc ...
>>>
>>> I put more info into PR 79080.
>>>
>>> Let me know if you want me to try anything else.
>>> --Yousif
>>>
>>> _______________________________________________
>>> freebsd-acpi@freebsd.org mailing list
>>> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
>>> To unsubscribe, send any mail to
"freebsd-acpi-unsubscribe@freebsd.org"
>
>--
>Nate



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B28E9812BAF6E2498B7EC5C427F293A403F6087A>