GPE handler livelock
Alexey Starikovskiy
astarikovskiy at suse.de
Mon Jan 7 11:03:55 PST 2008
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 at root.org]
>> Sent: Monday, January 07, 2008 10:09 AM
>> To: Moore, Robert
>> Cc: Yousif Hassan; freebsd-acpi at 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 at freebsd.org [mailto:owner-freebsd-
>>>> acpi at freebsd.org] On Behalf Of Yousif Hassan
>>>> Sent: Sunday, January 06, 2008 12:18 PM
>>>> To: Nate Lawson
>>>> Cc: freebsd-acpi at 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 at freebsd.org mailing list
>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
>>>> To unsubscribe, send any mail to
> "freebsd-acpi-unsubscribe at freebsd.org"
>> --
>> Nate
More information about the freebsd-acpi
mailing list