Twenty-four diagnostic patches and 18 kernel boots led to a change from round_up() to round_down(). The bad calculation exposed only 2 KiB of reserved Intel GPU memory, yet that sliver was enough to corrupt a page table and leave a 16 GiB Battlemage machine at a black screen. Linus Torvalds said AI handled much of the investigative grunt work, then added the detail that makes this more useful than another story about AI writing code: the assistant repeatedly declared the bug impossible and tried to end the investigation.
The Linux commit that fixes the bug is unusually candid about both the machine failure and the debugging process. Torvalds kept pushing after the assistant proposed writing a report and stopping. In response, it continued adding instrumentation and analyzing the results. He credited that work and let the AI draft the commit message, but the record does not identify the model or claim that it found the final fix on its own.
That distinction matters for developers evaluating coding assistants. The useful work here was repetitive, stateful investigation across reboots. The failure was knowing when the evidence justified continuing. A model can produce another probe or read another memory dump while still making the wrong call about whether the search has reached a dead end.
Two kilobytes in the wrong address range
The bug sat in get_flat_ccs_offset(), a function in Intel's Xe graphics driver. Flat CCS is storage used by the GPU's compression hardware. The driver reads the start of that reserved area from hardware, adjusts it for the number of enabled L3 nodes, then uses the resulting address as the end of VRAM available to the allocator, according to Torvalds' fix description. Everything below the boundary may be handed to software. Everything at or above it belongs to hardware.
On the affected Battlemage G21 system, the actual Flat CCS base was 0x3fafff800. The driver rounded that upward to 0x3fb000000, putting the final 2 KiB of page 0x3fafff000 on both sides of the ownership line. Software saw the whole 4 KiB page as free. The compression unit still treated its upper half as metadata storage.
That overlap was unusually hard to observe because the hardware did not need a buffer object, a GPU command or even a page-table entry to write there. Torvalds reported that it happened before userspace started. Conventional reasoning about which submitted workload damaged memory therefore pointed away from the component doing the writing.
The victim allocation was consistent on cold boots of this machine. A Mesa virtual machine's level-three page table landed on the disputed page, and the compression unit overwrote the entry that covered the compositor's batch-buffer heap. The compositor faulted on its first submission, so GDM kept restarting it and the display stayed black. Restarting GDM manually appeared to cure the machine because the next page table was allocated elsewhere, the commit explains.
This symptom is a good trap. A cold boot failed in a repeatable way, while restarting a service changed the result. That pattern can look like a timing problem in userspace. Here, it was allocation placement: the first Mesa VM repeatedly received the poisoned page, and the next one did not.
The one-line fix has page-sized consequences
The core correction is small enough to read without knowing the rest of the driver:
/* old */
offset = round_up(offset, SZ_128K);
/* fixed */
offset = round_down(offset, SZ_4K);
Rounding down matches the meaning of the value. It is the first address owned by compression hardware, so the allocator's upper limit cannot move past it. The allocator works in 4 KiB pages, which means a page shared by ordinary VRAM and a reserved tail cannot safely be allocated at all. The fix therefore withholds one complete page on Torvalds' test system, even though hardware occupied only its final 2 KiB.
The earlier code was not an arbitrary typo. A September 2024 Xe commit said the hardware specification required software to round up to the nearest 128 KiB. That patch added exactly the round_up() call now being removed, carried a Fixes tag of its own and was marked for stable kernels from 6.10 onward. The new commit says the scaled Flat CCS address has no reason to retain 128 KiB alignment on the tested configuration.
This is where the direction of a harmless-looking rounding operation becomes an ownership rule. Rounding a requested allocation size upward usually reserves enough space. Rounding the end of usable memory upward grants software addresses it does not own. The same verb describes opposite safety effects because the values represent different sides of an interval.
The patch changes more than the rounding line. It adds a comment that states the ownership invariant in plain terms and replaces the previous assertion. The old test compared the calculated offset with GSMBASE - ccs_size for equality. That comparison value was itself 128 KiB aligned, so it agreed with the rounded result in precisely the case where the true base was not aligned. Torvalds wrote that the assertion could not fail when it most needed to.
The replacement checks that Flat CCS storage does not run into GSM. That is a direct property of the memory map rather than a comparison between two values shaped by the same mistaken assumption. It also matters that the old assertion was present only when CONFIG_DRM_XE_DEBUG was enabled, as the fix notes. A debug check that cannot reject the failing state offers false comfort during exactly the builds meant to expose driver mistakes.
What the AI contribution did and did not prove
Torvalds described the session as a "debug session from hell" and said AI helped "enormously" with the grunt work. Those are specific claims about one investigation, written by the developer who ran it. The same note says the assistant several times called the problem "impossible and unsolvable" and recommended producing a report instead of continuing.
The productive division of labor was uneven. The assistant could keep generating debug changes and interpreting new output when directed. Torvalds supplied persistence, decided the stopping advice was wrong and forced another cycle of evidence collection. Across 24 patches and 18 boots, that judgment controlled whether any later evidence existed to analyze.
There is no basis in the commit for turning the episode into a benchmark score. It names no model, prompt, transcript, elapsed time or comparison run without AI. We cannot tell whether a different tool would have reached the same diagnosis faster, or whether Torvalds would have solved it with fewer iterations alone. We can say that this assistant contributed useful technical labor while repeatedly misjudging the investigation's viability.
The drafted commit message is also a narrow success. It gives exact addresses, reconstructs the corruption path, shows the observed metadata pattern and explains why the assertion failed. Torvalds accepted that account into the kernel history. Acceptance supports the quality of this particular output after human investigation and review. It does not tell us who first formed each part of the explanation.
For maintainers, the episode suggests a practical boundary for agent use in low-level debugging. Asking an assistant to extend instrumentation or organize results leaves the next action under human control. Letting its confidence decide when to stop hands over a different kind of authority, one for which this session produced several wrong answers. Persistence was part of the technical method because each reboot created the evidence needed for the next patch.
Why the driver context made the failure expensive
Linux's Xe memory-management documentation explains that the driver uses buffer objects for page tables and other kernel work, with placement in system memory or VRAM. Some kernel buffer objects must be contiguous and restored to the same physical location. Corrupting a page-table allocation is therefore very different from flipping unused pixels in a disposable frame buffer: it changes where the GPU believes other objects reside.
The Xe driver also spans rendering, display, compute and media, while its display support is shared with Intel's i915 display driver, according to the kernel's Xe overview. That division helps explain why the visible failure appeared several layers away from the allocator calculation. The bad boundary was in VRAM setup, the damaged object belonged to a Mesa VM, the first failed access involved a compositor batch, and GDM exposed the loop to the user.
Kernel documentation says Xe assertions exist to catch unwanted states during code integration without imposing their footprint on production builds. In this case, the documented debug mechanism was present, but the condition encoded the same alignment assumption as the buggy calculation. More debug machinery would not have helped until the invariant itself changed.
The fix carries a Fixes reference to the 2024 rounding patch and is copied to the stable-kernel maintainers. The next concrete signals will be which supported stable branches receive it and whether reports identify other Flat CCS configurations with the same boundary condition. The current evidence is narrower: one 16 GiB Battlemage G21 system, one excluded 4 KiB page and a black screen traced to 2 KiB that software should never have owned.