From owner-freebsd-acpi@FreeBSD.ORG Thu Nov 3 02:09:15 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 8F0E016A41F; Thu, 3 Nov 2005 02:09:15 +0000 (GMT) (envelope-from keramida@linux.gr) Received: from rosebud.otenet.gr (rosebud.otenet.gr [195.170.0.94]) by mx1.FreeBSD.org (Postfix) with ESMTP id D6B3B43D45; Thu, 3 Nov 2005 02:09:12 +0000 (GMT) (envelope-from keramida@linux.gr) Received: from flame.pc (patr530-a063.otenet.gr [212.205.215.63]) by rosebud.otenet.gr (8.13.4/8.13.4/Debian-1) with ESMTP id jA3299Cr017102; Thu, 3 Nov 2005 04:09:09 +0200 Received: from flame.pc (flame [127.0.0.1]) by flame.pc (8.13.4/8.13.4) with ESMTP id jA3293KH030404; Thu, 3 Nov 2005 04:09:03 +0200 (EET) (envelope-from keramida@linux.gr) Received: (from keramida@localhost) by flame.pc (8.13.4/8.13.4/Submit) id jA3292PD030395; Thu, 3 Nov 2005 04:09:02 +0200 (EET) (envelope-from keramida@linux.gr) Date: Thu, 3 Nov 2005 04:09:02 +0200 From: Giorgos Keramidas To: Nate Lawson Message-ID: <20051103020902.GA29536@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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051103014740.GA1586@flame.pc> Cc: freebsd-acpi@freebsd.org, freebsd-current@freebsd.org, robert.moore@intel.com, 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 02:09:15 -0000 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. Does the following look ok for using memguard(9) with M_ACPICA? %%% begin acpica-memguard.patch Index: kern/kern_malloc.c =================================================================== RCS file: /home/ncvs/src/sys/kern/kern_malloc.c,v retrieving revision 1.148 diff -u -r1.148 kern_malloc.c --- kern/kern_malloc.c 20 Oct 2005 21:28:31 -0000 1.148 +++ kern/kern_malloc.c 3 Nov 2005 02:04:02 -0000 @@ -62,6 +62,8 @@ #include #include +MALLOC_DECLARE(M_ACPICA); + #ifdef DEBUG_MEMGUARD #include #endif @@ -305,7 +307,7 @@ #ifdef DEBUG_MEMGUARD /* XXX CHANGEME! */ - if (mtp == M_SUBPROC) + if (mtp == M_ACPICA) return memguard_alloc(size, flags); #endif %%% end acpica-memguard.patch