* Damian Gerow <dgerow [ at ] afflictions [ dot ] org> [090811 20:55]: > So, how does one go about proving these are kernel panics? There are a few ways. > (The most obvious route, attach a serial console, is sadly an unviable > option in this case. The reasons why are long and dry, so I'll save you all > the boring details.) One of them is a serial console as you suggest. Another is a netconsole. This is similar to syslog, in that it logs simple text messages from the kernel over a UDP "connection". To configure it you simply have to run: modprobe netconsole netconsole=9999@/eth0,9999@10.10.10.10/ See output of modinfo netconsole for the specifics of the configuration string. Once setup all console messages generated by the kernel will be output on eth0 sent to 10.10.10.10 UDP port 9999. On the other system you can capture these with netcat, for example nc -u -l -p 9999. Like serial console, netconsole will only give you the backtrace, registers, and the raw machine code around the instruction that triggered the crash. Another way is to setup kdump, which will create kernel core files on the disk. See if your distribution has the kexec-tools package. Yet another way is to use netdump, but I think this is mainly maintained by RedHat. netdump will send a core file over the network to a netdump server. It's a bit of a pain. Finally there is kgdb. This allows you to connect a debugger to a running kernel. kgdb can work over serial (kgdboc) or ethernet (module kgdboe). Unfortunately, the kgdboe is not available in mainline kernels, and I don't know if SuSE ships it. Having said all that, I use netdump 90% of the time and kgdb for the remaining 10% (mostly for complex problems that arise while developing new code). Hope that helps. -Bart -- WebSig: http://www.jukie.net/~bart/sig/