View Single Post
Old 14th February 2009
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 7,983
Default

John, your system has 3/4 of a GB (768MB) of RAM, per your earlier dmesgs.

Your swap space is sufficient for capturing RAM during a dump. Unfortunately, you need at least 768MB free space available in /var (or mounted to /var/crash) in order to have savecore(8) save the dump for gdb(1).

Are you *sure* you want to do all of this?

Once you have sufficient free disk space in /var or /var/crash for savecore(8) to save a copy of RAM, you still won't have sufficient useful information. Why? Because any traces produced by ddb(4) or gdb(1) will only have addresses. You'll want debugging symbols if you want a functional, useful kernel for debugging. To get that, you'll need to compile a custom kernel from -current source, adding this line to your custom configuration file:
makeoptions DEBUG="-g"
as described in options(8). Kernel building is described in detail in FAQ 5. The kernel build will create two kernels; a stripped "bsd" for booting, and a "bsd.gdb" with debugging symbols for use with gdb(1).

If you have all that, the general process is:
  • Set up the sysctl ddb.console=1 in /etc/sysctl.conf and reboot
  • Create the hang situation
  • Cause the kernel to hang to "break" the hang and enter ddb(4). Of course, the kernel must respond to keyboard interrupts for this to happen -- it may not, so before making the storage and kernel changes, test that the kernel breaks into ddb(4).
  • In ddb(4), issue a "boot dump" command. This will save RAM to swap (and you have sufficient swap space right now).
  • On boot, /etc/rc will run savecore(8), which will save the dump to the filesystem in /var/crash (you don't have enough space right now)
  • Run the script(1) command to capture the console to a file.
  • Per crash(8), start gdb(1), point to the dump in /var/crash with the file command, then point to your debugging symbols kernel with target kvm.
  • use the bt command to obtain a backtrace (which will show what the kernel has been up to while hung, it may even show why it was hung. With the gdb symbols, it will show modules and source code line numbers.
  • quit gdb(1).
  • exit the script(1) shell.
  • Clean up the output file, e.g.: # col -b < typescript > my.output
All of this, just to get a backtrace that you can then send in an e-mail to misc.
Reply With Quote