panic in AcpiExReleaseMutex

[Andriy Gapon]

We are trying to resolve an issue reported in the following FreeBSD PR:
http://www.freebsd.org/cgi/query-pr.cgi?pr=140979

There is some additional information in:
http://people.freebsd.org/~avg/pr140979/

This is 8-stable, so ACPICA version is 20090521.

It looks like a NULL-pointer issue in AcpiExReleaseMutex.
The reported line where the trap happens is the following:

    PreviousSyncLevel =
        WalkState->Thread->AcquiredMutexList->Mutex.OriginalSyncLevel;

Fault address is 0x40 which is exactly an offset of OriginalSyncLevel within
ACPI_OBJECT_MUTEX on amd64 platform.

My understanding of the stacktrace on the pictures is the following.
>From EC driver we call AcpiInstallAddressSpaceHandler to install EcSpaceHandler
function for ACPI_ADR_SPACE_EC.  As I understand, that leads to execution of
_REG method of EC device.  _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.  Apparently, in our case that code path was taken and we got the
NULL-pointer problem while evaluating AML Release function in either _Q20 or
_Q09.  Both of them acquire and release the already mentioned
\_SB.PCI0.LPC0.EC0.MUT1 Mutex.

Does my interpretation sound correct?
Does this scenario ring any bells?
Does our EC driver do everything correct?

I am somewhat suspicious of recursive use of \_SB.PCI0.LPC0.EC0.MUT1 in this
situation.  But I am not sure if it's an issue with AML or with our code.

-- 
Andriy Gapon