6.1-RELEASE / 6.2 Kernel Crash...

[Robert Watson]

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...

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
Computer Laboratory
University of Cambridge