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
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
