From owner-freebsd-acpi@FreeBSD.ORG Sun Nov 25 14:00:17 2012 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E697FEAF; Sun, 25 Nov 2012 14:00:17 +0000 (UTC) (envelope-from stefan@fafoe.narf.at) Received: from fep17.mx.upcmail.net (fep17.mx.upcmail.net [62.179.121.37]) by mx1.freebsd.org (Postfix) with ESMTP id F13D88FC0C; Sun, 25 Nov 2012 14:00:16 +0000 (UTC) Received: from edge03.upcmail.net ([192.168.13.238]) by viefep17-int.chello.at (InterMail vM.8.01.05.05 201-2260-151-110-20120111) with ESMTP id <20121125140009.XBEQ7658.viefep17-int.chello.at@edge03.upcmail.net>; Sun, 25 Nov 2012 15:00:09 +0100 Received: from mole.fafoe.narf.at ([80.109.55.137]) by edge03.upcmail.net with edge id Tq091k00D2xdvHc03q09Zm; Sun, 25 Nov 2012 15:00:09 +0100 X-SourceIP: 80.109.55.137 Received: by mole.fafoe.narf.at (Postfix, from userid 1001) id DCD816D449; Sun, 25 Nov 2012 15:00:08 +0100 (CET) Date: Sun, 25 Nov 2012 15:00:08 +0100 From: Stefan Farfeleder To: Andriy Gapon Subject: Re: ACPI panic Message-ID: <20121125140008.GA1497@mole.fafoe.narf.at> References: <20121120103522.GB2012@mole.fafoe.narf.at> <50AC0A68.8070906@FreeBSD.org> <20121121104840.GA1468@mole.fafoe.narf.at> <20121122081831.GA1483@mole.fafoe.narf.at> <50ADFD75.10709@FreeBSD.org> <50ADFFB2.1000108@FreeBSD.org> <50AE057D.8060808@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50AE057D.8060808@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-acpi@FreeBSD.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Nov 2012 14:00:18 -0000 Hi Andriy, with your patch my notebook has a ~50% chance of stalling during boot. This always happens after the "Entropy harvesting" line and I can only power it down then. I guess somehow cycles are introduced into the acpi objects list? The panic was never triggered. Stefan On Thu, Nov 22, 2012 at 12:59:09PM +0200, Andriy Gapon wrote: > > A patch that should actually compile, finally. > BTW, it's probably better to replace the NULL dereference trick with a simple > panic call in the first patch too. > > diff --git a/sys/contrib/dev/acpica/components/utilities/utcache.c > b/sys/contrib/dev/acpica/components/utilities/utcache.c > index b8efa68..edd9e4f 100644 > --- a/sys/contrib/dev/acpica/components/utilities/utcache.c > +++ b/sys/contrib/dev/acpica/components/utilities/utcache.c > @@ -226,6 +226,21 @@ AcpiOsReleaseObject ( > return (AE_BAD_PARAMETER); > } > > + (void) AcpiUtAcquireMutex (ACPI_MTX_CACHES); > + char *Curr; > + char *Next; > + Next = Cache->ListHead; > + while (Next) > + { > + Curr = Next; > + Next = *(ACPI_CAST_INDIRECT_PTR (char, > + &(((char *) Curr)[Cache->LinkOffset]))); > + if (Object == Curr) { > + panic("freeing a free object %p", Object); > + } > + } > + (void) AcpiUtReleaseMutex (ACPI_MTX_CACHES); > + > /* If cache is full, just free this object */ > > if (Cache->CurrentDepth >= Cache->MaxDepth) > @@ -312,6 +327,10 @@ AcpiOsAcquireObject ( > > Cache->CurrentDepth--; > > + if (*(const unsigned char *) Object != 0xCA) { > + panic("detected use after free %p\n", Object); > + } > + > ACPI_MEM_TRACKING (Cache->Hits++); > ACPI_DEBUG_PRINT ((ACPI_DB_EXEC, > "Object %p from %s cache\n", Object, Cache->ListName)); > > -- > Andriy Gapon > _______________________________________________ > freebsd-acpi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" From owner-freebsd-acpi@FreeBSD.ORG Sun Nov 25 16:17:42 2012 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 610B276B; Sun, 25 Nov 2012 16:17:42 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 730358FC0C; Sun, 25 Nov 2012 16:17:41 +0000 (UTC) Received: from porto.starpoint.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 SAA19686; Sun, 25 Nov 2012 18:17:40 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Tcetn-000L2c-OR; Sun, 25 Nov 2012 18:17:39 +0200 Message-ID: <50B244A1.1040800@FreeBSD.org> Date: Sun, 25 Nov 2012 18:17:37 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Stefan Farfeleder Subject: Re: ACPI panic References: <20121120103522.GB2012@mole.fafoe.narf.at> <50AC0A68.8070906@FreeBSD.org> <20121121104840.GA1468@mole.fafoe.narf.at> <20121122081831.GA1483@mole.fafoe.narf.at> <50ADFD75.10709@FreeBSD.org> <50ADFFB2.1000108@FreeBSD.org> <50AE057D.8060808@FreeBSD.org> <20121125140008.GA1497@mole.fafoe.narf.at> In-Reply-To: <20121125140008.GA1497@mole.fafoe.narf.at> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Nov 2012 16:17:42 -0000 on 25/11/2012 16:00 Stefan Farfeleder said the following: > Hi Andriy, > > with your patch my notebook has a ~50% chance of stalling during boot. > This always happens after the "Entropy harvesting" line and I can only > power it down then. > I guess somehow cycles are introduced into the acpi objects list? The > panic was never triggered. Hmm, I didn't think that the cycles were possible... Could you please try the following patch on top of the previous ones? Also, if you don't have DDB in your kernel yet, please add it and try to break into the debugger if one of those hangs happens again without any panic. diff --git a/sys/contrib/dev/acpica/components/utilities/utcache.c b/sys/contrib/dev/acpica/components/utilities/utcache.c index edd9e4f..5eee934 100644 --- a/sys/contrib/dev/acpica/components/utilities/utcache.c +++ b/sys/contrib/dev/acpica/components/utilities/utcache.c @@ -229,6 +229,8 @@ AcpiOsReleaseObject ( (void) AcpiUtAcquireMutex (ACPI_MTX_CACHES); char *Curr; char *Next; + int Depth; + Depth = Cache->CurrentDepth; Next = Cache->ListHead; while (Next) { @@ -238,6 +240,10 @@ AcpiOsReleaseObject ( if (Object == Curr) { panic("freeing a free object %p", Object); } + Depth--; + if (Depth < 0) { + panic("cycle in a cache list"); + } } (void) AcpiUtReleaseMutex (ACPI_MTX_CACHES); -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Sun Nov 25 19:37:33 2012 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 910F9B0; Sun, 25 Nov 2012 19:37:33 +0000 (UTC) (envelope-from seanwbruno@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 557698FC13; Sun, 25 Nov 2012 19:37:32 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id wz12so7679835pbc.13 for ; Sun, 25 Nov 2012 11:37:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:from:reply-to:to:cc:in-reply-to:references:content-type :date:message-id:mime-version:x-mailer:content-transfer-encoding; bh=GhjqBHN0xXY+FNKFsPPlr952Z6Gfmds6qf22BTar5d4=; b=m5mI9d5iFf8KTaBYwLKTAKGgwWQC4a/Pje+m8S6RkG1gl8xM+hVODMjsdPtBP1aaiY SF1RBTQ+U8eIauGSBuHs/AZQT5OIImFpGQxDZP466nfjOaVeJoe9oPY92p5uv5jRhmHw O46gN1yw5eBy6xWL9KvN4DYUlxSuuWKYY4dcp9h25KizTJnb5UCm/UyAqhsK/+Ayd0yx k412cEW8netpXihHydUPC6cqXhy/GBBQdELe3kubKvMDWAl/2qyE7prZuhgwjJhfycdf LCZwHMGNCzcUaXDRV8mkEvs6vmU9iOn3kLv1XuB5eex75wmYllZo1OhHstaMaYps7qzt gnnw== Received: by 10.66.85.10 with SMTP id d10mr26790563paz.52.1353872252573; Sun, 25 Nov 2012 11:37:32 -0800 (PST) Received: from [192.168.1.128] (c-71-202-40-63.hsd1.ca.comcast.net. [71.202.40.63]) by mx.google.com with ESMTPS id qj6sm7418477pbb.69.2012.11.25.11.37.31 (version=SSLv3 cipher=OTHER); Sun, 25 Nov 2012 11:37:31 -0800 (PST) Subject: Re: [rfc] bind curthread to target cpu for _CST change notification From: Sean Bruno To: Andriy Gapon In-Reply-To: <50AE3C66.2050207@FreeBSD.org> References: <50AE3C66.2050207@FreeBSD.org> Content-Type: text/plain; charset="UTF-8" Date: Sun, 25 Nov 2012 11:37:29 -0800 Message-ID: <1353872249.20189.3.camel@powernoodle> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: sbruno@freebsd.org List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Nov 2012 19:37:33 -0000 On Thu, 2012-11-22 at 16:53 +0200, Andriy Gapon wrote: > I would like to propose the following patch which should kill two birds with one > stone: > > - avoid race in acpi_cpu_cx_cst if more than one notifications occur in a rapid > succession for the same CPU and end up being concurrently handled by ACPI taskqeue > threads > - avoid race acpi_cpu_cx_cst and acpi_cpu_idle where the latter may access > resources being updated by the former > > What do you think? > > Index: sys/dev/acpica/acpi_cpu.c > =================================================================== > --- sys/dev/acpica/acpi_cpu.c (revision 242854) > +++ sys/dev/acpica/acpi_cpu.c (working copy) > @@ -1047,7 +1047,16 @@ > return; > > /* Update the list of Cx states. */ > + thread_lock(curthread); > + sched_bind(curthread, sc->cpu_pcpu->pc_cpuid); > + thread_unlock(curthread); > + critical_enter(); > acpi_cpu_cx_cst(sc); > + critical_exit(); > + thread_lock(curthread); > + sched_unbind(curthread); > + thread_unlock(curthread); > + > acpi_cpu_cx_list(sc); > > ACPI_SERIAL_BEGIN(cpu); > Ack. This looks appropriate to me. Sean From owner-freebsd-acpi@FreeBSD.ORG Mon Nov 26 09:11:26 2012 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 55E761C3; Mon, 26 Nov 2012 09:11:26 +0000 (UTC) (envelope-from stefan@fafoe.narf.at) Received: from fep13.mx.upcmail.net (fep13.mx.upcmail.net [62.179.121.33]) by mx1.freebsd.org (Postfix) with ESMTP id 68A658FC0C; Mon, 26 Nov 2012 09:11:23 +0000 (UTC) Received: from edge01.upcmail.net ([192.168.13.236]) by viefep13-int.chello.at (InterMail vM.8.01.05.05 201-2260-151-110-20120111) with ESMTP id <20121126091116.YAZH3518.viefep13-int.chello.at@edge01.upcmail.net>; Mon, 26 Nov 2012 10:11:16 +0100 Received: from mole.fafoe.narf.at ([80.109.55.137]) by edge01.upcmail.net with edge id U9BB1k0022xdvHc019BEcd; Mon, 26 Nov 2012 10:11:16 +0100 X-SourceIP: 80.109.55.137 Received: by mole.fafoe.narf.at (Postfix, from userid 1001) id D5BAC6D449; Mon, 26 Nov 2012 10:11:10 +0100 (CET) Date: Mon, 26 Nov 2012 10:11:10 +0100 From: Stefan Farfeleder To: Andriy Gapon Subject: Re: ACPI panic Message-ID: <20121126091101.GA1469@mole.fafoe.narf.at> References: <20121120103522.GB2012@mole.fafoe.narf.at> <50AC0A68.8070906@FreeBSD.org> <20121121104840.GA1468@mole.fafoe.narf.at> <20121122081831.GA1483@mole.fafoe.narf.at> <50ADFD75.10709@FreeBSD.org> <50ADFFB2.1000108@FreeBSD.org> <50AE057D.8060808@FreeBSD.org> <20121125140008.GA1497@mole.fafoe.narf.at> <50B244A1.1040800@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50B244A1.1040800@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-acpi@FreeBSD.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 09:11:26 -0000 On Sun, Nov 25, 2012 at 06:17:37PM +0200, Andriy Gapon wrote: > @@ -238,6 +240,10 @@ AcpiOsReleaseObject ( > if (Object == Curr) { > panic("freeing a free object %p", Object); > } > + Depth--; > + if (Depth < 0) { > + panic("cycle in a cache list"); > + } > } > (void) AcpiUtReleaseMutex (ACPI_MTX_CACHES); I can easily trigger this panic. At the time of the panic, the cache list has ~30 entries and somewhere in the middle there's a 2-item cycle A -> B -> A. I don't think release is called twice on A as your patch checks that and the cycle is not at the beginning of the loop. So this means "someone" changes the next pointer while the object is in the cache. Stefan From owner-freebsd-acpi@FreeBSD.ORG Mon Nov 26 09:29:59 2012 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5A3BC62B; Mon, 26 Nov 2012 09:29:59 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 7367E8FC0C; Mon, 26 Nov 2012 09:29:58 +0000 (UTC) Received: from porto.starpoint.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 LAA28261; Mon, 26 Nov 2012 11:29:56 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Tcv0m-000Lgs-JJ; Mon, 26 Nov 2012 11:29:56 +0200 Message-ID: <50B33693.2060000@FreeBSD.org> Date: Mon, 26 Nov 2012 11:29:55 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Stefan Farfeleder Subject: Re: ACPI panic References: <20121120103522.GB2012@mole.fafoe.narf.at> <50AC0A68.8070906@FreeBSD.org> <20121121104840.GA1468@mole.fafoe.narf.at> <20121122081831.GA1483@mole.fafoe.narf.at> <50ADFD75.10709@FreeBSD.org> <50ADFFB2.1000108@FreeBSD.org> <50AE057D.8060808@FreeBSD.org> <20121125140008.GA1497@mole.fafoe.narf.at> <50B244A1.1040800@FreeBSD.org> <20121126091101.GA1469@mole.fafoe.narf.at> In-Reply-To: <20121126091101.GA1469@mole.fafoe.narf.at> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 09:29:59 -0000 on 26/11/2012 11:11 Stefan Farfeleder said the following: > On Sun, Nov 25, 2012 at 06:17:37PM +0200, Andriy Gapon wrote: >> @@ -238,6 +240,10 @@ AcpiOsReleaseObject ( >> if (Object == Curr) { >> panic("freeing a free object %p", Object); >> } >> + Depth--; >> + if (Depth < 0) { >> + panic("cycle in a cache list"); >> + } >> } >> (void) AcpiUtReleaseMutex (ACPI_MTX_CACHES); > > I can easily trigger this panic. At the time of the panic, the cache > list has ~30 entries and somewhere in the middle there's a 2-item cycle > A -> B -> A. I don't think release is called twice on A as your patch > checks that and the cycle is not at the beginning of the loop. So this > means "someone" changes the next pointer while the object is in the > cache. Very interesting, thank you. Are you able to get a crash dump? -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Mon Nov 26 09:37:26 2012 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3371098D; Mon, 26 Nov 2012 09:37:26 +0000 (UTC) (envelope-from stefan@fafoe.narf.at) Received: from fep24.mx.upcmail.net (fep24.mx.upcmail.net [62.179.121.44]) by mx1.freebsd.org (Postfix) with ESMTP id 71B438FC0C; Mon, 26 Nov 2012 09:37:25 +0000 (UTC) Received: from edge03.upcmail.net ([192.168.13.238]) by viefep12-int.chello.at (InterMail vM.8.01.05.05 201-2260-151-110-20120111) with ESMTP id <20121126093705.YDLU2716.viefep12-int.chello.at@edge03.upcmail.net>; Mon, 26 Nov 2012 10:37:05 +0100 Received: from mole.fafoe.narf.at ([80.109.55.137]) by edge03.upcmail.net with edge id U9d41k03M2xdvHc039d5gw; Mon, 26 Nov 2012 10:37:05 +0100 X-SourceIP: 80.109.55.137 Received: by mole.fafoe.narf.at (Postfix, from userid 1001) id CA4AB6D449; Mon, 26 Nov 2012 10:37:04 +0100 (CET) Date: Mon, 26 Nov 2012 10:37:04 +0100 From: Stefan Farfeleder To: Andriy Gapon Subject: Re: ACPI panic Message-ID: <20121126093704.GB1469@mole.fafoe.narf.at> References: <50AC0A68.8070906@FreeBSD.org> <20121121104840.GA1468@mole.fafoe.narf.at> <20121122081831.GA1483@mole.fafoe.narf.at> <50ADFD75.10709@FreeBSD.org> <50ADFFB2.1000108@FreeBSD.org> <50AE057D.8060808@FreeBSD.org> <20121125140008.GA1497@mole.fafoe.narf.at> <50B244A1.1040800@FreeBSD.org> <20121126091101.GA1469@mole.fafoe.narf.at> <50B33693.2060000@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50B33693.2060000@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-acpi@FreeBSD.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 09:37:26 -0000 On Mon, Nov 26, 2012 at 11:29:55AM +0200, Andriy Gapon wrote: > > Very interesting, thank you. > Are you able to get a crash dump? Yes. (kgdb) bt #0 doadump (textdump=0) at pcpu.h:229 #1 0xffffffff802becae in db_dump (dummy=, dummy2=0, dummy3=0, dummy4=0x0) at /usr/src/sys/ddb/db_command.c:543 #2 0xffffffff802be874 in db_command (last_cmdp=, cmd_table=, dopager=1) at /usr/src/sys/ddb/db_command.c:449 #3 0xffffffff802be562 in db_command_loop () at /usr/src/sys/ddb/db_command.c:502 #4 0xffffffff802c0e40 in db_trap (type=, code=0) at /usr/src/sys/ddb/db_main.c:231 #5 0xffffffff804c165e in kdb_trap (type=3, code=0, tf=) at /usr/src/sys/kern/subr_kdb.c:654 #6 0xffffffff806ee2dc in trap (frame=0xffffff811fe0e3f0) at /usr/src/sys/amd64/amd64/trap.c:579 #7 0xffffffff806d8e43 in calltrap () at /tmp/exception-EAhiLL.s:142 #8 0xffffffff804c0e5e in kdb_enter (why=0xffffffff8079246e "panic", msg=) at cpufunc.h:63 #9 0xffffffff8048ca4f in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:628 #10 0xffffffff802b57ca in AcpiOsReleaseObject (Cache=0xfffffe000292a700, Object=0xfffffe0002a60780) at /usr/src/sys/contrib/dev/acpica/components/utilities/utcache.c:245 #11 0xffffffff802b679d in AcpiUtUpdateRefCount (Object=0xfffffe0002a60780, ---Type to continue, or q to quit--- Action=) at /usr/src/sys/contrib/dev/acpica/components/utilities/utdelete.c:464 #12 0xffffffff802b66fb in AcpiUtUpdateObjectReference ( Object=0xfffffe0002a60780, Action=1) at /usr/src/sys/contrib/dev/acpica/components/utilities/utdelete.c:648 #13 0xffffffff8029bbc5 in AcpiDsIsResultUsed (Op=0xfffffe00041b3a00, WalkState=0xfffffe00061a4800) at /usr/src/sys/contrib/dev/acpica/components/dispatcher/dsutils.c:100 #14 0xffffffff8029bd03 in AcpiDsDeleteResultIfNotUsed (Op=0xffffff811fe0e3b0, ResultObj=0xfffffe0002a60700, WalkState=0xfffffe00061a4800) at /usr/src/sys/contrib/dev/acpica/components/dispatcher/dsutils.c:388 #15 0xffffffff8029c874 in AcpiDsExecEndOp (WalkState=0xfffffe00061a4800) at /usr/src/sys/contrib/dev/acpica/components/dispatcher/dswexec.c:773 #16 0xffffffff802afe04 in AcpiPsParseLoop (WalkState=0xfffffe00061a4800) at /usr/src/sys/contrib/dev/acpica/components/parser/psloop.c:1276 #17 0xffffffff802b068d in AcpiPsParseAml (WalkState=) at /usr/src/sys/contrib/dev/acpica/components/parser/psparse.c:525 #18 0xffffffff802b11e7 in AcpiPsExecuteMethod (Info=0xfffffe0006139440) at /usr/src/sys/contrib/dev/acpica/components/parser/psxface.c:368 #19 0xffffffff802aac16 in AcpiNsEvaluate (Info=0xfffffe0006139440) at /usr/src/sys/contrib/dev/acpica/components/namespace/nseval.c:193 #20 0xffffffff802add48 in AcpiEvaluateObject (Handle=0xfffffe0002a03dc0, Pathname=, ExternalParams=, ---Type to continue, or q to quit--- ReturnBuffer=0xffffff811fe0e838) at /usr/src/sys/contrib/dev/acpica/components/namespace/nsxfeval.c:289 #21 0xffffffff802c6fdf in acpi_GetInteger (handle=, path=0xffffffff80756410 "_PSR", number=0xffffff811fe0e884) at /usr/src/sys/dev/acpica/acpi.c:2207 #22 0xffffffff802cc8ff in acpi_acad_get_status (context=0xfffffe0002a3cd00) at /usr/src/sys/dev/acpica/acpi_acad.c:106 #23 0xffffffff802cccc4 in acpi_acad_sysctl (oidp=0xfffffe0004192000, arg1=0xfffffe0004145980, arg2=-2142478272, req=0xffffff811fe0e968) at /usr/src/sys/dev/acpica/acpi_acad.c:279 #24 0xffffffff80496d0c in sysctl_root (arg1=, arg2=) at /usr/src/sys/kern/kern_sysctl.c:1513 #25 0xffffffff804972c8 in userland_sysctl (td=, name=0xffffff811fe0ea30, namelen=, old=, oldlenp=, inkernel=, new=, newlen=, retval=, flags=534833488) at /usr/src/sys/kern/kern_sysctl.c:1623 #26 0xffffffff804970b4 in sys___sysctl (td=0xfffffe00061fe900, uap=0xffffff811fe0eb40) at /usr/src/sys/kern/kern_sysctl.c:1549 #27 0xffffffff806eef8e in amd64_syscall (td=0xfffffe00061fe900, traced=0) at subr_syscall.c:135 #28 0xffffffff806d912b in Xfast_syscall () at /tmp/exception-EAhiLL.s:292 ---Type to continue, or q to quit--- #29 0x000000080093456a in ?? () Previous frame inner to this frame (corrupt stack?) Current language: auto; currently minimal (kgdb) f 10 #10 0xffffffff802b57ca in AcpiOsReleaseObject (Cache=0xfffffe000292a700, Object=0xfffffe0002a60780) at /usr/src/sys/contrib/dev/acpica/components/utilities/utcache.c:245 245 panic("cycle in a cache list"); (kgdb) p *Cache $1 = {ListName = 0xffffffff8074f8e0 "Acpi-Operand", ListHead = 0xfffffe0002a60580, ObjectSize = 72, MaxDepth = 96, CurrentDepth = 30, LinkOffset = 8} From owner-freebsd-acpi@FreeBSD.ORG Mon Nov 26 10:29:28 2012 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 004CE9C4; Mon, 26 Nov 2012 10:29:27 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 28D058FC17; Mon, 26 Nov 2012 10:29:26 +0000 (UTC) Received: from porto.starpoint.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 MAA29070; Mon, 26 Nov 2012 12:29:26 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TcvwL-000LjE-Iq; Mon, 26 Nov 2012 12:29:25 +0200 Message-ID: <50B34484.1090807@FreeBSD.org> Date: Mon, 26 Nov 2012 12:29:24 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Stefan Farfeleder Subject: Re: ACPI panic References: <50AC0A68.8070906@FreeBSD.org> <20121121104840.GA1468@mole.fafoe.narf.at> <20121122081831.GA1483@mole.fafoe.narf.at> <50ADFD75.10709@FreeBSD.org> <50ADFFB2.1000108@FreeBSD.org> <50AE057D.8060808@FreeBSD.org> <20121125140008.GA1497@mole.fafoe.narf.at> <50B244A1.1040800@FreeBSD.org> <20121126091101.GA1469@mole.fafoe.narf.at> <50B33693.2060000@FreeBSD.org> <20121126093704.GB1469@mole.fafoe.narf.at> In-Reply-To: <20121126093704.GB1469@mole.fafoe.narf.at> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 10:29:28 -0000 on 26/11/2012 11:37 Stefan Farfeleder said the following: > On Mon, Nov 26, 2012 at 11:29:55AM +0200, Andriy Gapon wrote: >> >> Very interesting, thank you. >> Are you able to get a crash dump? > > Yes. Great! Could you please cast those cycled objects to 'union acpi_operand_object' and print them? Something like 'p *(union acpi_operand_object *)$x'. > (kgdb) bt > #0 doadump (textdump=0) at pcpu.h:229 > #1 0xffffffff802becae in db_dump (dummy=, dummy2=0, > dummy3=0, dummy4=0x0) at /usr/src/sys/ddb/db_command.c:543 > #2 0xffffffff802be874 in db_command (last_cmdp=, > cmd_table=, dopager=1) > at /usr/src/sys/ddb/db_command.c:449 > #3 0xffffffff802be562 in db_command_loop () > at /usr/src/sys/ddb/db_command.c:502 > #4 0xffffffff802c0e40 in db_trap (type=, code=0) > at /usr/src/sys/ddb/db_main.c:231 > #5 0xffffffff804c165e in kdb_trap (type=3, code=0, tf=) > at /usr/src/sys/kern/subr_kdb.c:654 > #6 0xffffffff806ee2dc in trap (frame=0xffffff811fe0e3f0) > at /usr/src/sys/amd64/amd64/trap.c:579 > #7 0xffffffff806d8e43 in calltrap () at /tmp/exception-EAhiLL.s:142 > #8 0xffffffff804c0e5e in kdb_enter (why=0xffffffff8079246e "panic", > msg=) at cpufunc.h:63 > #9 0xffffffff8048ca4f in panic (fmt=) > at /usr/src/sys/kern/kern_shutdown.c:628 > #10 0xffffffff802b57ca in AcpiOsReleaseObject (Cache=0xfffffe000292a700, > Object=0xfffffe0002a60780) > at /usr/src/sys/contrib/dev/acpica/components/utilities/utcache.c:245 > #11 0xffffffff802b679d in AcpiUtUpdateRefCount (Object=0xfffffe0002a60780, > ---Type to continue, or q to quit--- > Action=) > at /usr/src/sys/contrib/dev/acpica/components/utilities/utdelete.c:464 > #12 0xffffffff802b66fb in AcpiUtUpdateObjectReference ( > Object=0xfffffe0002a60780, Action=1) > at /usr/src/sys/contrib/dev/acpica/components/utilities/utdelete.c:648 > #13 0xffffffff8029bbc5 in AcpiDsIsResultUsed (Op=0xfffffe00041b3a00, > WalkState=0xfffffe00061a4800) > at /usr/src/sys/contrib/dev/acpica/components/dispatcher/dsutils.c:100 > #14 0xffffffff8029bd03 in AcpiDsDeleteResultIfNotUsed (Op=0xffffff811fe0e3b0, > ResultObj=0xfffffe0002a60700, WalkState=0xfffffe00061a4800) > at /usr/src/sys/contrib/dev/acpica/components/dispatcher/dsutils.c:388 > #15 0xffffffff8029c874 in AcpiDsExecEndOp (WalkState=0xfffffe00061a4800) > at /usr/src/sys/contrib/dev/acpica/components/dispatcher/dswexec.c:773 > #16 0xffffffff802afe04 in AcpiPsParseLoop (WalkState=0xfffffe00061a4800) > at /usr/src/sys/contrib/dev/acpica/components/parser/psloop.c:1276 > #17 0xffffffff802b068d in AcpiPsParseAml (WalkState=) > at /usr/src/sys/contrib/dev/acpica/components/parser/psparse.c:525 > #18 0xffffffff802b11e7 in AcpiPsExecuteMethod (Info=0xfffffe0006139440) > at /usr/src/sys/contrib/dev/acpica/components/parser/psxface.c:368 > #19 0xffffffff802aac16 in AcpiNsEvaluate (Info=0xfffffe0006139440) > at /usr/src/sys/contrib/dev/acpica/components/namespace/nseval.c:193 > #20 0xffffffff802add48 in AcpiEvaluateObject (Handle=0xfffffe0002a03dc0, > Pathname=, ExternalParams=, > ---Type to continue, or q to quit--- > ReturnBuffer=0xffffff811fe0e838) > at /usr/src/sys/contrib/dev/acpica/components/namespace/nsxfeval.c:289 > #21 0xffffffff802c6fdf in acpi_GetInteger (handle=, > path=0xffffffff80756410 "_PSR", number=0xffffff811fe0e884) > at /usr/src/sys/dev/acpica/acpi.c:2207 > #22 0xffffffff802cc8ff in acpi_acad_get_status (context=0xfffffe0002a3cd00) > at /usr/src/sys/dev/acpica/acpi_acad.c:106 > #23 0xffffffff802cccc4 in acpi_acad_sysctl (oidp=0xfffffe0004192000, > arg1=0xfffffe0004145980, arg2=-2142478272, req=0xffffff811fe0e968) > at /usr/src/sys/dev/acpica/acpi_acad.c:279 > #24 0xffffffff80496d0c in sysctl_root (arg1=, > arg2=) at /usr/src/sys/kern/kern_sysctl.c:1513 > #25 0xffffffff804972c8 in userland_sysctl (td=, > name=0xffffff811fe0ea30, namelen=, > old=, oldlenp=, > inkernel=, new=, > newlen=, retval=, > flags=534833488) at /usr/src/sys/kern/kern_sysctl.c:1623 > #26 0xffffffff804970b4 in sys___sysctl (td=0xfffffe00061fe900, > uap=0xffffff811fe0eb40) at /usr/src/sys/kern/kern_sysctl.c:1549 > #27 0xffffffff806eef8e in amd64_syscall (td=0xfffffe00061fe900, traced=0) > at subr_syscall.c:135 > #28 0xffffffff806d912b in Xfast_syscall () at /tmp/exception-EAhiLL.s:292 > ---Type to continue, or q to quit--- > #29 0x000000080093456a in ?? () > Previous frame inner to this frame (corrupt stack?) > Current language: auto; currently minimal > (kgdb) f 10 > #10 0xffffffff802b57ca in AcpiOsReleaseObject (Cache=0xfffffe000292a700, > Object=0xfffffe0002a60780) > at /usr/src/sys/contrib/dev/acpica/components/utilities/utcache.c:245 > 245 panic("cycle in a cache list"); > (kgdb) p *Cache > $1 = {ListName = 0xffffffff8074f8e0 "Acpi-Operand", > ListHead = 0xfffffe0002a60580, ObjectSize = 72, MaxDepth = 96, > CurrentDepth = 30, LinkOffset = 8} > -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Mon Nov 26 10:47:43 2012 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 75D56CD0; Mon, 26 Nov 2012 10:47:43 +0000 (UTC) (envelope-from stefan@fafoe.narf.at) Received: from fep13.mx.upcmail.net (fep13.mx.upcmail.net [62.179.121.33]) by mx1.freebsd.org (Postfix) with ESMTP id 4E9228FC12; Mon, 26 Nov 2012 10:47:40 +0000 (UTC) Received: from edge04.upcmail.net ([192.168.13.239]) by viefep13-int.chello.at (InterMail vM.8.01.05.05 201-2260-151-110-20120111) with ESMTP id <20121126104738.ERZR3518.viefep13-int.chello.at@edge04.upcmail.net>; Mon, 26 Nov 2012 11:47:38 +0100 Received: from mole.fafoe.narf.at ([80.109.55.137]) by edge04.upcmail.net with edge id UAnd1k04F2xdvHc04AnexB; Mon, 26 Nov 2012 11:47:38 +0100 X-SourceIP: 80.109.55.137 Received: by mole.fafoe.narf.at (Postfix, from userid 1001) id D99776D449; Mon, 26 Nov 2012 11:47:37 +0100 (CET) Date: Mon, 26 Nov 2012 11:47:37 +0100 From: Stefan Farfeleder To: Andriy Gapon Subject: Re: ACPI panic Message-ID: <20121126104737.GC1469@mole.fafoe.narf.at> References: <20121122081831.GA1483@mole.fafoe.narf.at> <50ADFD75.10709@FreeBSD.org> <50ADFFB2.1000108@FreeBSD.org> <50AE057D.8060808@FreeBSD.org> <20121125140008.GA1497@mole.fafoe.narf.at> <50B244A1.1040800@FreeBSD.org> <20121126091101.GA1469@mole.fafoe.narf.at> <50B33693.2060000@FreeBSD.org> <20121126093704.GB1469@mole.fafoe.narf.at> <50B34484.1090807@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <50B34484.1090807@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-acpi@FreeBSD.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 10:47:43 -0000 On Mon, Nov 26, 2012 at 12:29:24PM +0200, Andriy Gapon wrote: > Great! > Could you please cast those cycled objects to 'union acpi_operand_object' and > print them? Something like 'p *(union acpi_operand_object *)$x'. Sure. First here's the cycle: (kgdb) p *(void **)(0xfffffe0006117600+8) $2 = (void *) 0xfffffe0006117680 (kgdb) p *(void **)(0xfffffe0006117680+8) $3 = (void *) 0xfffffe0002a60080 (kgdb) p *(void **)(0xfffffe0002a60080+8) $4 = (void *) 0xfffffe0006117680 The last two objects look like this (0xca except the next pointer): (kgdb) p *(union acpi_operand_object *)0xfffffe0006117680 $6 = {Common = {NextObject = 0xcacacacacacacaca, DescriptorType = 128 '\200', Type = 0 '\0', ReferenceCount = 678, Flags = 0 '\0'}, Integer = { NextObject = 0xcacacacacacacaca, DescriptorType = 128 '\200', Type = 0 '\0', ReferenceCount = 678, Flags = 0 '\0', Fill = "���", Value = 14612714913291487946}, String = {NextObject = 0xcacacacacacacaca, DescriptorType = 128 '\200', Type = 0 '\0', ReferenceCount = 678, Flags = 0 '\0', Pointer = 0xcacacacacacacaca
, Length = 3402287818}, Buffer = {NextObject = 0xcacacacacacacaca, DescriptorType = 128 '\200', Type = 0 '\0', ReferenceCount = 678, Flags = 0 '\0', Pointer = 0xcacacacacacacaca
, Length = 3402287818, AmlLength = 3402287818, AmlStart = 0xcacacacacacacaca
, Node = 0xcacacacacacacaca}, Package = {NextObject = 0xcacacacacacacaca, DescriptorType = 128 '\200', Type = 0 '\0', ReferenceCount = 678, Flags = 0 '\0', Node = 0xcacacacacacacaca, Elements = 0xcacacacacacacaca, AmlStart = 0xcacacacacacacaca
, AmlLength = 3402287818, Count = 3402287818}, Event = { NextObject = 0xcacacacacacacaca, DescriptorType = 128 '\200', Type = 0 '\0', ReferenceCount = 678, Flags = 0 '\0', OsSemaphore = 0xcacacacacacacaca}, Method = { NextObject = 0xcacacacacacacaca, DescriptorType = 128 '\200', ---Type to continue, or q to quit--- Type = 0 '\0', ReferenceCount = 678, Flags = 0 '\0', InfoFlags = 254 '�', ParamCount = 255 '�', SyncLevel = 255 '�', Mutex = 0xcacacacacacacaca, AmlStart = 0xcacacacacacacaca
, Dispatch = {Implementation = 0xcacacacacacacaca, Handler = 0xcacacacacacacaca}, AmlLength = 3402287818, ThreadCount = 202 '�', OwnerId = 202 '�'}, Mutex = { NextObject = 0xcacacacacacacaca, DescriptorType = 128 '\200', Type = 0 '\0', ReferenceCount = 678, Flags = 0 '\0', SyncLevel = 254 '�', AcquisitionDepth = 65535, OsMutex = 0xcacacacacacacaca, ThreadId = 14612714913291487946, OwnerThread = 0xcacacacacacacaca, Prev = 0xcacacacacacacaca, Next = 0xcacacacacacacaca, Node = 0xcacacacacacacaca, OriginalSyncLevel = 202 '�'}, Region = { NextObject = 0xcacacacacacacaca, DescriptorType = 128 '\200', Type = 0 '\0', ReferenceCount = 678, Flags = 0 '\0', SpaceId = 254 '�', Node = 0xcacacacacacacaca, Handler = 0xcacacacacacacaca, Next = 0xcacacacacacacaca, Address = 14612714913291487946, Length = 3402287818}, CommonNotify = {NextObject = 0xcacacacacacacaca, DescriptorType = 128 '\200', Type = 0 '\0', ReferenceCount = 678, Flags = 0 '\0', NotifyList = {0xcacacacacacacaca, 0xcacacacacacacaca}, Handler = 0xcacacacacacacaca}, Device = {NextObject = 0xcacacacacacacaca, DescriptorType = 128 '\200', Type = 0 '\0', ReferenceCount = 678, Flags = 0 '\0', NotifyList = {0xcacacacacacacaca, 0xcacacacacacacaca}, Handler = 0xcacacacacacacaca, GpeBlock = 0xcacacacacacacaca}, ---Type to continue, or q to quit--- PowerResource = {NextObject = 0xcacacacacacacaca, DescriptorType = 128 '\200', Type = 0 '\0', ReferenceCount = 678, Flags = 0 '\0', NotifyList = {0xcacacacacacacaca, 0xcacacacacacacaca}, Handler = 0xcacacacacacacaca, SystemLevel = 3402287818, ResourceOrder = 3402287818}, Processor = {NextObject = 0xcacacacacacacaca, DescriptorType = 128 '\200', Type = 0 '\0', ReferenceCount = 678, Flags = 0 '\0', ProcId = 254 '�', Length = 255 '�', NotifyList = { 0xcacacacacacacaca, 0xcacacacacacacaca}, Handler = 0xcacacacacacacaca, Address = 14612714913291487946}, ThermalZone = { NextObject = 0xcacacacacacacaca, DescriptorType = 128 '\200', Type = 0 '\0', ReferenceCount = 678, Flags = 0 '\0', NotifyList = { 0xcacacacacacacaca, 0xcacacacacacacaca}, Handler = 0xcacacacacacacaca}, CommonField = {NextObject = 0xcacacacacacacaca, DescriptorType = 128 '\200', Type = 0 '\0', ReferenceCount = 678, Flags = 0 '\0', FieldFlags = 254 '�', Attribute = 255 '�', AccessByteWidth = 255 '�', Node = 0xcacacacacacacaca, BitLength = 3402287818, BaseByteOffset = 3402287818, Value = 3402287818, StartFieldBitOffset = 202 '�', AccessLength = 202 '�', RegionObj = 0xcacacacacacacaca}, Field = {NextObject = 0xcacacacacacacaca, DescriptorType = 128 '\200', Type = 0 '\0', ReferenceCount = 678, Flags = 0 '\0', FieldFlags = 254 '�', Attribute = 255 '�', AccessByteWidth = 255 '�', Node = 0xcacacacacacacaca, BitLength = 3402287818, BaseByteOffset = 3402287818, Value = 3402287818, StartFieldBitOffset = 202 '�', AccessLength = 202 '�', ---Type to continue, or q to quit--- ResourceLength = 51914, RegionObj = 0xcacacacacacacaca, ResourceBuffer = 0xcacacacacacacaca
}, BufferField = {NextObject = 0xcacacacacacacaca, DescriptorType = 128 '\200', Type = 0 '\0', ReferenceCount = 678, Flags = 0 '\0', FieldFlags = 254 '�', Attribute = 255 '�', AccessByteWidth = 255 '�', Node = 0xcacacacacacacaca, BitLength = 3402287818, BaseByteOffset = 3402287818, Value = 3402287818, StartFieldBitOffset = 202 '�', AccessLength = 202 '�', BufferObj = 0xcacacacacacacaca}, BankField = { NextObject = 0xcacacacacacacaca, DescriptorType = 128 '\200', Type = 0 '\0', ReferenceCount = 678, Flags = 0 '\0', FieldFlags = 254 '�', Attribute = 255 '�', AccessByteWidth = 255 '�', Node = 0xcacacacacacacaca, BitLength = 3402287818, BaseByteOffset = 3402287818, Value = 3402287818, StartFieldBitOffset = 202 '�', AccessLength = 202 '�', RegionObj = 0xcacacacacacacaca, BankObj = 0xcacacacacacacaca}, IndexField = {NextObject = 0xcacacacacacacaca, DescriptorType = 128 '\200', Type = 0 '\0', ReferenceCount = 678, Flags = 0 '\0', FieldFlags = 254 '�', Attribute = 255 '�', AccessByteWidth = 255 '�', Node = 0xcacacacacacacaca, BitLength = 3402287818, BaseByteOffset = 3402287818, Value = 3402287818, StartFieldBitOffset = 202 '�', AccessLength = 202 '�', IndexObj = 0xcacacacacacacaca, DataObj = 0xcacacacacacacaca}, Notify = { NextObject = 0xcacacacacacacaca, DescriptorType = 128 '\200', Type = 0 '\0', ReferenceCount = 678, Flags = 0 '\0', ---Type to continue, or q to quit--- Node = 0xcacacacacacacaca, HandlerType = 3402287818, Handler = 0xcacacacacacacaca, Context = 0xcacacacacacacaca, Next = { 0xcacacacacacacaca, 0xcacacacacacacaca}}, AddressSpace = { NextObject = 0xcacacacacacacaca, DescriptorType = 128 '\200', Type = 0 '\0', ReferenceCount = 678, Flags = 0 '\0', SpaceId = 254 '�', HandlerFlags = 255 '�', Handler = 0xcacacacacacacaca, Node = 0xcacacacacacacaca, Context = 0xcacacacacacacaca, Setup = 0xcacacacacacacaca, RegionList = 0xcacacacacacacaca, Next = 0xcacacacacacacaca}, Reference = {NextObject = 0xcacacacacacacaca, DescriptorType = 128 '\200', Type = 0 '\0', ReferenceCount = 678, Flags = 0 '\0', Class = 254 '�', TargetType = 255 '�', Reserved = 255 '�', Object = 0xcacacacacacacaca, Node = 0xcacacacacacacaca, Where = 0xcacacacacacacaca, Value = 3402287818}, Extra = { NextObject = 0xcacacacacacacaca, DescriptorType = 128 '\200', Type = 0 '\0', ReferenceCount = 678, Flags = 0 '\0', Method_REG = 0xcacacacacacacaca, ScopeNode = 0xcacacacacacacaca, RegionContext = 0xcacacacacacacaca, AmlStart = 0xcacacacacacacaca
, AmlLength = 3402287818}, Data = {NextObject = 0xcacacacacacacaca, DescriptorType = 128 '\200', Type = 0 '\0', ReferenceCount = 678, Flags = 0 '\0', Handler = 0xcacacacacacacaca, Pointer = 0xcacacacacacacaca}, Cache = {NextObject = 0xcacacacacacacaca, DescriptorType = 128 '\200', Type = 0 '\0', ReferenceCount = 678, ---Type to continue, or q to quit--- Flags = 0 '\0', Next = 0xcacacacacacacaca}, Node = { Object = 0xcacacacacacacaca, DescriptorType = 128 '\200', Type = 0 '\0', Flags = 166 '�', OwnerId = 2 '\002', Name = {Integer = 4294966784, Ascii = "\000���"}, Parent = 0xcacacacacacacaca, Child = 0xcacacacacacacaca, Peer = 0xcacacacacacacaca}} (kgdb) p *(union acpi_operand_object *)0xfffffe0002a60080 $7 = {Common = {NextObject = 0xcacacacacacacaca, DescriptorType = 128 '\200', Type = 118 'v', ReferenceCount = 1553, Flags = 0 '\0'}, Integer = { NextObject = 0xcacacacacacacaca, DescriptorType = 128 '\200', Type = 118 'v', ReferenceCount = 1553, Flags = 0 '\0', Fill = "���", Value = 14612714913291487946}, String = {NextObject = 0xcacacacacacacaca, DescriptorType = 128 '\200', Type = 118 'v', ReferenceCount = 1553, Flags = 0 '\0', Pointer = 0xcacacacacacacaca
, Length = 3402287818}, Buffer = {NextObject = 0xcacacacacacacaca, DescriptorType = 128 '\200', Type = 118 'v', ReferenceCount = 1553, Flags = 0 '\0', Pointer = 0xcacacacacacacaca
, Length = 3402287818, AmlLength = 3402287818, AmlStart = 0xcacacacacacacaca
, Node = 0xcacacacacacacaca}, Package = {NextObject = 0xcacacacacacacaca, DescriptorType = 128 '\200', Type = 118 'v', ReferenceCount = 1553, Flags = 0 '\0', Node = 0xcacacacacacacaca, Elements = 0xcacacacacacacaca, AmlStart = 0xcacacacacacacaca
, AmlLength = 3402287818, Count = 3402287818}, Event = { NextObject = 0xcacacacacacacaca, DescriptorType = 128 '\200', Type = 118 'v', ReferenceCount = 1553, Flags = 0 '\0', OsSemaphore = 0xcacacacacacacaca}, Method = { NextObject = 0xcacacacacacacaca, DescriptorType = 128 '\200', ---Type to continue, or q to quit--- Type = 118 'v', ReferenceCount = 1553, Flags = 0 '\0', InfoFlags = 254 '�', ParamCount = 255 '�', SyncLevel = 255 '�', Mutex = 0xcacacacacacacaca, AmlStart = 0xcacacacacacacaca
, Dispatch = {Implementation = 0xcacacacacacacaca, Handler = 0xcacacacacacacaca}, AmlLength = 3402287818, ThreadCount = 202 '�', OwnerId = 202 '�'}, Mutex = { NextObject = 0xcacacacacacacaca, DescriptorType = 128 '\200', Type = 118 'v', ReferenceCount = 1553, Flags = 0 '\0', SyncLevel = 254 '�', AcquisitionDepth = 65535, OsMutex = 0xcacacacacacacaca, ThreadId = 14612714913291487946, OwnerThread = 0xcacacacacacacaca, Prev = 0xcacacacacacacaca, Next = 0xcacacacacacacaca, Node = 0xcacacacacacacaca, OriginalSyncLevel = 202 '�'}, Region = {NextObject = 0xcacacacacacacaca, DescriptorType = 128 '\200', Type = 118 'v', ReferenceCount = 1553, Flags = 0 '\0', SpaceId = 254 '�', Node = 0xcacacacacacacaca, Handler = 0xcacacacacacacaca, Next = 0xcacacacacacacaca, Address = 14612714913291487946, Length = 3402287818}, CommonNotify = { NextObject = 0xcacacacacacacaca, DescriptorType = 128 '\200', Type = 118 'v', ReferenceCount = 1553, Flags = 0 '\0', NotifyList = { 0xcacacacacacacaca, 0xcacacacacacacaca}, Handler = 0xcacacacacacacaca}, Device = {NextObject = 0xcacacacacacacaca, DescriptorType = 128 '\200', Type = 118 'v', ReferenceCount = 1553, Flags = 0 '\0', NotifyList = { ---Type to continue, or q to quit--- 0xcacacacacacacaca, 0xcacacacacacacaca}, Handler = 0xcacacacacacacaca, GpeBlock = 0xcacacacacacacaca}, PowerResource = { NextObject = 0xcacacacacacacaca, DescriptorType = 128 '\200', Type = 118 'v', ReferenceCount = 1553, Flags = 0 '\0', NotifyList = { 0xcacacacacacacaca, 0xcacacacacacacaca}, Handler = 0xcacacacacacacaca, SystemLevel = 3402287818, ResourceOrder = 3402287818}, Processor = { NextObject = 0xcacacacacacacaca, DescriptorType = 128 '\200', Type = 118 'v', ReferenceCount = 1553, Flags = 0 '\0', ProcId = 254 '�', Length = 255 '�', NotifyList = {0xcacacacacacacaca, 0xcacacacacacacaca}, Handler = 0xcacacacacacacaca, Address = 14612714913291487946}, ThermalZone = {NextObject = 0xcacacacacacacaca, DescriptorType = 128 '\200', Type = 118 'v', ReferenceCount = 1553, Flags = 0 '\0', NotifyList = { 0xcacacacacacacaca, 0xcacacacacacacaca}, Handler = 0xcacacacacacacaca}, CommonField = {NextObject = 0xcacacacacacacaca, DescriptorType = 128 '\200', Type = 118 'v', ReferenceCount = 1553, Flags = 0 '\0', FieldFlags = 254 '�', Attribute = 255 '�', AccessByteWidth = 255 '�', Node = 0xcacacacacacacaca, BitLength = 3402287818, BaseByteOffset = 3402287818, Value = 3402287818, StartFieldBitOffset = 202 '�', AccessLength = 202 '�', RegionObj = 0xcacacacacacacaca}, Field = {NextObject = 0xcacacacacacacaca, DescriptorType = 128 '\200', Type = 118 'v', ReferenceCount = 1553, Flags = 0 '\0', FieldFlags = 254 '�', Attribute = 255 '�', AccessByteWidth = 255 '�', Node = 0xcacacacacacacaca, ---Type to continue, or q to quit--- BitLength = 3402287818, BaseByteOffset = 3402287818, Value = 3402287818, StartFieldBitOffset = 202 '�', AccessLength = 202 '�', ResourceLength = 51914, RegionObj = 0xcacacacacacacaca, ResourceBuffer = 0xcacacacacacacaca
}, BufferField = {NextObject = 0xcacacacacacacaca, DescriptorType = 128 '\200', Type = 118 'v', ReferenceCount = 1553, Flags = 0 '\0', FieldFlags = 254 '�', Attribute = 255 '�', AccessByteWidth = 255 '�', Node = 0xcacacacacacacaca, BitLength = 3402287818, BaseByteOffset = 3402287818, Value = 3402287818, StartFieldBitOffset = 202 '�', AccessLength = 202 '�', BufferObj = 0xcacacacacacacaca}, BankField = { NextObject = 0xcacacacacacacaca, DescriptorType = 128 '\200', Type = 118 'v', ReferenceCount = 1553, Flags = 0 '\0', FieldFlags = 254 '�', Attribute = 255 '�', AccessByteWidth = 255 '�', Node = 0xcacacacacacacaca, BitLength = 3402287818, BaseByteOffset = 3402287818, Value = 3402287818, StartFieldBitOffset = 202 '�', AccessLength = 202 '�', RegionObj = 0xcacacacacacacaca, BankObj = 0xcacacacacacacaca}, IndexField = {NextObject = 0xcacacacacacacaca, DescriptorType = 128 '\200', Type = 118 'v', ReferenceCount = 1553, Flags = 0 '\0', FieldFlags = 254 '�', Attribute = 255 '�', AccessByteWidth = 255 '�', Node = 0xcacacacacacacaca, BitLength = 3402287818, BaseByteOffset = 3402287818, Value = 3402287818, ---Type to continue, or q to quit--- StartFieldBitOffset = 202 '�', AccessLength = 202 '�', IndexObj = 0xcacacacacacacaca, DataObj = 0xcacacacacacacaca}, Notify = { NextObject = 0xcacacacacacacaca, DescriptorType = 128 '\200', Type = 118 'v', ReferenceCount = 1553, Flags = 0 '\0', Node = 0xcacacacacacacaca, HandlerType = 3402287818, Handler = 0xcacacacacacacaca, Context = 0xcacacacacacacaca, Next = { 0xcacacacacacacaca, 0xcacacacacacacaca}}, AddressSpace = { NextObject = 0xcacacacacacacaca, DescriptorType = 128 '\200', Type = 118 'v', ReferenceCount = 1553, Flags = 0 '\0', SpaceId = 254 '�', HandlerFlags = 255 '�', Handler = 0xcacacacacacacaca, Node = 0xcacacacacacacaca, Context = 0xcacacacacacacaca, Setup = 0xcacacacacacacaca, RegionList = 0xcacacacacacacaca, Next = 0xcacacacacacacaca}, Reference = {NextObject = 0xcacacacacacacaca, DescriptorType = 128 '\200', Type = 118 'v', ReferenceCount = 1553, Flags = 0 '\0', Class = 254 '�', TargetType = 255 '�', Reserved = 255 '�', Object = 0xcacacacacacacaca, Node = 0xcacacacacacacaca, Where = 0xcacacacacacacaca, Value = 3402287818}, Extra = { NextObject = 0xcacacacacacacaca, DescriptorType = 128 '\200', Type = 118 'v', ReferenceCount = 1553, Flags = 0 '\0', Method_REG = 0xcacacacacacacaca, ScopeNode = 0xcacacacacacacaca, RegionContext = 0xcacacacacacacaca, AmlStart = 0xcacacacacacacaca
, AmlLength = 3402287818}, Data = {NextObject = 0xcacacacacacacaca, ---Type to continue, or q to quit--- DescriptorType = 128 '\200', Type = 118 'v', ReferenceCount = 1553, Flags = 0 '\0', Handler = 0xcacacacacacacaca, Pointer = 0xcacacacacacacaca}, Cache = {NextObject = 0xcacacacacacacaca, DescriptorType = 128 '\200', Type = 118 'v', ReferenceCount = 1553, Flags = 0 '\0', Next = 0xcacacacacacacaca}, Node = { Object = 0xcacacacacacacaca, DescriptorType = 128 '\200', Type = 118 'v', Flags = 17 '\021', OwnerId = 6 '\006', Name = {Integer = 4294966784, Ascii = "\000���"}, Parent = 0xcacacacacacacaca, Child = 0xcacacacacacacaca, Peer = 0xcacacacacacacaca}} BTW, I noticed the ACPI_SET_DESCRIPTOR_TYPE code is pointless, because the DescriptorType is at offset 8 from the object start and gets immediately overwritten by the next pointer. However I don't think it's a problem. Stefan From owner-freebsd-acpi@FreeBSD.ORG Mon Nov 26 11:06:22 2012 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2C7DC44F; Mon, 26 Nov 2012 11:06:22 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 425E68FC12; Mon, 26 Nov 2012 11:06:20 +0000 (UTC) Received: from porto.starpoint.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 NAA29560; Mon, 26 Nov 2012 13:06:19 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TcwW3-000LlF-41; Mon, 26 Nov 2012 13:06:19 +0200 Message-ID: <50B34D2A.7060604@FreeBSD.org> Date: Mon, 26 Nov 2012 13:06:18 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Stefan Farfeleder Subject: Re: ACPI panic References: <20121122081831.GA1483@mole.fafoe.narf.at> <50ADFD75.10709@FreeBSD.org> <50ADFFB2.1000108@FreeBSD.org> <50AE057D.8060808@FreeBSD.org> <20121125140008.GA1497@mole.fafoe.narf.at> <50B244A1.1040800@FreeBSD.org> <20121126091101.GA1469@mole.fafoe.narf.at> <50B33693.2060000@FreeBSD.org> <20121126093704.GB1469@mole.fafoe.narf.at> <50B34484.1090807@FreeBSD.org> <20121126104737.GC1469@mole.fafoe.narf.at> In-Reply-To: <20121126104737.GC1469@mole.fafoe.narf.at> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 11:06:22 -0000 on 26/11/2012 12:47 Stefan Farfeleder said the following: > BTW, I noticed the ACPI_SET_DESCRIPTOR_TYPE code is pointless, because the > DescriptorType is at offset 8 from the object start and gets immediately > overwritten by the next pointer. However I don't think it's a problem. Thank you. To make things more obvious could you please also examine the objects like this: x/9a ? -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Mon Nov 26 11:06:40 2012 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6A3E14A8 for ; Mon, 26 Nov 2012 11:06:40 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 354E88FC12 for ; Mon, 26 Nov 2012 11:06:40 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id qAQB6ePR019301 for ; Mon, 26 Nov 2012 11:06:40 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id qAQB6d9h019299 for freebsd-acpi@FreeBSD.org; Mon, 26 Nov 2012 11:06:39 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 26 Nov 2012 11:06:39 GMT Message-Id: <201211261106.qAQB6d9h019299@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-acpi@FreeBSD.org Subject: Current problem reports assigned to freebsd-acpi@FreeBSD.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 11:06:40 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/171305 acpi [acpi] acpi_tz0: _CRT value is absurd, ignored (256.0C o kern/164329 acpi [acpi] hw.acpi.thermal.tz0.temperature shows strange v o kern/163268 acpi [acpi_hp] fix driver detach in absence of CMI o kern/162859 acpi [acpi] ACPI battery/acline monitoring partialy working o kern/161715 acpi [acpi] Dell E6520 doesn't resume after ACPI suspend o kern/161713 acpi [acpi] Suspend on Dell E6520 o kern/160838 acpi [acpi] ACPI Battery Monitor Non-Functional o kern/160419 acpi [acpi_thermal] acpi_thermal kernel thread high CPU usa o kern/158689 acpi [acpi] value of sysctl hw.acpi.thermal.polling_rate ne o kern/154955 acpi [acpi] Keyboard or ACPI doesn't work on Lenovo S10-3 o kern/152438 acpi [acpi]: patch to acpi_asus(4) to add extra sysctls for o kern/152098 acpi [acpi] Lenovo T61p does not resume o i386/146715 acpi [acpi] Suspend works, resume not on a HP Probook 4510s o kern/145306 acpi [acpi]: Can't change brightness on HP ProBook 4510s o i386/143798 acpi [acpi] shutdown problem with SiS K7S5A o kern/143420 acpi [acpi] ACPI issues with Toshiba o kern/142009 acpi [acpi] [panic] Panic in AcpiNsGetAttachedObject o kern/139088 acpi [acpi] ACPI Exception: AE_AML_INFINITE_LOOP error o amd64/138210 acpi [acpi] acer aspire 5536 ACPI problems (S3, brightness, o kern/137042 acpi [acpi] hp laptop's lcd not wakes up after suspend to r o i386/136008 acpi [acpi] Dell Vostro 1310 will not shutdown (Requires us o kern/132602 acpi [acpi] ACPI Problem with Intel SS4200: System does not p kern/128634 acpi [patch] fix acpi_asus(4) in asus a6f laptop o bin/126162 acpi [acpi] ACPI autoload failed : loading required module o kern/123039 acpi [acpi] ACPI AML_BUFFER_LIMIT errors during boot a i386/122887 acpi [panic] [atkbdc] 7.0-RELEASE on IBM HS20 panics immed s kern/112544 acpi [acpi] [patch] Add High Precision Event Timer Driver f o kern/105537 acpi [acpi] problems in acpi on HP Compaq nc6320 o kern/91594 acpi [acpi] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/ o kern/73823 acpi [request] acpi / power-on by timer support o kern/56024 acpi ACPI suspend drains battery while in S3 31 problems total. From owner-freebsd-acpi@FreeBSD.ORG Mon Nov 26 11:10:57 2012 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5C7E5E42; Mon, 26 Nov 2012 11:10:57 +0000 (UTC) (envelope-from stefan@fafoe.narf.at) Received: from fep19.mx.upcmail.net (fep19.mx.upcmail.net [62.179.121.39]) by mx1.freebsd.org (Postfix) with ESMTP id 6CA088FC0C; Mon, 26 Nov 2012 11:10:56 +0000 (UTC) Received: from edge01.upcmail.net ([192.168.13.236]) by viefep19-int.chello.at (InterMail vM.8.01.05.05 201-2260-151-110-20120111) with ESMTP id <20121126111047.WNAK26940.viefep19-int.chello.at@edge01.upcmail.net>; Mon, 26 Nov 2012 12:10:47 +0100 Received: from mole.fafoe.narf.at ([80.109.55.137]) by edge01.upcmail.net with edge id UBAl1k02o2xdvHc01BAlRC; Mon, 26 Nov 2012 12:10:47 +0100 X-SourceIP: 80.109.55.137 Received: by mole.fafoe.narf.at (Postfix, from userid 1001) id B29346D449; Mon, 26 Nov 2012 12:10:45 +0100 (CET) Date: Mon, 26 Nov 2012 12:10:45 +0100 From: Stefan Farfeleder To: Andriy Gapon Subject: Re: ACPI panic Message-ID: <20121126111045.GE1469@mole.fafoe.narf.at> References: <50ADFFB2.1000108@FreeBSD.org> <50AE057D.8060808@FreeBSD.org> <20121125140008.GA1497@mole.fafoe.narf.at> <50B244A1.1040800@FreeBSD.org> <20121126091101.GA1469@mole.fafoe.narf.at> <50B33693.2060000@FreeBSD.org> <20121126093704.GB1469@mole.fafoe.narf.at> <50B34484.1090807@FreeBSD.org> <20121126104737.GC1469@mole.fafoe.narf.at> <50B34D2A.7060604@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50B34D2A.7060604@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-acpi@FreeBSD.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 11:10:57 -0000 On Mon, Nov 26, 2012 at 01:06:18PM +0200, Andriy Gapon wrote: > on 26/11/2012 12:47 Stefan Farfeleder said the following: > > BTW, I noticed the ACPI_SET_DESCRIPTOR_TYPE code is pointless, because the > > DescriptorType is at offset 8 from the object start and gets immediately > > overwritten by the next pointer. However I don't think it's a problem. > > Thank you. > To make things more obvious could you please also examine the objects like this: > x/9a > ? (kgdb) x/9a 0xfffffe0006117600 0xfffffe0006117600: 0xcacacacacacacaca 0xfffffe0006117680 0xfffffe0006117610: 0xcacacacacacacaca 0xcacacacacacacaca 0xfffffe0006117620: 0xcacacacacacacaca 0xcacacacacacacaca 0xfffffe0006117630: 0xcacacacacacacaca 0xcacacacacacacaca 0xfffffe0006117640: 0xcacacacacacacaca (kgdb) x/9a 0xfffffe0006117680 0xfffffe0006117680: 0xcacacacacacacaca 0xfffffe0002a60080 0xfffffe0006117690: 0xcacacacacacacaca 0xcacacacacacacaca 0xfffffe00061176a0: 0xcacacacacacacaca 0xcacacacacacacaca 0xfffffe00061176b0: 0xcacacacacacacaca 0xcacacacacacacaca 0xfffffe00061176c0: 0xcacacacacacacaca (kgdb) x/9a 0xfffffe0002a60080 0xfffffe0002a60080: 0xcacacacacacacaca 0xfffffe0006117680 0xfffffe0002a60090: 0xcacacacacacacaca 0xcacacacacacacaca 0xfffffe0002a600a0: 0xcacacacacacacaca 0xcacacacacacacaca 0xfffffe0002a600b0: 0xcacacacacacacaca 0xcacacacacacacaca 0xfffffe0002a600c0: 0xcacacacacacacaca Stefan From owner-freebsd-acpi@FreeBSD.ORG Mon Nov 26 11:13:49 2012 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DA5121C9; Mon, 26 Nov 2012 11:13:49 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id F2F578FC08; Mon, 26 Nov 2012 11:13:48 +0000 (UTC) Received: from porto.starpoint.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 NAA29614; Mon, 26 Nov 2012 13:13:47 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TcwdH-000Lle-2b; Mon, 26 Nov 2012 13:13:47 +0200 Message-ID: <50B34EEA.4000209@FreeBSD.org> Date: Mon, 26 Nov 2012 13:13:46 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Stefan Farfeleder Subject: Re: ACPI panic References: <20121122081831.GA1483@mole.fafoe.narf.at> <50ADFD75.10709@FreeBSD.org> <50ADFFB2.1000108@FreeBSD.org> <50AE057D.8060808@FreeBSD.org> <20121125140008.GA1497@mole.fafoe.narf.at> <50B244A1.1040800@FreeBSD.org> <20121126091101.GA1469@mole.fafoe.narf.at> <50B33693.2060000@FreeBSD.org> <20121126093704.GB1469@mole.fafoe.narf.at> <50B34484.1090807@FreeBSD.org> <20121126104737.GC1469@mole.fafoe.narf.at> In-Reply-To: <20121126104737.GC1469@mole.fafoe.narf.at> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 11:13:49 -0000 Also, I've just realized that the check is racy... Could you please move the whole check block (between and excluding AcpiUtAcquireMutex and AcpiUtReleaseMutex) down right below the following lines: Status = AcpiUtAcquireMutex (ACPI_MTX_CACHES); if (ACPI_FAILURE (Status)) { return (Status); } Thank you. -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Mon Nov 26 11:15:40 2012 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C7FCA256; Mon, 26 Nov 2012 11:15:40 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id DEC0E8FC15; Mon, 26 Nov 2012 11:15:39 +0000 (UTC) Received: from porto.starpoint.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 NAA29661; Mon, 26 Nov 2012 13:15:38 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Tcwf4-000Lls-7h; Mon, 26 Nov 2012 13:15:38 +0200 Message-ID: <50B34F59.2030006@FreeBSD.org> Date: Mon, 26 Nov 2012 13:15:37 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Stefan Farfeleder Subject: Re: ACPI panic References: <50ADFFB2.1000108@FreeBSD.org> <50AE057D.8060808@FreeBSD.org> <20121125140008.GA1497@mole.fafoe.narf.at> <50B244A1.1040800@FreeBSD.org> <20121126091101.GA1469@mole.fafoe.narf.at> <50B33693.2060000@FreeBSD.org> <20121126093704.GB1469@mole.fafoe.narf.at> <50B34484.1090807@FreeBSD.org> <20121126104737.GC1469@mole.fafoe.narf.at> <50B34D2A.7060604@FreeBSD.org> <20121126111045.GE1469@mole.fafoe.narf.at> In-Reply-To: <20121126111045.GE1469@mole.fafoe.narf.at> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 11:15:40 -0000 on 26/11/2012 13:10 Stefan Farfeleder said the following: > On Mon, Nov 26, 2012 at 01:06:18PM +0200, Andriy Gapon wrote: >> on 26/11/2012 12:47 Stefan Farfeleder said the following: >>> BTW, I noticed the ACPI_SET_DESCRIPTOR_TYPE code is pointless, because the >>> DescriptorType is at offset 8 from the object start and gets immediately >>> overwritten by the next pointer. However I don't think it's a problem. >> >> Thank you. >> To make things more obvious could you please also examine the objects like this: >> x/9a >> ? > > (kgdb) x/9a 0xfffffe0006117600 > 0xfffffe0006117600: 0xcacacacacacacaca 0xfffffe0006117680 > 0xfffffe0006117610: 0xcacacacacacacaca 0xcacacacacacacaca > 0xfffffe0006117620: 0xcacacacacacacaca 0xcacacacacacacaca > 0xfffffe0006117630: 0xcacacacacacacaca 0xcacacacacacacaca > 0xfffffe0006117640: 0xcacacacacacacaca > (kgdb) x/9a 0xfffffe0006117680 > 0xfffffe0006117680: 0xcacacacacacacaca 0xfffffe0002a60080 > 0xfffffe0006117690: 0xcacacacacacacaca 0xcacacacacacacaca > 0xfffffe00061176a0: 0xcacacacacacacaca 0xcacacacacacacaca > 0xfffffe00061176b0: 0xcacacacacacacaca 0xcacacacacacacaca > 0xfffffe00061176c0: 0xcacacacacacacaca > (kgdb) x/9a 0xfffffe0002a60080 > 0xfffffe0002a60080: 0xcacacacacacacaca 0xfffffe0006117680 > 0xfffffe0002a60090: 0xcacacacacacacaca 0xcacacacacacacaca > 0xfffffe0002a600a0: 0xcacacacacacacaca 0xcacacacacacacaca > 0xfffffe0002a600b0: 0xcacacacacacacaca 0xcacacacacacacaca > 0xfffffe0002a600c0: 0xcacacacacacacaca So this looks like use after free is unlikely. It's probably a double-free that was missed in the race which I've just realized. -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Tue Nov 27 16:06:37 2012 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7A681FA2 for ; Tue, 27 Nov 2012 16:06:37 +0000 (UTC) (envelope-from vladimir@shumbely.com) Received: from forward1h.mail.yandex.net (forward1h.mail.yandex.net [IPv6:2a02:6b8:0:f05::10]) by mx1.freebsd.org (Postfix) with ESMTP id E44B68FC18 for ; Tue, 27 Nov 2012 16:06:36 +0000 (UTC) Received: from smtp4h.mail.yandex.net (smtp4h.mail.yandex.net [84.201.186.21]) by forward1h.mail.yandex.net (Yandex) with ESMTP id 47C9C9E0343 for ; Tue, 27 Nov 2012 20:06:35 +0400 (MSK) Received: from smtp4h.mail.yandex.net (localhost [127.0.0.1]) by smtp4h.mail.yandex.net (Yandex) with ESMTP id 24DB12C0110 for ; Tue, 27 Nov 2012 20:06:35 +0400 (MSK) Received: from 80-67-52-95.baltnet.ru (80-67-52-95.baltnet.ru [95.52.67.80]) by smtp4h.mail.yandex.net (nwsmtp/Yandex) with ESMTP id 6YGm9Mb4-6YGO9S4r; Tue, 27 Nov 2012 20:06:34 +0400 Date: Tue, 27 Nov 2012 19:06:34 +0300 From: Vladimir Vasilenko To: freebsd-acpi@FreeBSD.org Subject: PC can't wake up after sleep Message-Id: <20121127190634.99968f4bae7601b6f7326f68@shumbely.com> Organization: I'm a consultant X-Mailer: Sylpheed 3.2.0 (GTK+ 2.24.6; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 16:06:37 -0000 Hello, my PC can't wake up after acpiconf -sN: the monitor is off, power supply halted, power indicator begin blink. When I press a power button that power supply triggered on 5 second and stopped again. Power indicator continue blink but if I press power button again so power supply just not started. MB: Asus M2N-E CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ (2210.23-MHz K8-class CPU) Video: nVidia GeForce 7300 GT sysctl hw | grep acpi hw.acpi.supported_sleep_state: S1 S3 S4 S5 hw.acpi.power_button_state: S5 hw.acpi.sleep_button_state: S1 hw.acpi.lid_switch_state: NONE hw.acpi.standby_state: S1 hw.acpi.suspend_state: S3 hw.acpi.sleep_delay: 1 hw.acpi.s4bios: 0 hw.acpi.verbose: 0 hw.acpi.disable_on_reboot: 0 hw.acpi.handle_reboot: 1 hw.acpi.reset_video: 1 hw.acpi.cpu.cx_lowest: C1 hw.acpi.thermal.min_runtime: 0 hw.acpi.thermal.polling_rate: 10 hw.acpi.thermal.user_override: 0 hw.acpi.thermal.tz0.temperature: 40,0C hw.acpi.thermal.tz0.active: -1 hw.acpi.thermal.tz0.passive_cooling: 1 hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0._PSV: 73,0C hw.acpi.thermal.tz0._HOT: -1 hw.acpi.thermal.tz0._CRT: 75,0C hw.acpi.thermal.tz0._ACx: 73,0C -1 -1 -1 -1 -1 -1 -1 -1 -1 hw.acpi.thermal.tz0._TC1: 4 hw.acpi.thermal.tz0._TC2: 3 hw.acpi.thermal.tz0._TSP: 60 What can I do? Best regards, Vladimir. -- Vladimir Vasilenko , Kaliningrad, Russia. JID: vladimir@shumbely.com http://shumbely.com Cell ph: +7 921 1033434 From owner-freebsd-acpi@FreeBSD.ORG Thu Nov 29 08:46:37 2012 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B41A03E5; Thu, 29 Nov 2012 08:46:37 +0000 (UTC) (envelope-from stefan@fafoe.narf.at) Received: from fep19.mx.upcmail.net (fep19.mx.upcmail.net [62.179.121.39]) by mx1.freebsd.org (Postfix) with ESMTP id C4BB98FC16; Thu, 29 Nov 2012 08:46:35 +0000 (UTC) Received: from edge04.upcmail.net ([192.168.13.239]) by viefep19-int.chello.at (InterMail vM.8.01.05.05 201-2260-151-110-20120111) with ESMTP id <20121129084628.QFBW26940.viefep19-int.chello.at@edge04.upcmail.net>; Thu, 29 Nov 2012 09:46:28 +0100 Received: from mole.fafoe.narf.at ([80.109.55.137]) by edge04.upcmail.net with edge id VLmU1k00M2xdvHc04LmURT; Thu, 29 Nov 2012 09:46:28 +0100 X-SourceIP: 80.109.55.137 Received: by mole.fafoe.narf.at (Postfix, from userid 1001) id 07CAE6D465; Thu, 29 Nov 2012 09:46:28 +0100 (CET) Date: Thu, 29 Nov 2012 09:46:27 +0100 From: Stefan Farfeleder To: Andriy Gapon Subject: Re: ACPI panic Message-ID: <20121129084627.GA1450@mole.fafoe.narf.at> References: <50ADFFB2.1000108@FreeBSD.org> <50AE057D.8060808@FreeBSD.org> <20121125140008.GA1497@mole.fafoe.narf.at> <50B244A1.1040800@FreeBSD.org> <20121126091101.GA1469@mole.fafoe.narf.at> <50B33693.2060000@FreeBSD.org> <20121126093704.GB1469@mole.fafoe.narf.at> <50B34484.1090807@FreeBSD.org> <20121126104737.GC1469@mole.fafoe.narf.at> <50B34EEA.4000209@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50B34EEA.4000209@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-acpi@FreeBSD.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 08:46:37 -0000 On Mon, Nov 26, 2012 at 01:13:46PM +0200, Andriy Gapon wrote: > > Also, I've just realized that the check is racy... > Could you please move the whole check block (between and excluding > AcpiUtAcquireMutex and AcpiUtReleaseMutex) down right below the following lines: > > Status = AcpiUtAcquireMutex (ACPI_MTX_CACHES); > if (ACPI_FAILURE (Status)) > { > return (Status); > } Sorry for the delay. I'm now running the patch below. I still got the cycle panic, this time with a 4-objects cycle. It looks like an object gets released twice but I don't understand why the "freeing a free object" check fails to trigger. Stefan Index: components/utilities/utcache.c =================================================================== --- components/utilities/utcache.c (revision 243234) +++ components/utilities/utcache.c (working copy) @@ -244,6 +244,28 @@ return (Status); } + char *Curr; + char *Next; + int Depth; + Depth = Cache->CurrentDepth; + Next = Cache->ListHead; + while (Next) + { + Curr = Next; + Next = *(ACPI_CAST_INDIRECT_PTR (char, + &(((char *) Curr)[Cache->LinkOffset]))); + if (*(const unsigned char *) Curr != 0xCA) { + panic("detected use after free %p\n", Curr); + } + if (Object == Curr) { + panic("freeing a free object %p", Object); + } + Depth--; + if (Depth < 0) { + panic("cycle in a cache list"); + } + } + /* Mark the object as cached */ ACPI_MEMSET (Object, 0xCA, Cache->ObjectSize); @@ -312,6 +334,10 @@ Cache->CurrentDepth--; + if (*(const unsigned char *) Object != 0xCA) { + panic("detected use after free %p\n", Object); + } + ACPI_MEM_TRACKING (Cache->Hits++); ACPI_DEBUG_PRINT ((ACPI_DB_EXEC, "Object %p from %s cache\n", Object, Cache->ListName)); From owner-freebsd-acpi@FreeBSD.ORG Thu Nov 29 15:29:17 2012 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D868A43D; Thu, 29 Nov 2012 15:29:17 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id EBD0A8FC12; Thu, 29 Nov 2012 15:29:16 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA12122; Thu, 29 Nov 2012 17:29:15 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <50B77F4B.8070701@FreeBSD.org> Date: Thu, 29 Nov 2012 17:29:15 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: sbruno@FreeBSD.org Subject: Re: [rfc] bind curthread to target cpu for _CST change notification References: <50AE3C66.2050207@FreeBSD.org> <1353872249.20189.3.camel@powernoodle> In-Reply-To: <1353872249.20189.3.camel@powernoodle> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org, Sean Bruno X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 15:29:17 -0000 Turned out not be so rosy... on 25/11/2012 21:37 Sean Bruno said the following: > > > On Thu, 2012-11-22 at 16:53 +0200, Andriy Gapon wrote: >> I would like to propose the following patch which should kill two birds with one >> stone: >> >> - avoid race in acpi_cpu_cx_cst if more than one notifications occur in a rapid >> succession for the same CPU and end up being concurrently handled by ACPI taskqeue >> threads critical_enter was a very a bad idea and can't be used here because acpi_cpu_cx_cst acquires blockable locks and does waiting memory allocations. Unfortunately, it was not immediately obvious to me. >> - avoid race acpi_cpu_cx_cst and acpi_cpu_idle where the latter may access >> resources being updated by the former sched_bind wouldn't guarantee that this would work if critical_enter is not used, because the current thread may block and the idle thread may get to run. >> What do you think? >> >> Index: sys/dev/acpica/acpi_cpu.c >> =================================================================== >> --- sys/dev/acpica/acpi_cpu.c (revision 242854) >> +++ sys/dev/acpica/acpi_cpu.c (working copy) >> @@ -1047,7 +1047,16 @@ >> return; >> >> /* Update the list of Cx states. */ >> + thread_lock(curthread); >> + sched_bind(curthread, sc->cpu_pcpu->pc_cpuid); >> + thread_unlock(curthread); >> + critical_enter(); >> acpi_cpu_cx_cst(sc); >> + critical_exit(); >> + thread_lock(curthread); >> + sched_unbind(curthread); >> + thread_unlock(curthread); >> + >> acpi_cpu_cx_list(sc); >> >> ACPI_SERIAL_BEGIN(cpu); >> > > Ack. This looks appropriate to me. I am working on an alternative approach to these two issues. Thank you. -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Thu Nov 29 21:43:55 2012 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8C6939A4; Thu, 29 Nov 2012 21:43:55 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 811848FC0C; Thu, 29 Nov 2012 21:43:53 +0000 (UTC) Received: from porto.starpoint.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 XAA14483; Thu, 29 Nov 2012 23:43:52 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TeBtg-0001jA-KX; Thu, 29 Nov 2012 23:43:52 +0200 Message-ID: <50B7D717.4030402@FreeBSD.org> Date: Thu, 29 Nov 2012 23:43:51 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Stefan Farfeleder Subject: Re: ACPI panic References: <50ADFFB2.1000108@FreeBSD.org> <50AE057D.8060808@FreeBSD.org> <20121125140008.GA1497@mole.fafoe.narf.at> <50B244A1.1040800@FreeBSD.org> <20121126091101.GA1469@mole.fafoe.narf.at> <50B33693.2060000@FreeBSD.org> <20121126093704.GB1469@mole.fafoe.narf.at> <50B34484.1090807@FreeBSD.org> <20121126104737.GC1469@mole.fafoe.narf.at> <50B34EEA.4000209@FreeBSD.org> <20121129084627.GA1450@mole.fafoe.narf.at> In-Reply-To: <20121129084627.GA1450@mole.fafoe.narf.at> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 21:43:55 -0000 on 29/11/2012 10:46 Stefan Farfeleder said the following: > On Mon, Nov 26, 2012 at 01:13:46PM +0200, Andriy Gapon wrote: >> >> Also, I've just realized that the check is racy... >> Could you please move the whole check block (between and excluding >> AcpiUtAcquireMutex and AcpiUtReleaseMutex) down right below the following lines: >> >> Status = AcpiUtAcquireMutex (ACPI_MTX_CACHES); >> if (ACPI_FAILURE (Status)) >> { >> return (Status); >> } > > Sorry for the delay. I'm now running the patch below. I still got the > cycle panic, this time with a 4-objects cycle. It looks like an object > gets released twice but I don't understand why the "freeing a free > object" check fails to trigger. Hmmm... Another bug-catching patch before I start questioning my ability to understand the code. index 59ecf21..1687c75b 100644 --- a/sys/contrib/dev/acpica/components/utilities/utcache.c +++ b/sys/contrib/dev/acpica/components/utilities/utcache.c @@ -238,6 +238,8 @@ AcpiOsReleaseObject ( else { + if (AcpiGbl_MutexInfo[ACPI_MTX_CACHES].ThreadId == AcpiOsGetThreadId ()) + panic("ACPI_MTX_CACHES acquired recursively"); Status = AcpiUtAcquireMutex (ACPI_MTX_CACHES); if (ACPI_FAILURE (Status)) { @@ -311,6 +313,8 @@ AcpiOsAcquireObject ( return (NULL); } + if (AcpiGbl_MutexInfo[ACPI_MTX_CACHES].ThreadId == AcpiOsGetThreadId ()) + panic("ACPI_MTX_CACHES acquired recursively"); Status = AcpiUtAcquireMutex (ACPI_MTX_CACHES); if (ACPI_FAILURE (Status)) { > Stefan > > Index: components/utilities/utcache.c > =================================================================== > --- components/utilities/utcache.c (revision 243234) > +++ components/utilities/utcache.c (working copy) > @@ -244,6 +244,28 @@ > return (Status); > } > > + char *Curr; > + char *Next; > + int Depth; > + Depth = Cache->CurrentDepth; > + Next = Cache->ListHead; > + while (Next) > + { > + Curr = Next; > + Next = *(ACPI_CAST_INDIRECT_PTR (char, > + &(((char *) Curr)[Cache->LinkOffset]))); > + if (*(const unsigned char *) Curr != 0xCA) { > + panic("detected use after free %p\n", Curr); > + } > + if (Object == Curr) { > + panic("freeing a free object %p", Object); > + } > + Depth--; > + if (Depth < 0) { > + panic("cycle in a cache list"); > + } > + } > + > /* Mark the object as cached */ > > ACPI_MEMSET (Object, 0xCA, Cache->ObjectSize); > @@ -312,6 +334,10 @@ > > Cache->CurrentDepth--; > > + if (*(const unsigned char *) Object != 0xCA) { > + panic("detected use after free %p\n", Object); > + } > + > ACPI_MEM_TRACKING (Cache->Hits++); > ACPI_DEBUG_PRINT ((ACPI_DB_EXEC, > "Object %p from %s cache\n", Object, Cache->ListName)); > Just in case: this is exactly what I had in mind. -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Fri Nov 30 11:14:40 2012 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E754BF8D; Fri, 30 Nov 2012 11:14:40 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id D6C428FC0C; Fri, 30 Nov 2012 11:14:39 +0000 (UTC) Received: from porto.starpoint.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 NAA19870; Fri, 30 Nov 2012 13:14:38 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TeOYH-0002cn-UG; Fri, 30 Nov 2012 13:14:38 +0200 Message-ID: <50B8951D.1000609@FreeBSD.org> Date: Fri, 30 Nov 2012 13:14:37 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: freebsd-acpi@FreeBSD.org Subject: Re: [rfc] bind curthread to target cpu for _CST change notification References: <50AE3C66.2050207@FreeBSD.org> <1353872249.20189.3.camel@powernoodle> <50B77F4B.8070701@FreeBSD.org> In-Reply-To: <50B77F4B.8070701@FreeBSD.org> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Sean Bruno X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 11:14:41 -0000 on 29/11/2012 17:29 Andriy Gapon said the following: > I am working on an alternative approach to these two issues. Here is my WIP: http://people.freebsd.org/~avg/acpi_cpu_notify.2.diff -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Sat Dec 1 09:02:59 2012 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 70BE61D8; Sat, 1 Dec 2012 09:02:59 +0000 (UTC) (envelope-from dumbbell@FreeBSD.org) Received: from mail.made4.biz (unknown [IPv6:2001:41d0:1:7018::1:3]) by mx1.freebsd.org (Postfix) with ESMTP id 066E88FC0C; Sat, 1 Dec 2012 09:02:59 +0000 (UTC) Received: from [2a01:e35:8b20:ae00:290:f5ff:fe9d:b78c] (helo=magellan.dumbbell.fr) by mail.made4.biz with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1TeiyP-000D8L-Jv; Sat, 01 Dec 2012 10:02:58 +0100 Message-ID: <50B9C7B6.1040306@FreeBSD.org> Date: Sat, 01 Dec 2012 10:02:46 +0100 From: =?ISO-8859-1?Q?Jean-S=E9bastien_P=E9dron?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Andriy Gapon Subject: Re: [rfc] bind curthread to target cpu for _CST change notification References: <50AE3C66.2050207@FreeBSD.org> <1353872249.20189.3.camel@powernoodle> <50B77F4B.8070701@FreeBSD.org> <50B8951D.1000609@FreeBSD.org> In-Reply-To: <50B8951D.1000609@FreeBSD.org> X-Enigmail-Version: 1.4.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigFECCC3B61247D10FDDE0689F" Cc: freebsd-acpi@FreeBSD.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Dec 2012 09:02:59 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigFECCC3B61247D10FDDE0689F Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 30.11.2012 12:14, Andriy Gapon wrote: > Here is my WIP: > http://people.freebsd.org/~avg/acpi_cpu_notify.2.diff Hi Andriy! I tried your last patch and it fixed a page fault I had since r243404 (I couldn't investigate the problem before this week-end). This page fault corresponds to the point #2 of your patch ("avoid race acpi_cpu_cx_cst and acpi_cpu_idle"). In my case, acpi_cpu_cx_cst is triggered every 10 seconds (I don't know if it's expected). This frees cx_ptr->p_lvlx each time (new in r243404), and concurrently, CPU_GET_REG(cx_next->p_lvlx, 1) causes the page fault in acpi_cpu_idle().= By the way, should _CST appear in a dump from acpidump(8)? Thanks a lot! --=20 Jean-S=E9bastien P=E9dron --------------enigFECCC3B61247D10FDDE0689F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEUEARECAAYFAlC5x8AACgkQa+xGJsFYOlMw0QCUCPSRmdb7WGxW3WKjU3OhduJp CACg2sq4hCa6OKsyIE/D1+wHPvkxF80= =Sazz -----END PGP SIGNATURE----- --------------enigFECCC3B61247D10FDDE0689F-- From owner-freebsd-acpi@FreeBSD.ORG Sat Dec 1 09:10:04 2012 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AC89D30C; Sat, 1 Dec 2012 09:10:04 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id C5B978FC08; Sat, 1 Dec 2012 09:10:03 +0000 (UTC) Received: from porto.starpoint.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 LAA28130; Sat, 01 Dec 2012 11:10:02 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Tej5G-0004zI-7b; Sat, 01 Dec 2012 11:10:02 +0200 Message-ID: <50B9C968.70804@FreeBSD.org> Date: Sat, 01 Dec 2012 11:10:00 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Jean-S=E9bastien_P=E9dron?= Subject: Re: [rfc] bind curthread to target cpu for _CST change notification References: <50AE3C66.2050207@FreeBSD.org> <1353872249.20189.3.camel@powernoodle> <50B77F4B.8070701@FreeBSD.org> <50B8951D.1000609@FreeBSD.org> <50B9C7B6.1040306@FreeBSD.org> In-Reply-To: <50B9C7B6.1040306@FreeBSD.org> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-acpi@FreeBSD.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Dec 2012 09:10:04 -0000 on 01/12/2012 11:02 Jean-Sébastien Pédron said the following: > On 30.11.2012 12:14, Andriy Gapon wrote: >> Here is my WIP: http://people.freebsd.org/~avg/acpi_cpu_notify.2.diff > > Hi Andriy! > > I tried your last patch and it fixed a page fault I had since r243404 (I > couldn't investigate the problem before this week-end). > > This page fault corresponds to the point #2 of your patch ("avoid race > acpi_cpu_cx_cst and acpi_cpu_idle"). In my case, acpi_cpu_cx_cst is > triggered every 10 seconds (I don't know if it's expected). This frees > cx_ptr->p_lvlx each time (new in r243404), and concurrently, > CPU_GET_REG(cx_next->p_lvlx, 1) causes the page fault in acpi_cpu_idle(). Thank you for testing! I will commit this patch soon. > By the way, should _CST appear in a dump from acpidump(8)? Yes, it depends... :-) _CST could be defined in a dynamically loadable region. If you do not see _CST in the DSDT but see Load() calls, then that's the most likely explanation. -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Sat Dec 1 09:16:03 2012 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4D56435F; Sat, 1 Dec 2012 09:16:03 +0000 (UTC) (envelope-from dumbbell@FreeBSD.org) Received: from mail.made4.biz (unknown [IPv6:2001:41d0:1:7018::1:3]) by mx1.freebsd.org (Postfix) with ESMTP id 078DB8FC08; Sat, 1 Dec 2012 09:16:03 +0000 (UTC) Received: from [2a01:e35:8b20:ae00:290:f5ff:fe9d:b78c] (helo=magellan.dumbbell.fr) by mail.made4.biz with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1TejB3-000DQV-LM; Sat, 01 Dec 2012 10:16:02 +0100 Message-ID: <50B9CACB.8030903@FreeBSD.org> Date: Sat, 01 Dec 2012 10:15:55 +0100 From: =?ISO-8859-1?Q?Jean-S=E9bastien_P=E9dron?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Andriy Gapon Subject: Re: [rfc] bind curthread to target cpu for _CST change notification References: <50AE3C66.2050207@FreeBSD.org> <1353872249.20189.3.camel@powernoodle> <50B77F4B.8070701@FreeBSD.org> <50B8951D.1000609@FreeBSD.org> <50B9C7B6.1040306@FreeBSD.org> <50B9C968.70804@FreeBSD.org> In-Reply-To: <50B9C968.70804@FreeBSD.org> X-Enigmail-Version: 1.4.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig9BB5F127611747F5FF83F896" Cc: freebsd-acpi@FreeBSD.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Dec 2012 09:16:03 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig9BB5F127611747F5FF83F896 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 01.12.2012 10:10, Andriy Gapon wrote: > on 01/12/2012 11:02 Jean-S=E9bastien P=E9dron said the following: >> By the way, should _CST appear in a dump from acpidump(8)? >=20 > Yes, it depends... :-) > _CST could be defined in a dynamically loadable region. If you do not = see > _CST in the DSDT but see Load() calls, then that's the most likely expl= anation. How do I see these Load() calls? Are they related to the ACPI_LV_LOAD level in debug.acpi.level? --=20 Jean-S=E9bastien P=E9dron --------------enig9BB5F127611747F5FF83F896 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlC5ytEACgkQa+xGJsFYOlPK6ACeKdueVq83SDGw+6ZJuIuElV26 w1EAni+OqrG/UGtqnofXCubP8YghkUrC =YOk9 -----END PGP SIGNATURE----- --------------enig9BB5F127611747F5FF83F896-- From owner-freebsd-acpi@FreeBSD.ORG Sat Dec 1 10:58:25 2012 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2D7D5D95; Sat, 1 Dec 2012 10:58:25 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 3FE818FC08; Sat, 1 Dec 2012 10:58:24 +0000 (UTC) Received: from porto.starpoint.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 MAA28522; Sat, 01 Dec 2012 12:58:22 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Tekm6-00055w-5V; Sat, 01 Dec 2012 12:58:22 +0200 Message-ID: <50B9E2CB.3010002@FreeBSD.org> Date: Sat, 01 Dec 2012 12:58:19 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Jean-S=E9bastien_P=E9dron?= Subject: Re: [rfc] bind curthread to target cpu for _CST change notification References: <50AE3C66.2050207@FreeBSD.org> <1353872249.20189.3.camel@powernoodle> <50B77F4B.8070701@FreeBSD.org> <50B8951D.1000609@FreeBSD.org> <50B9C7B6.1040306@FreeBSD.org> <50B9C968.70804@FreeBSD.org> <50B9CACB.8030903@FreeBSD.org> In-Reply-To: <50B9CACB.8030903@FreeBSD.org> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-acpi@FreeBSD.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Dec 2012 10:58:25 -0000 on 01/12/2012 11:15 Jean-Sébastien Pédron said the following: > On 01.12.2012 10:10, Andriy Gapon wrote: >> on 01/12/2012 11:02 Jean-Sébastien Pédron said the following: >>> By the way, should _CST appear in a dump from acpidump(8)? >> >> Yes, it depends... :-) _CST could be defined in a dynamically loadable >> region. If you do not see _CST in the DSDT but see Load() calls, then >> that's the most likely explanation. > > How do I see these Load() calls? Are they related to the ACPI_LV_LOAD level > in debug.acpi.level? acpidump -dt > somefile.asl vi somefile.asl /Load :-) -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Sat Dec 1 11:43:24 2012 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4F050319; Sat, 1 Dec 2012 11:43:24 +0000 (UTC) (envelope-from dumbbell@FreeBSD.org) Received: from mail.made4.biz (unknown [IPv6:2001:41d0:1:7018::1:3]) by mx1.freebsd.org (Postfix) with ESMTP id D5E0C8FC16; Sat, 1 Dec 2012 11:43:23 +0000 (UTC) Received: from [2a01:e35:8b20:ae00:290:f5ff:fe9d:b78c] (helo=magellan.dumbbell.fr) by mail.made4.biz with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1TelTe-000GYI-K1; Sat, 01 Dec 2012 12:43:23 +0100 Message-ID: <50B9ED54.4010809@FreeBSD.org> Date: Sat, 01 Dec 2012 12:43:16 +0100 From: =?ISO-8859-1?Q?Jean-S=E9bastien_P=E9dron?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Andriy Gapon Subject: Re: [rfc] bind curthread to target cpu for _CST change notification References: <50AE3C66.2050207@FreeBSD.org> <1353872249.20189.3.camel@powernoodle> <50B77F4B.8070701@FreeBSD.org> <50B8951D.1000609@FreeBSD.org> <50B9C7B6.1040306@FreeBSD.org> <50B9C968.70804@FreeBSD.org> <50B9CACB.8030903@FreeBSD.org> <50B9E2CB.3010002@FreeBSD.org> In-Reply-To: <50B9E2CB.3010002@FreeBSD.org> X-Enigmail-Version: 1.4.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigEB22CA24BFAC3E7E0B1A4900" Cc: freebsd-acpi@FreeBSD.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Dec 2012 11:43:24 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigEB22CA24BFAC3E7E0B1A4900 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 01.12.2012 11:58, Andriy Gapon wrote: > on 01/12/2012 11:15 Jean-S=E9bastien P=E9dron said the following: >> On 01.12.2012 10:10, Andriy Gapon wrote: >>> on 01/12/2012 11:02 Jean-S=E9bastien P=E9dron said the following: >>>> By the way, should _CST appear in a dump from acpidump(8)? >>> >>> Yes, it depends... :-) _CST could be defined in a dynamically loadabl= e >>> region. If you do not see _CST in the DSDT but see Load() calls, the= n >>> that's the most likely explanation. >> >> How do I see these Load() calls? Are they related to the ACPI_LV_LOAD = level >> in debug.acpi.level? >=20 > acpidump -dt > somefile.asl > vi somefile.asl > /Load >=20 > :-) Right :) Yes, there're Load() calls: ... Load (CST0, HC0) ... Thank you! --=20 Jean-S=E9bastien P=E9dron --------------enigEB22CA24BFAC3E7E0B1A4900 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlC57VoACgkQa+xGJsFYOlOCBgCglrAtK/1kTQbCJg4WEtv+yvUM cpIAn0E7qSxj8V0W6WhxXmy68fjjlTdP =3xew -----END PGP SIGNATURE----- --------------enigEB22CA24BFAC3E7E0B1A4900--