a kernel panic (and an oops)
When an ordinary program hits a fatal error, the kernel simply kills that one process and the rest of the system keeps running - a segmentation fault is contained. But the kernel is the program that does the containing; there is nothing above it to catch its own fatal errors. A kernel panic is what happens when the kernel detects a problem so serious that it cannot safely continue - so rather than risk silently corrupting data on disk, it deliberately stops everything. It is the kernel saying 'I can no longer trust the state of the machine; halting now is safer than going on.'
Two related terms are worth separating. In Linux, an oops is a report of a serious kernel error - the kernel hit a bug (often a bad pointer dereference inside kernel code), printed a diagnostic dump (registers, a call stack/backtrace showing how it got there, the offending instruction), and tried to carry on, perhaps by killing just the affected task. A panic is the harder stop: the error is unrecoverable - or an oops happened somewhere too critical to limp past - so the kernel prints its diagnostic and then halts the system entirely. On Windows the same idea is the famous 'Blue Screen of Death'; on macOS it is a kernel panic that forces a reboot. The diagnostic a panic prints is precious for debugging, which is why kernels can be configured to capture it (a crash dump via kdump) for post-mortem analysis.
Why understanding this matters: a panic is not a random failure to be annoyed at - it is usually a deliberate, defensive choice. The kernel would rather halt loudly than continue with corrupted internal state and quietly destroy your filesystem. So the right reaction to a panic is to read its message: it almost always points at the cause (a specific driver, a specific function in the backtrace). And the deeper point ties back to the trust boundary: because the kernel runs with full privilege and has no safety net above it, a single bug in any in-kernel component - including a buggy driver in a monolithic kernel - can panic the whole machine, which is exactly the fragility that microkernels try to contain by isolating drivers into restartable user-mode servers.
kernel code dereferences a bad pointer -> oops: prints registers + backtrace (which function, which driver), may kill just that task. if unrecoverable or in a critical path -> panic: prints the dump, then halts the whole system. kdump can save it for analysis.
An oops reports a kernel bug and may limp on; a panic is the unrecoverable stop. The printed backtrace is the first clue to the cause.
A panic is usually a deliberate fail-safe, not a random glitch: the kernel halts on purpose rather than risk corrupting your data with an untrusted internal state. Always read the backtrace - it points at the faulty function or driver. And remember the structural cause: with full privilege and no safety net above it, one in-kernel bug can take down the whole machine.