What Is a Kernel Panic? Mine Happened Today, and Nothing Was Broken
My Mac Studio kernel panicked this morning, mid-render. I went looking for a broken driver, which is what I assumed I'd find. What I actually found was the kernel doing its job perfectly.
The panic log is on this machine, so let's read it rather than talk in general terms.
First: what a kernel panic actually is
When a normal program hits something impossible — dereferences a null pointer, divides by zero, corrupts its own heap — the operating system kills it. You lose that process. Everything else keeps running. Your editor crashing doesn't take your music player with it.
That works because there is something underneath the program to catch it.
The kernel is the thing underneath. It's the code that owns memory mapping, scheduling, device drivers, and the boundary between user programs and hardware. When the kernel hits something impossible, there is no parent to catch it, no supervisor to restart it, no outer layer to fall back to. It is the outer layer.
So it does the only responsible thing available: it stops the entire machine, writes down everything it can about its own state, and reboots.
A kernel panic is not the kernel crashing. It's the kernel refusing to continue. That distinction sounds pedantic until you see a panic like mine.
Mine, verbatim
panic(cpu 0 caller 0xfffffe001d8a5abc): watchdog timeout:
no checkins from watchdogd in 92 seconds
(8109 total checkins since monitoring last enabled)
Read that carefully, because it doesn't say what people expect a panic to say.
Nothing was corrupt. No memory was invalid. No driver faulted. What happened is that a userspace daemon called watchdogd — whose entire job is to periodically tell the kernel "I'm alive and being scheduled" — stopped saying it. It had said it successfully 8,109 times. Then it didn't say it for 92 seconds, and the kernel pulled the plug on the whole machine.
The rest of the log backs it up. This is a Mac Studio (Mac13,1, M1 Max, kernel RELEASE_ARM64_T6000), and:
- The panicking task was
kernel_task, pid 0, carrying 726 threads. - There are no third-party kernel extensions in the backtrace. The usual culprit — some vendor's driver — simply isn't there.
AppleAVE(Apple's hardware video encoder),AGX(the GPU driver) andIOSurface(shared graphics buffers) are all in play, which is exactly what you'd expect from a machine encoding video.
So: no bug, no bad driver, no corruption. A heartbeat stopped.
What a watchdog actually is
A watchdog is a dead man's switch.
The pattern is old and it's everywhere — industrial controllers, aircraft, network gear, embedded firmware. You have a component that must keep working. You cannot easily prove from the inside that it is working. So you invert the problem: instead of detecting failure, you require continuous proof of life. Something must reset a countdown at regular intervals. If the countdown ever reaches zero, the system assumes the worst and resets.
The genius of it is that it needs no theory of what might go wrong. A watchdog doesn't care why the check-in stopped — deadlock, livelock, priority inversion, a driver spinning with interrupts disabled, a scheduler that has become so oversubscribed that a critical daemon simply never gets a turn. All of those look identical from the outside: silence.
And silence is the one thing a watchdog is built to punish.
So what starved it?
This is where the render comes in. Encoding video pins the media engine, hammers the GPU, allocates aggressively, and drives memory pressure hard. The load average on this machine is still 19.45 over fifteen minutes as I write this, and macOS logged a separate memory-pressure event earlier the same day.
Under that kind of sustained pressure, a small daemon that does almost nothing can go a very long time without being scheduled. watchdogd doesn't need much CPU. It needs some, reliably, within 92 seconds.
It didn't get it.
Note what that means: the machine was probably not "hung" in the way you'd picture. Cores were busy. Work was happening. Frames were very likely being encoded. But the system could no longer guarantee that a designated task would run within a bounded time — and for a kernel, an unbounded scheduling delay is indistinguishable from a deadlock.
It can't tell the difference between "extremely busy" and "permanently stuck." So it treats them the same, on purpose.
The part I find genuinely interesting
I have spent the last few weeks writing about a distinction between two kinds of failure: the ones that announce themselves, and the ones that quietly hand you a wrong answer while looking fine.
The argument there was that loud failures are cheap and silent ones are expensive. A crash gives you a stack trace and a place to start. A confident wrong answer gives you nothing, and you find it weeks later in a customer's spreadsheet.
A watchdog panic is that principle implemented in silicon and shipped by default.
The alternative behaviour — the one the watchdog exists to prevent — is a machine that stays powered on, keeps its fans running, holds your filesystem mounted, and is no longer reliably servicing anything. Half-alive. Responsive enough to look up, unreliable enough to corrupt whatever it touches next. That's a machine that lies about its own state.
Apple's engineers made the same call I keep arriving at from the other direction:
When you can no longer prove the system is healthy, crashing loudly beats continuing quietly.
Which reframes the whole event. My machine didn't fail this morning. My machine detected that it could no longer verify its own health and chose the failure mode that leaves evidence — a 3 MB panic log with every core's register state in it — over the failure mode that leaves you guessing.
What to actually do about one
Practical, in the order I'd do it.
Read the panic string. It's the first line and it tells you which kind you have. watchdog timeout is a starvation or hang problem. A Kernel data abort or an address fault usually means memory or a driver. Kernel Extensions in backtrace: followed by anything third-party points straight at the culprit — mine was empty, which is what let me stop suspecting drivers.
On macOS the logs live in /Library/Logs/DiagnosticReports/, and older ones get moved into a Retired/ subfolder — which is where mine was, and why a quick look at the main directory turned up nothing at first.
Don't fix a watchdog panic as if it were a bug. It's a symptom. The bug, if there is one, is whatever made the machine unable to schedule a trivial daemon for a minute and a half. Chasing the watchdog itself is chasing the smoke alarm.
Check whether you're actually overcommitted. Memory pressure and a triple-digit process count under a heavy encode is a resource problem wearing a crash's clothing. In my case the honest reading is that I asked a workstation to render video while it was already carrying a load average that peaked near 20.
Only then suspect hardware. Repeated panics with different panic strings, especially memory faults, are the pattern that points at failing RAM or a failing SSD. One watchdog timeout under extreme load is not that.
So
A kernel panic is the bottom of the stack declining to guess. There's nothing underneath it to catch a mistake, so when it can't be sure it's operating correctly, it stops — loudly, with a full record of what it was doing.
Mine wasn't a driver bug or bad memory. It was a machine under enough load that a heartbeat missed for 92 seconds, and an operating system that treats an unprovable state as a fatal one.
I'd rather have that than the alternative. A computer that dies with a 3 MB explanation is a better colleague than one that keeps going and stops telling you the truth.