How do I keep Fedora4 from rebooting on a kernel panic?

[beer]

if anyone can help me figure out how to keep my machines from rebooting on a kernel panic I'd be really happy. I have a serial console that I can grab console output from, but since the STA reboots on the panic I have debug messages queued that I am not getting. If I can just allow the machine to hang and let the serial FIFO empty it would make my jo much easier.

Anyone have any ideas?

 

[Nothinman]

By default it doesn't reboot on panic and I didn't think any distros enabled it by default. Check out this[1] one link that tells you how to enable it, if that's not setup than I'd say something is causing the CPU to reset which will be a PITA to track down.

[1] http://gentoo-wiki.com/TIP_Kernel_Panic_Reboot

 

[beer]

Well, it could be something left dangling that shouldn't be or a race condition resulting in something bad that should be capable of bringing down the kernel, but why would the CPU reset? This is a networking driver and the problem is likely in the protocol implementation and not in the actually PHY code.

I'll keep investigating. Thanks for your help.
<-- might have to learn GDB soon.

 

[Nothinman]

Learning gdb would be a very good idea, there's also kgdb for an in-kernel debugger but you'll need to patch your kernel to use it since Linus doesn't really like debuggers.

 

[beer]

If i could reliably get my kprintf buffers to empty before the damn machine reboooted that would be fine. We have enough in-driver debugging that it would be useful. But if the damn reboots or doesn't empty the fifo to the attached console before rebooting, or worse gives me a corrupted stack it's useless.

I really hate debugging on linux.

 

[Nothinman]

If i could reliably get my kprintf buffers to empty before the damn machine reboooted that would be fine.

I hope you mean printk there.

But if the damn reboots or doesn't empty the fifo to the attached console before rebooting, or worse gives me a corrupted stack it's useless.

Did you enable all of the kernel debugging options? Things like CONFIG_DEBUG_SLAB and CONFIG_DEBUG_STACKOVERFLOW might help if you are having memory and/or stack problems.

And if you're still stuck you could always post to lkml, as long as you put the code somewhere someone will probably help you out.

Edit: and one more thing to consider if you have firewire on the box is firescope. Apparently the 1394 controller has full access to the entire range of host memory so you can read that memory on another machine via firewire even if the host OS has crashed. I've never used it though, so I have no idea how well it works and the rebooting might make that even more complicated.