GPE handler livelock

[Alexey Starikovskiy]

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 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
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: defer_enabling_of_level_gpe.patch
Type: text/x-patch
Size: 3886 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-acpi/attachments/20080107/1e068191/defer_enabling_of_level_gpe.bin