From owner-freebsd-acpi@FreeBSD.ORG Fri Dec 4 04:57:21 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 0BA72106566B for ; Fri, 4 Dec 2009 04:57:18 +0000 (UTC) (envelope-from robert.moore@intel.com) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by mx1.freebsd.org (Postfix) with ESMTP id AE59A8FC0A for ; Fri, 4 Dec 2009 04:57:18 +0000 (UTC) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga102.fm.intel.com with ESMTP; 03 Dec 2009 20:52:54 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.47,339,1257148800"; d="scan'208";a="752726546" Received: from orsmsx604.amr.corp.intel.com ([10.22.226.87]) by fmsmga001.fm.intel.com with ESMTP; 03 Dec 2009 20:57:16 -0800 Received: from orsmsx503.amr.corp.intel.com ([10.22.226.47]) by orsmsx604.amr.corp.intel.com ([10.250.113.17]) with mapi; Thu, 3 Dec 2009 20:57:17 -0800 From: "Moore, Robert" To: Andriy Gapon , "freebsd-acpi@freebsd.org" Date: Thu, 3 Dec 2009 20:57:16 -0800 Thread-Topic: panic in AcpiExReleaseMutex Thread-Index: Acpz+mBME2OdDzj5SQWVtBgIcgIlIAAo5isg Message-ID: <4911F71203A09E4D9981D27F9D8308583E8F26CF@orsmsx503.amr.corp.intel.com> References: <4B178387.4050601@icyb.net.ua> In-Reply-To: <4B178387.4050601@icyb.net.ua> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Tarick Subject: RE: 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: Fri, 04 Dec 2009 04:57:21 -0000 >I am somewhat suspicious of recursive use of \_SB.PCI0.LPC0.EC0.MUT1 It is OK for AML code to acquire a mutex multiple times, so I don't think t= hat is the problem. > PreviousSyncLevel =3D > WalkState->Thread->AcquiredMutexList->Mutex.OriginalSyncLevel; Multiple pointers here, do you know which one is null? >-----Original Message----- >From: Andriy Gapon [mailto:avg@icyb.net.ua] >Sent: Thursday, December 03, 2009 1:23 AM >To: freebsd-acpi@freebsd.org; Moore, Robert >Cc: Tarick >Subject: panic in AcpiExReleaseMutex > > >We are trying to resolve an issue reported in the following FreeBSD PR: >http://www.freebsd.org/cgi/query-pr.cgi?pr=3D140979 > >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 =3D > 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 E= C >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 make= s >a >direct call to EcGpeQueryHandler during a cold boot phase if SCI bit is se= t >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