Linus Torvalds merged a one line fix to Intel's Xe graphics driver on Friday, August twenty first, 2026, ending a bug that left his own workstation at a black screen with the display manager restarting in a loop. The offending code rounded a video memory offset up when it should have rounded it down, which quietly handed the compression metadata region to the memory allocator as if it were free. Getting there took 24 debugging patches and 18 kernel boots, and Torvalds described the process as a debug session from hell, enormously helped by an AI that repeatedly told him the problem was unsolvable.
The short answer
Linus Torvalds merged commit 818bebeb63dd to Intel's Xe driver on August 21, 2026, fixing a bug that left his Battlemage G21 workstation at a black screen with GDM restarting in a loop. The flat CCS offset calculation rounded up to a 128 KiB boundary instead of down, so memory belonging to the compression metadata region was handed to the VRAM allocator. Finding it took 24 debugging patches and 18 kernel boots. Torvalds credited an AI with much of the mechanical work and noted that it repeatedly declared the problem impossible.
Torvalds does not write many patches himself any more. He merges, he reviews, he occasionally shouts. So when a commit lands with his name on the authorship line and a commit message describing 18 boots and a session from hell, the interesting part is not the fix. It is the shape of the problem that forced him back into the chair.
What the machine was doing
A black screen, and a display manager restarting forever. That is the whole external symptom, on an Intel Battlemage G21 card with 16 GiB of video memory.
Underneath it, the compositor was making its first GPU submission and that submission was failing. GDM does the sensible thing when a session dies immediately, which is to start another one, and the loop that produces is indistinguishable from a machine that simply will not boot to a desktop. There is no error on screen because there is no screen.
Failures at that point in startup are unpleasant to debug for a structural reason: everything you would normally use to observe the system is downstream of the thing that is broken. You are debugging the display from a machine with no display.
The rounding direction
Intel GPUs reserve a region at the top of video memory for flat CCS, the compression metadata that lets the hardware compress framebuffers and other surfaces. Nothing else may touch it.
The function that works out where that region starts, get_flat_ccs_offset, computed an address and then aligned it to a 128 KiB boundary using round_up. That is the wrong direction for this particular calculation, and the consequence is precise: rounding the start of a reserved region up moves the boundary later, which makes the protected region smaller than the real one. The bytes between where the reserved region actually begins and where the rounded boundary sits stop being protected.
The VRAM allocator was then told those bytes were available. It handed them out. The compositor got memory the hardware was simultaneously treating as compression metadata, and its first submission failed.
Change round_up to round_down and the boundary moves the other way, the protected region becomes slightly larger than strictly necessary, and nothing outside it can be given away. That is the entire patch.
Why this class of bug is hard
Rounding direction errors are common in low level code, and they are common for a reason that has nothing to do with carelessness.
Both functions exist because both are needed. When you size an allocation you round up, because you need at least that much room. When you mark the boundary of something that must not be touched, you round down, because the protected region has to cover at least the real one. The two cases sit next to each other in the same files, the calls read almost identically, and a reviewer scanning a diff has no local signal telling them which question this particular line is answering.
Then the failure is non deterministic in practice. Whether anything goes wrong depends on where the computed offset happens to land relative to the alignment boundary, and on whether the allocator happens to reach into the gap. Some cards are fine. Some configurations are fine until a memory size changes. That is why it got through review and into a release rather than being caught by anyone's test rig.
The AI part, read carefully
Torvalds credited an AI with doing much of the grunt work, and the phrasing in his commentary is worth quoting rather than summarising. He described it as a debug session from hell, enormously helped by an AI doing much of the grunt work. Then, immediately: he would like to call it his tireless helper, but the AI several times stated flat out that this was impossible. And he suspects those things have been trained by people who may not be quite as stubborn as he is.
Both halves are the story. The model absorbed the mechanical cost of 24 rounds of instrumentation, which is a genuinely large amount of tedium and exactly the work that makes people abandon hard bugs. It also produced a confident assessment that the problem was unsolvable and that the right move was to write up a report instead. Torvalds ignored it and was right.
This is not an argument about whether models are useful for kernel work. Torvalds settled his own position on that in July 2026, saying Linux is not an anti AI project and that the tool gets judged on results, and the volume of model assisted patches arriving on the networking lists has already made the question practical rather than theoretical. It is a narrower point about calibration. A model that says a problem is impossible has produced an output, not a verdict, and this particular problem turned out to be a one word fix.
What to take from it
If you write code that computes the edge of a region something else must not use, the rounding direction is a correctness property. It deserves a comment at the call site saying which way the safety lies, in the same way a lock deserves a note about what it protects. GPU memory, DMA windows, firmware reservations, partition alignment: the shape recurs everywhere and the failure mode is always somebody else quietly using memory that was supposed to be off limits.
And when a bug does not bisect cleanly, the way through is measurement rather than theory. Twenty four patches and eighteen boots is not a sign that something went wrong with the process. It is what the process looks like when the answer is not guessable and somebody keeps going anyway.
Sources and further reading
- Linus Torvalds Endures A Debug Session From Hell, Enormously Helped By AI, Phoronix, August 21, 2026
- Linus Torvalds Turns to AI to Track Down Intel Xe GPU Bug, Linuxiac, August 2026
- Linus Torvalds Endures A Debug Session From Hell, Slashdot, August 21, 2026
Frequently asked questions
What was the actual bug?
Intel GPUs reserve a region at the top of video memory for flat CCS, the compression metadata that makes framebuffer compression work. The function that calculates where that reserved region begins, get_flat_ccs_offset, took the computed address and rounded it up to a 128 KiB boundary. Rounding up moves the boundary later, so the bytes between the true start of the reserved region and the rounded boundary fell outside what the driver considered reserved, and the VRAM allocator was told it could hand them out. It did. The compositor's very first GPU submission then landed on memory the hardware was also using as compression metadata, the submission failed, GDM restarted the session, and the whole thing looped. The fix was to round down instead.
Why is rounding down the correct direction for a reserved region?
Because the two rounding directions answer different questions and it is easy to reach for the wrong one. When you are sizing an allocation you round up, because you need at least that much space. When you are marking the boundary of a region that must not be touched, you round down, because you need the protected region to be at least as large as the true one. Rounding up a reserved region's start address shrinks the protected area, and everything between the real start and the rounded start becomes a gap that something else will eventually use. This is one of the more common shapes of memory bug in low level code precisely because both calls compile, both look reasonable in review, and the failure only appears when a specific allocator happens to reach into the gap.
Who was affected by this?
The symptom appeared on an Intel Battlemage G21 card with 16 GiB of video memory, which is the machine Torvalds was running. The failure mode is unmistakable if you hit it: a black screen and a display manager that restarts endlessly, because the compositor cannot complete its first GPU submission. Whether a given card hits it depends on where the flat CCS offset lands relative to the 128 KiB boundary and on whether the allocator happens to hand out the gap, so this is not a bug that reproduces on every configuration. That is also what made it hard. A bug that only some machines see, with no obvious relationship between hardware and symptom, is the kind that survives review and lands in a release.
What did the AI actually do here?
Grunt work, by Torvalds' own description: adding instrumentation, running through results, and eventually writing the long commit message. What it did not do was find the answer. Torvalds wrote that he would like to call it his tireless helper, but that the AI several times stated flat out that this was impossible, and added that he suspects those things have been trained by people who may not be quite as stubborn as he is. That is the useful reading of this story for anyone debugging with a model. It compressed the mechanical cost of 24 instrumentation rounds, which is real value, and it produced a confident wrong conclusion about tractability, which is a real hazard. Both things happened in the same session.
Is there a lesson beyond the specific fix?
Two. The first is about instrumentation as a strategy: when a bug does not bisect cleanly, the way through is to add measurement rather than to add theories, and 24 patches over 18 boots is what that looks like when it is done seriously. The second is about rounding in any code that computes the edge of a reserved region, whether that is GPU memory, a DMA window, a firmware reservation or a partition table. The direction is a correctness property, not a formatting choice, and it is worth a comment at the call site saying which way the safety lies. Neither lesson is new. Both keep being learned expensively.