From owner-freebsd-acpi@FreeBSD.ORG Thu Dec 3 09:24:08 2009 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 27F691065672 for ; Thu, 3 Dec 2009 09:24:08 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id D30098FC16 for ; Thu, 3 Dec 2009 09:24:06 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA19226; Thu, 03 Dec 2009 11:24:04 +0200 (EET) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1NG7uu-000Emt-F9; Thu, 03 Dec 2009 11:24:04 +0200 Message-ID: <4B178387.4050601@icyb.net.ua> Date: Thu, 03 Dec 2009 11:23:19 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20091128) MIME-Version: 1.0 To: freebsd-acpi@freebsd.org, "Moore, Robert" X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Tarick Subject: panic in AcpiExReleaseMutex X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 09:24:08 -0000 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