Kernel logs, taint flags, and oops decoding

The kernel logs to a ring buffer exposed as /dev/kmsg. Reading that buffer is how you investigate hardware, driver, and filesystem issues that originate below userspace.

Reading dmesg output

$ cat /proc/sys/kernel/tainted; echo see-table-below-for-decoding

12289
K,B,G

Kernel oops

A kernel oops is the kernel’s “something went wrong, but I am trying to continue” message. Unlike a panic (which halts), an oops may kill the offending process and continue — but the kernel is now tainted.

$ dmesg | grep -A 5 -i 'oops'

[12345.678] BUG: unable to handle kernel NULL pointer dereference at 0000000000000010
[12345.678] PGD 0 P4D 0
[12345.678] Oops: 0002 [#1] SMP PTIT
[12345.678] CPU: 2 PID: 1234 Comm: myapp Tainted: G        W        6.6.31-linuxkit
[12345.678] RIP: 0010:[<ffffffffc0deadbeef>]
...

The discipline for oops:

1; capture the full oops output (photo or serial capture). 2. Check the taint flags — was the kernel already in a problematic state? 3. Check mcelog (or rasdaemon) for hardware-level errors if the oops is a machine check. 4. Look up the oops code in the kernel source (kernel.org git). 5; test on a clone host before applying any fix.

When to escalate

A kernel oops is always worth investigating. The escalation threshold depends on the symptoms:

Knowledge check