6.1-RELEASE / 6.2 Kernel Crash...
rwatson at FreeBSD.org
Fri Dec 29 13:33:25 PST 2006
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:
> 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...
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.
Robert N M Watson
University of Cambridge
More information about the freebsd-hackers