From owner-freebsd-current@FreeBSD.ORG Thu Nov 3 08:36:07 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 32FF916A41F; Thu, 3 Nov 2005 08:36:07 +0000 (GMT) (envelope-from nate@root.org) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9618943D48; Thu, 3 Nov 2005 08:36:06 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.250] (ppp-71-139-0-107.dsl.snfc21.pacbell.net [71.139.0.107]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id jA38a3xq028698 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 3 Nov 2005 00:36:04 -0800 Message-ID: <4369CBCA.7050501@root.org> Date: Thu, 03 Nov 2005 00:35:22 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Munehiro Matsuda References: <971FCB6690CD0E4898387DBF7552B90E0346CAFB@orsmsx403.amr.corp.intel.com> <20051103.094643.74756456.haro@h4.dion.ne.jp> <436961FD.3040605@root.org> <20051103.122404.74756296.haro@h4.dion.ne.jp> In-Reply-To: <20051103.122404.74756296.haro@h4.dion.ne.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2005 08:36:07 -0000 Munehiro Matsuda wrote: > Hi Nate, > > Thanks for memguard tip. > But now, I'm confuse with the outcome. :-( > > 1) With memguard enabled, system boots up just fine, even acpi compiled > into kernel or loaded as a module. > > 2) Without memguard, but with acpi compiled into kernel, system boots up > past the reported point. > But this time, npanics with page fault further into the booting process, > just as Marcel reported yesterday. > > 3) Without memguard and with acpi loaded as module, system panics as > reported in my original mail. > > So, the memguard works as workaround for me, but not as debuging aid. ;-P > > If you need more info or any other way to debug, please let me know. Judging from your dmesg, the use after free happens somewhere just after probing of PCI LNKH. Something likely changed in how acpi-ca deals with pci links or resources (due to your failure message on PRT_). Since memguard affects the malloc pool enough to hide the problem, you'll have to trace it down differently with memguard disabled. My procedure for hunting these problems is a little more time consuming but nearly always works. Compile in DDB and type "boot -d" at the loader prompt. This will pop into the debugger early. Then type "w 0xc1ee1600" to set a watchpoint for this address. Now you'll break to the debugger each time this memory is written to. Type "tr" to get a trace each time you hit the debugger and see what call stack was the very last one to write to that region, just before the panic. -Nate > From: Nate Lawson > Date: Wed, 02 Nov 2005 17:03:57 -0800 > ::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. > :: > ::http://www.freebsd.org/cgi/man.cgi?query=memguard&apropos=0&sektion=0&manpath=FreeBSD+6.0-current&format=html > :: > ::If you need a kernel to keep running in production while debugging the > ::other kernel, disable options INVARIANTS to get rid of the diagnostic panic. > :: > ::-Nate