From owner-freebsd-acpi@FreeBSD.ORG Fri Dec 4 21:39:07 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 0534A1065670 for ; Fri, 4 Dec 2009 21:39:07 +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 362C58FC12 for ; Fri, 4 Dec 2009 21:39:05 +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 XAA24165; Fri, 04 Dec 2009 23:38:58 +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 1NGfrd-000JsA-JC; Fri, 04 Dec 2009 23:38:57 +0200 Message-ID: <4B198142.2040407@icyb.net.ua> Date: Fri, 04 Dec 2009 23:38:10 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20091128) MIME-Version: 1.0 To: "Moore, Robert" 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> In-Reply-To: <4911F71203A09E4D9981D27F9D8308583E8F2C06@orsmsx503.amr.corp.intel.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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:39:07 -0000 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 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@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 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 -- Andriy Gapon