Date: Fri, 29 Dec 2006 17:32:59 -0500 From: Jan Knepper <jan@digitaldaemon.com> To: Robert Watson <rwatson@FreeBSD.org> Cc: Tim McCullagh <tim@halenet.com.au>, FreeBSD ISP <FreeBSD-ISP@FreeBSD.org>, Kris Kennaway <kris@obsecurity.org>, FreeBSD Hackers <FreeBSD-Hackers@FreeBSD.org> Subject: Re: 6.1-RELEASE / 6.2 Kernel Crash... Message-ID: <4595979B.1030104@digitaldaemon.com> In-Reply-To: <20061229213013.E86685@fledge.watson.org> References: <45918F6E.90006@digitaldaemon.com> <004c01c7293b$d5e03b40$6500a8c0@laptopt> <4591CB3C.1060902@digitaldaemon.com> <20061227033742.GA9706@xor.obsecurity.org> <4593552E.80400@digitaldaemon.com> <20061229213013.E86685@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Robert Watson wrote: > On Thu, 28 Dec 2006, Jan Knepper wrote: > >>> Sounds like a bug in the support for your ATA hardware, or your >>> hardware is broken. The very least you'll need to do is to obtain a >>> crashdump and debugging backtrace (see the developers handbook) and >>> CC it to sos@ >>> >> This is getting funnier... >> I added: >> dumpdev="AUTO" >> to: rc.conf >> Rebooted the system and tried to get it to crash again... >> And indeed it does in process 9: taskq >> >> Then it starts dumping which takes a couple of seconds as the machine >> has 2 GB Ram... >> >> Than it reboots... and the next thing you know... savecore does NOT >> recognize a dump on the swap file system. If does not save anything >> to /var/crash... <sigh> Tried this about 10 times... No luck... >> >> Any other idea's? > > Yeah, unfortunately if some combination of storage driver and hardware > aren't working, it's hard to get a dump... No kidding! > The usual fallback here is to use a serial console to capture > debugging information from DDB and to skip the dump side of things. > In fact, I prefer debugging that way most of the time. The reason for > using a serial console (or firewire) is to avoid having to hand-copy > trap and debugging information, which gets very painful very quickly. > Compile DDB and KDB into your kernel, and configure a serial console, > and a panic should lead to the system entering the debugger. The > usual first command to type is "trace" to generate a backtrace; it's > often useful also to do "show pcpu", "show allpcpu", "alltrace", and > "ps", although for the problem you're seeing the last two may be less > useful. > > The 0x50 trap address in your post suggests this is a NULL pointer > dereference. What we now need to do is work out what piece of code is > dereferencing the pointer improperly, which is where the backtrace > comes in. > > If you could copy and paste all that DDB/KDB output into an e-mail > (or, perhaps more ideally, a PR), that would be great. Thanks for the reply Robert. Since this machine runs at my house I hope to get to this over the weekend. I will definitely try to get this information out as soon as I decently can. Thanks! Jan Knepper
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4595979B.1030104>