In July I wrote about The Problem Wasn't the AI—Linus Torvalds pushing back on treating the Linux kernel as an anti-AI project and calling AI a useful tool that should be judged like any other. It is unusual enough to see Torvalds personally author a patch deep inside an Intel graphics driver. The reason he ended up there is even more interesting.

Torvalds had been chasing a nasty Intel Xe graphics problem that could leave a machine with a black screen while GDM repeatedly restarted, reliably reproducible on an Intel Battlemage G21 GPU with 16 GB of VRAM. The eventual fix was almost embarrassingly small. The Xe driver was calculating where usable VRAM ended and Intel's compression metadata storage began, and it rounded that boundary up to a 128 KB boundary—exactly the wrong direction when everything below that address is handed to a memory allocator. Rounding upward meant a small piece of memory owned by the GPU's compression hardware was being advertised as ordinary usable VRAM. On Torvalds' machine, the overlap was only 2 KB, and that was enough.

A Mesa virtual machine page table landed on the affected page during cold boot. The GPU's compression hardware wrote metadata into the same memory and corrupted the page table; the compositor faulted; GDM restarted it; the process repeated indefinitely. Restarting GDM could make the problem disappear because the next page table might land somewhere else.

That kind of bug is miserable—memory placement, hardware behavior, timing, and corruption somewhere completely different from where the failure becomes visible. Torvalds called it a "debug session from hell." It took 24 progressively instrumented patches and 18 kernel boots to narrow it down.

And AI helped him do it—not by handing him the answer. Torvalds said the AI did much of the grunt work: adding debugging instrumentation, processing what came back, and helping continue as they narrowed the problem. The funny part is that the AI repeatedly wanted to give up. Several times it concluded the problem was impossible and suggested they should simply write up a report. He kept pushing it. Eventually they isolated the bad memory-boundary calculation. Torvalds even let the AI write the final commit message.

When the AI said the problem could not be solved, the human knew better and kept going. I can relate—these tools constantly decide something is too difficult, take a shortcut, or ignore half of what I asked. Stubbornness is becoming an increasingly useful engineering skill.

I really like this example because it is almost the opposite of what people usually mean by "AI coding." The engineer understood the system, reproduced the problem, and decided what needed to be measured next. The AI handled repetitive instrumentation and helped process the results. And the human ultimately took responsibility for the patch.

That last part matters because the Linux kernel now has explicit documentation for AI-assisted development. AI tools must follow the normal process, and the Signed-off-by certification is reserved for humans. The person submitting the change reviews AI-generated work, validates it, and takes responsibility. That seems like exactly the right model—useful when paired with someone who knows when the model is wrong, and less useful when the operator cannot tell a good answer from a confident dead end.

The incorrect round_up() was introduced in a September 2024 Xe driver fix that said Intel's specification required rounding upward to the nearest 128 KB boundary. Two years later, debugging showed why applying that rule at this particular point was wrong. The fix rounds the usable-memory boundary down to the allocator's 4 KB page size instead.

One incorrect rounding direction. Two kilobytes of overlapping memory. A corrupted GPU page table. A machine that appeared to have a completely different graphics failure. Twenty-four debugging patches. Eighteen kernel boots. That is software debugging.

Not replacing the engineer—helping a stubborn engineer keep digging.

Read Linus Torvalds' commit: drm/xe: Don't hand out the flat CCS storage as usable VRAM.

All notes