1

What's current best practice to capture full kernel stack traces on a Linux system (RHEL 5.x, kernel 2.6.18) that occasionally panics in a device driver?

I'm used to the "old" SunOS way of doing things - crash dumps get written to swap, and on reboot the dump gets retrieved in the local file system. man 8 crash refers to diskdump, but that appears to be unsupported. and/or deprecated.

I've played with kdump, but it's unclear whether I can get a stack trace from that. Triggering a panic via Magic SysRq didn't create one. It also seems wasteful to reserve so much memory (128MB) just for a kexec crash recovery kernel.

Alnitak
  • 21,191
  • 3
  • 52
  • 82
  • 1
    The last time I did any of this (2.6.18 era, actually) I used a serial-console configuration to get crash-dump data. That's useless in a VM context these days as nearly every VM system doesn't so serial. No idea if that's latest, though. – sysadmin1138 Sep 15 '10 at 20:06
  • @sysadmin1138: both VirtualBox and QEMU KVM have support for serial ports. – Cristian Ciupitu Sep 15 '10 at 20:39
  • @cristian Hooray! VMWare doesn't, and that's what I have in front of me. – sysadmin1138 Sep 15 '10 at 21:31
  • @sysadmin1138: well, at least [VMWare 3.2 had support for serial ports](http://www.vmware.com/support/ws3/doc/ws32_devices3.html) :-) – Cristian Ciupitu Sep 15 '10 at 22:04
  • @sysadmin1138: Funny, I'm trying to think of a VM solution that *doesn't* do serial. And wondering why you would use such a solution. – Matthew Iselin Sep 15 '10 at 23:56

2 Answers2

1

If you are looking to log output in case of a kernel panic with Linux, kdump is the way to go. This is what Red Hat trains people to use and what I have known to be the standard approach.

Warner
  • 23,756
  • 2
  • 59
  • 69
0

Maybe the stack trace makes it through a netconsole (/usr/src/linux/Documentation/networking/netconsole.txt). Worth a try, since it's almost no effort.

al.
  • 925
  • 6
  • 17