Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm regularly encountering a kernel panic on my FreeBSD 9 laptop.

I have not been able to fix the problem by updating my system to the current stable version (which I got from the ctm-svn), so how shall I go forth to find out the reason for this kernel panic and how to get rid of it?

I have the three files info.N, core.txt.N and vmcore.N that savecore writes to /var/crash during the boot process, where info.N contains something like

Dump header from device /dev/ada0p3
  Architecture: amd64
  Architecture Version: 2
  Dump Length: 289755136B (276 MB)
  Blocksize: 512
  Dumptime: Mon Feb  4 08:07:41 2013
  Hostname: hostname
  Magic: FreeBSD Kernel Dump
  Version String: FreeBSD 9.1-STABLE #4 r246115: Sat Feb  2 14:29:28 GMT 2013
    root@:/usr/obj/usr/src/sys/GENERIC
  Panic String: page fault
  Dump Parity: 2576771399
  Bounds: 3
  Dump Status: good

core.txt.N contains more context and vmcore.N is huge.

share|improve this question
2  
Do you already have dumps enabled? (If not, see freebsd.org/doc/en/books/developers-handbook/kerneldebug.html for instructions on how to do that). – Hennes Feb 3 '13 at 17:29
    
Can you post the panic stack? Did you get a minidump? – MaQleod Feb 3 '13 at 20:09
    
I'd start by running a memory test like memtest86+ for a few hours. If you get any errors at all, it's a hardware or BIOS configuration problem. – David Schwartz Feb 4 '13 at 10:07

It is rare for software to cause a kernel panic these days. Often kernel panics they are hardware related. Possible culprits are:

  • Bad memory
  • voltage too low
  • battery run down
  • CPU temperature too high

(although usually a low battery should trigger a clean shutdown, and CPU overtemperature just switches the machine off)

You can analyze the crashdumps with kgdb -n N, where N is the dump number. If the crashes consistently happen at the same point/subsystem in the kernel, it is probably a software problem. If they happen in different places, it's probably hardware.

There are several monitoring programs for running under X in the ports collection, like sysutils/conky. Those can help you keep an eye on battery status, CPU temperature, core voltage et cetera.

share|improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .