panic in AcpiExReleaseMutex

[Andriy Gapon]

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