Date: Thu, 03 Nov 2005 00:35:22 -0800 From: Nate Lawson <nate@root.org> To: Munehiro Matsuda <haro@h4.dion.ne.jp> 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 Message-ID: <4369CBCA.7050501@root.org> In-Reply-To: <20051103.122404.74756296.haro@h4.dion.ne.jp> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <nate@root.org> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4369CBCA.7050501>