Diagnosing a FreeBSD Kernel Panic from a Crash Dump
FreeBSD panicked and rebooted. Here's how to get the crash dump kgdb actually needs, and how to read it well enough to find the responsible driver or subsystem.
A FreeBSD kernel panic isn’t a dead end for diagnosis — as long as crash dumps are configured, the system captures exactly enough state to identify what actually went wrong, the same way diagnosing a macOS kernel panic does on Apple’s platform, just through FreeBSD’s own tooling.
Step 1: confirm crash dumps are actually enabled
sysrc dumpdev
cat /etc/rc.conf | grep dumpdevdumpdev="AUTO" in /etc/rc.conf tells FreeBSD to write a crash dump to the swap device on panic — without this configured before the panic happens, there’s nothing to analyze afterward, which makes confirming this the first and most important step, ideally long before a panic ever occurs.
Step 2: find the saved crash dump after a reboot
ls -la /var/crash/On boot after a panic, savecore (run automatically via /etc/rc.d/savecore) copies the dump from the swap device into /var/crash/, typically as vmcore.N alongside a matching kernel, kernel.N.
Step 3: load the dump into kgdb
kgdb /var/crash/kernel.0 /var/crash/vmcore.0kgdb (the kernel-aware variant of GDB) loads the crashed kernel’s symbols alongside the memory dump, letting you inspect the exact state at the moment of the panic.
Step 4: get the immediate panic message and backtrace
(kgdb) btThe backtrace shows the call stack at the moment of the panic — the top few frames are usually the most directly relevant, showing which function was executing (and which one called it) right before things went wrong.
Step 5: identify which subsystem or driver is implicated
(kgdb) bt fullA full backtrace including local variables often reveals which specific driver or kernel subsystem’s code was on the stack — a panic occurring inside a specific device driver’s function points squarely at that driver (or the hardware it manages) as the place to focus on, rather than the kernel core generally.
Step 6: check dmesg output preserved from before the panic
grep -A5 -B5 "panic:" /var/log/messagesThe panic message itself, along with kernel log lines leading up to it, are often preserved in the system log across the reboot — sometimes containing additional context (a specific error code, a resource that ran out) that the backtrace alone doesn’t show.
Step 7: check for a known, already-fixed bug matching your symptoms
Before assuming a panic reflects a bug you’ll need to diagnose entirely from scratch, check the specific panic message and backtrace signature against FreeBSD’s bug tracker and mailing list archives — many panics, especially in less mainstream drivers, are known issues with an existing fix in a newer version.
Why enabling dumps ahead of time is the step that actually matters most
Every step here depends entirely on Step 1 having already been done before the panic occurred — a system without dumpdev configured loses the crash dump the moment it reboots, leaving nothing for kgdb to load regardless of how good your debugging technique is afterward. Confirming crash dumps are enabled on any system where an unexplained panic would be costly to leave undiagnosed is the single highest-leverage step in this entire process, and the only one that has to happen before the problem occurs rather than after.