panic in AcpiExReleaseMutex

[Moore, Robert]

>Yes.  EC querying is performed under global lock.  That is, it gets locked
>and
>unlocked in EcGpeQueryHandler function before _Qxx evaluation.
>I am actually curious why you asked this question.

Global lock has it's own internal mutex.

    /* Release the global lock */

    Status = AcpiExReleaseMutexObject (AcpiGbl_GlobalLockMutex);

Do you know if the failure in ReleaseMutex is during a release of the MUT1 mutex, or could it possibly be the global lock?

 

>-----Original Message-----
>From: Andriy Gapon [mailto:avg at icyb.net.ua]
>Sent: Friday, December 04, 2009 1:38 PM
>To: Moore, Robert
>Cc: freebsd-acpi at freebsd.org; Tarick
>Subject: Re: panic in AcpiExReleaseMutex
>
>on 04/12/2009 23:24 Moore, Robert said the following:
>>> This  thread has a fixed tid of 100000.
>>
>> This is ok.
>>
>> Well, I don't see anything obvious. You will probably need to step
>through
>> the calls to AcpiExAcquireMutex and AcpiExReleaseMutex, or at least add
>some
>> printfs to monitor the value of WalkState->Thread->AcquiredMutexList.
>
>I see.
>
>> Another question, however: is the global lock involved in any way?
>
>Yes.  EC querying is performed under global lock.  That is, it gets locked
>and
>unlocked in EcGpeQueryHandler function before _Qxx evaluation.
>I am actually curious why you asked this question.
>
>Thank you!
>
>>> -----Original Message----- From: Andriy Gapon [mailto:avg at icyb.net.ua]
>>> Sent: Friday, December 04, 2009 1:20 PM To: Moore, Robert Cc:
>>> freebsd-acpi at freebsd.org; Tarick Subject: Re: panic in
>AcpiExReleaseMutex
>>>
>>> on 04/12/2009 22:59 Moore, Robert said the following:
>>>> It would appear that a GPE is taken, for the EC device, thus invoking
>>>> EcGpeQueryHandler. In what context is _Q20 or _Q09 executed?
>>> It's invoked in "polling mode" at that stage.  Interrupts are not
>enabled
>>> yet at that point.  Let me quote my original report: [quote] _REG method
>>> seems to access some registers in EC address space (with
>>> \_SB.PCI0.LPC0.EC0.MUT1 mutex locked).  That access triggers a call to
>>> EcSpaceHandler.  Now, we have a code in EcSpaceHandler that makes a
>direct
>>> call to EcGpeQueryHandler during a cold boot phase if SCI bit is set in
>CSR
>>>  register. EcGpeQueryHandler performs an EC query and executes _Qxx
>method
>>> if need. [/quote]
>>>
>>> So, everything happens in the same thread with the same context and
>stack.
>>>
>>>> This might be an important question: What is the thread_id of this
>>> initial
>>>> thread?
>>> This  thread has a fixed tid of 100000.
>>>
>>>>> -----Original Message----- From: Andriy Gapon [mailto:avg at icyb.net.ua]
>>>>> Sent: Friday, December 04, 2009 12:50 PM To: Moore, Robert Cc:
>>>>> freebsd-acpi at freebsd.org; Tarick Subject: Re: panic in
>>> AcpiExReleaseMutex
>>>>> on 04/12/2009 20:45 Moore, Robert said the following:
>>>>>> Yes, you are correct. I did not have the code in front of me at the
>>> time.
>>>>>>
>>>>>>
>>>>>>
>>>>>> When AcpiExReleaseMutex is called, apparently the mutex is in fact
>>> held,
>>>>>> otherwise the function would have aborted immediately.
>>>>>>
>>>>>> When the mutex is held, the Thread->AcquiredMutexList is expected to
>>> hold
>>>>>>
>>>>>>
>>>>> (at
>>>>>> the minimum) the mutex object being released. Something is very wrong
>>>>>>
>>> if
>>>>> this
>>>>>> list is NULL when releasing the mutex.
>>>>>>
>>>>>> Just to make sure: All of this is happening in the same thread?
>>>>> Yes, this happens when there is only the initial thread running on
>BSP,
>>>>>
>>> no
>>>>> other threads are started yet.
>>>>>
>>>>>
>>>>> -- Andriy Gapon
>>>
>>> -- Andriy Gapon
>
>
>--
>Andriy Gapon