From owner-freebsd-acpi@FreeBSD.ORG Thu Nov 3 15:43:24 2005 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A5B0016A41F; Thu, 3 Nov 2005 15:43:24 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail5.speedfactory.net [66.23.216.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id F2A5043D45; Thu, 3 Nov 2005 15:43:23 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 1306560 for multiple; Thu, 03 Nov 2005 10:41:22 -0500 Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id jA3FhHjv065953; Thu, 3 Nov 2005 10:43:17 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-acpi@freebsd.org Date: Thu, 3 Nov 2005 10:43:10 -0500 User-Agent: KMail/1.8.2 References: <971FCB6690CD0E4898387DBF7552B90E0346CAFB@orsmsx403.amr.corp.intel.com> <20051103142446.GA1787@flame.pc> <20051103144013.GA43086@peter.osted.lan> In-Reply-To: <20051103144013.GA43086@peter.osted.lan> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200511031043.13285.jhb@freebsd.org> X-Spam-Status: No, score=-2.8 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=100 Cc: Peter Holm , freebsd-current@freebsd.org, Giorgos Keramidas , jkim@freebsd.org, robert.moore@intel.com Subject: Re: Panic on boot with new ACPI-CA X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2005 15:43:25 -0000 On Thursday 03 November 2005 09:40 am, Peter Holm wrote: > On Thu, Nov 03, 2005 at 04:24:46PM +0200, Giorgos Keramidas wrote: > > On 2005-11-03 03:47, Giorgos Keramidas wrote: > > >On 2005-11-02 17:03, Nate Lawson wrote: > > >> As I mentioned to Jung-uk, the problem is likely an error in > > >> acpi-ca modifying memory after it has freed it. The way to > > >> track this down is to enable memguard(9). See the man page for > > >> info. You need to add options DEBUG_MEMGUARD to your kernel, > > >> set the malloc type to watch to M_ACPICA, and rebuild your > > >> kernel and modules. Memguard sets page permissions so we can > > >> catch the culprit who is modifying the memory. > > > > > > This is exactly the messgae printed on my console at panic time > > > -- of memory modified after free. I'm building a kernel with > > > MEMGUARD now, but it's probably going to be a bit hard to get a > > > kernel dump, because the panic happens before disks are > > > available and I don't have a serial console here. > > > > This is definitely something that is ACPI-related. I updated my > > sources to the last commit before the start of the ACPI import: > > > > build@flame:/home/build/src$ cvs -qR up -APd -D '2005/11/01 22:00:00 > > UTC' > > > > Rebuilt everything and I see no panics now. > > > > I'll use the watchpoint trick Nate posted when I have a new build > > to test. > > I've had the same problem with two of my boxes. Here's the result of a > watchpoint: > > http://people.freebsd.org/~pho/stress/log/acpi.html > > I too came to the conclusion that the damage happened between > > 2005-11-01 22:00:00 UTC OK > 2005-11-01 22:45:00 UTC panic Does this diff make a difference perhaps? Index: acpi_resource.c =================================================================== RCS file: /usr/cvs/src/sys/dev/acpica/acpi_resource.c,v retrieving revision 1.35 diff -u -r1.35 acpi_resource.c --- acpi_resource.c 11 Sep 2005 18:39:01 -0000 1.35 +++ acpi_resource.c 3 Nov 2005 15:42:14 -0000 @@ -168,6 +168,7 @@ /* Fetch the device's current resources. */ buf.Length = ACPI_ALLOCATE_BUFFER; + buf.Pointer = NULL; if (ACPI_FAILURE((status = AcpiGetCurrentResources(handle, &buf)))) { if (status != AE_NOT_FOUND) printf("can't fetch resources for %s - %s\n", -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org