From owner-freebsd-acpi@FreeBSD.ORG Fri Dec 4 21:43: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 D0271106568B for ; Fri, 4 Dec 2009 21:43:21 +0000 (UTC) (envelope-from robert.moore@intel.com) Received: from mga03.intel.com (mga03.intel.com [143.182.124.21]) by mx1.freebsd.org (Postfix) with ESMTP id A33B18FC1A for ; Fri, 4 Dec 2009 21:43:21 +0000 (UTC) Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga101.ch.intel.com with ESMTP; 04 Dec 2009 13:43:21 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.47,316,1257148800"; d="scan'208";a="219000448" Received: from orsmsx603.amr.corp.intel.com ([10.22.226.49]) by azsmga001.ch.intel.com with ESMTP; 04 Dec 2009 13:43:21 -0800 Received: from orsmsx503.amr.corp.intel.com ([10.22.226.47]) by orsmsx603.amr.corp.intel.com ([10.22.226.49]) with mapi; Fri, 4 Dec 2009 13:43:14 -0800 From: "Moore, Robert" To: Andriy Gapon Date: Fri, 4 Dec 2009 13:43:13 -0800 Thread-Topic: panic in AcpiExReleaseMutex Thread-Index: Acp1KjJBI+ErTVPaR9CRE148MXJIWAAACNAw Message-ID: <4911F71203A09E4D9981D27F9D8308583E8F2C55@orsmsx503.amr.corp.intel.com> References: <4B178387.4050601@icyb.net.ua> <4911F71203A09E4D9981D27F9D8308583E8F26CF@orsmsx503.amr.corp.intel.com> <4B189CD6.30906@icyb.net.ua> <4911F71203A09E4D9981D27F9D8308583E8F2A1F@orsmsx503.amr.corp.intel.com> <4B1975EE.5070803@icyb.net.ua> <4911F71203A09E4D9981D27F9D8308583E8F2BA9@orsmsx503.amr.corp.intel.com> <4B197D0E.1020400@icyb.net.ua> <4911F71203A09E4D9981D27F9D8308583E8F2C06@orsmsx503.amr.corp.intel.com> <4B198142.2040407@icyb.net.ua> In-Reply-To: <4B198142.2040407@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: "freebsd-acpi@freebsd.org" , 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 21:43:21 -0000 >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 =3D 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? =20 >-----Original Message----- >From: Andriy Gapon [mailto:avg@icyb.net.ua] >Sent: Friday, December 04, 2009 1:38 PM >To: Moore, Robert >Cc: freebsd-acpi@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@icyb.net.ua] >>> Sent: Friday, December 04, 2009 1:20 PM To: Moore, Robert Cc: >>> freebsd-acpi@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 metho= d >>> 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@icyb.net.ua= ] >>>>> Sent: Friday, December 04, 2009 12:50 PM To: Moore, Robert Cc: >>>>> freebsd-acpi@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 wron= g >>>>>> >>> 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