3 ms·

Putting aside the live debugger issue, most UNIXes support generating a full kernel core dump that can be used post-facto to debug the panic using the standard

Putting aside the live debugger issue, most UNIXes support generating a full kernel core dump that can be used post-facto to debug the panic using the standard debugging tools -- you get full access to the memory contents, machine state, a backtrace, etc. It's very, very useful when you have a difficult to reproduce problem that only occurs on a small subset of your machines while in production. Up until relatively recently, Linux had no support for this, and I believe still has no official support. RedHat EL ships a modified system with crash dump support, and other hacked in implementations exist. When we had Linux machines regularly crashing once every couple weeks in ~2003, we couldn't even get a usable oops out of them -- we just gave up and rebooted them regularly. When we saw the same thing occur on a new FreeBSD release a few years later, we enabled crash dumps and found and fixed the issue immediately. Linus is intelligent, but his oft-unchecked arrogance begets some particularly unfortunate foolishness.

lsc 17y ago
you did not get an oops or a backtrace out of your logging serial consoles? I mean, I understand that a kernel dump does give you even more information, but a logging serial console does give you a lot of information, usually enough. the kernel support for kdump is in the upstream kernel.org tree, I believe. you've gotta monkey with your initrd and the userland tools, though, last time I looked. It does seem pretty silly that linux seems to want to change the standard way to do crash dumps every two years. *BSD is much cleaner in this regard. But in my experience, a logging console is usually as useful (and sometimes more useful; logging consoles help in cases when the problem isn't a kernel panic, but is instead a weird network issue.) than kernel dumps. I remember last time I tried to debug an issue with kdump, the kernel would crash, then it would load the kdump kernel, but that, too would crash before dumping the kernel. (It turns out it was a hardware issue with the raid controller. Dumping to disk when disk is the problem doesn't work so well.) But then, I'm a computer janitor, and not a kernel developer. I imagine there are reasons to get a full kernel dump when you are concerned with more than "Is this a kernel issue or is it bad hardware?"

lsc 17y ago

you did not get an oops or a backtrace out of your logging serial consoles? I mean, I understand that a kernel dump does give you even more information, but a logging serial console does give you a lot of information, usually enough. the kernel support for kdump is in the upstream kernel.org tree, I believe. you've gotta monkey with your initrd and the userland tools, though, last time I looked. It does seem pretty silly that linux seems to want to change the standard way to do crash dumps every two years. *BSD is much cleaner in this regard. But in my experience, a logging console is usually as useful (and sometimes more useful; logging consoles help in cases when the problem isn't a kernel panic, but is instead a weird network issue.) than kernel dumps. I remember last time I tried to debug an issue with kdump, the kernel would crash, then it would load the kdump kernel, but that, too would crash before dumping the kernel. (It turns out it was a hardware issue with the raid controller. Dumping to disk when disk is the problem doesn't work so well.) But then, I'm a computer janitor, and not a kernel developer. I imagine there are reasons to get a full kernel dump when you are concerned with more than "Is this a kernel issue or is it bad hardware?"