From owner-freebsd-acpi@FreeBSD.ORG Thu Nov 3 15:33:34 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 706DA16A420 for ; Thu, 3 Nov 2005 15:33:34 +0000 (GMT) (envelope-from shoesoft@gmx.net) Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 47EF243D75 for ; Thu, 3 Nov 2005 15:33:29 +0000 (GMT) (envelope-from shoesoft@gmx.net) Received: (qmail invoked by alias); 03 Nov 2005 15:33:28 -0000 Received: from fwswe.rise-s.com (EHLO dhcp151.swe) [83.65.168.194] by mail.gmx.net (mp004) with SMTP; 03 Nov 2005 16:33:28 +0100 X-Authenticated: #16703784 From: Stefan Ehmann To: Giorgos Keramidas In-Reply-To: <20051103142446.GA1787@flame.pc> References: <971FCB6690CD0E4898387DBF7552B90E0346CAFB@orsmsx403.amr.corp.intel.com> <20051103.094643.74756456.haro@h4.dion.ne.jp> <436961FD.3040605@root.org> <20051103014740.GA1586@flame.pc> <20051103142446.GA1787@flame.pc> Content-Type: text/plain Date: Thu, 03 Nov 2005 16:33:26 +0100 Message-Id: <1131032006.648.4.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: freebsd-acpi@freebsd.org, robert.moore@intel.com, freebsd-current@freebsd.org, jkim@freebsd.org 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:33:34 -0000 On Thu, 2005-11-03 at 16:24 +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. > Just tried reverting, and my problem reported in http://lists.freebsd.org/pipermail/freebsd-current/2005-November/057596.html is also ACPI-related. It also happens early on boot but panic is different (in devfs_populate_loop()). Don't know if it's related or a different bug introduced by the ACPI-CA import.