Linus Torvalds Made an AI Debug a GPU Bug, and It Tried to Quit Twice Linus Torvalds fixed a two-year-old Linux kernel bug in Intel's Xe GPU driver that caused black screens on Intel Arc GPUs, after 24 debug patches and 18 kernel boots. The fix changed a memory offset rounding from round_up() to round_down(), preventing protected compression memory from being exposed as usable VRAM. Torvalds credited an AI assistant for grunt work but said it repeatedly insisted the bug was unsolvable and suggested filing a report. Linus Torvalds spent the better part of a day chasing a bug that had been sitting in the Linux kernel for two years. The actual fix came down to one line of logic. Finding it took eighteen kernel boots, twenty four debug patches, and an AI assistant that kept telling him the whole thing was unsolvable. The Short Version The bug: a memory offset in Intel’s Xe GPU driver rounded up instead of down, exposing protected compression memory as regular usable VRAM The symptom: random black screens on boot, caused by a login manager crash loop on affected Intel Arc GPUs The age: the flawed code had been in the kernel for two years before it turned reliably reproducible The hunt: 24 rounds of debug patches across 18 kernel boots The fix: round the boundary down to a 4KB page instead of up to a 128KB hardware alignment, changing round up to round down A Black Screen With No Explanation On certain Intel Arc graphics cards, cold booting into a Linux desktop sometimes ended in a black screen. No crash message, no kernel panic. Just gdm, the GNOME login manager, restarting the session over and over while the compositor failed to draw anything at all. For a long time the bug showed up too rarely to pin down. That changed on Torvalds’ own machine, where it started happening on nearly every cold boot. He never nailed down exactly what shifted, only that some change in user-space behavior made the bug reliable enough to chase. The Memory That Was Never Actually Free The root cause lived inside a function called get flat ccs offset , which calculates where a block of memory reserved for the GPU’s compression hardware begins. Everything below that address gets handed to the driver’s memory allocator as ordinary usable VRAM. The function rounded that address up to the nearest 128 kilobytes. On most cards the rounding never mattered. On a Battlemage-based Arc GPU with 16 gigabytes of memory, it mattered a lot. The real boundary sat at address 0x3fafff800 . Rounded up, the driver believed it started at 0x3fb000000 instead, a gap of roughly two kilobytes that got handed out as free memory when it was nothing of the sort. One Page, One Crash Loop On Torvalds’ system, a GPU page table that Mesa the open-source graphics stack had set up kept landing directly inside that mismarked gap. Each time it did, the compression hardware quietly overwrote part of the table and erased the entry pointing to the compositor’s batch buffer memory. The compositor’s next command to the GPU had nowhere to go. It faulted. gdm caught the crash and restarted the session, which ran straight into the same missing entry and faulted again. Manually restarting gdm looked like a fix, but only because the next attempt happened to place the page table somewhere the compression hardware never touched. Proof Was Sitting in the Page Itself Once the bad page was identified, reading its contents afterward confirmed exactly what had been happening to it. Instead of driver data, the page was full of values like 0xcccc000000000000 and 0xcc77000000000000 , repeating in a pattern with roughly two bytes of real content for every sixteen. That pattern matches compression metadata, not anything a user program would ever write. The compression hardware had been using memory the driver thought was free the entire time. An AI That Kept Wanting to Write a Report Instead Torvalds credited an AI assistant with doing much of what he called the grunt work of the investigation: adding debug instrumentation and working through whatever it produced. He was also blunt about how reluctant that assistant was. By his account, the AI repeatedly insisted the bug was impossible to solve and suggested filing a report and moving on instead. He kept pushing back, and each time he did, the AI added more debug code and analyzed the results rather than giving up. He later joked that whoever trained it was probably less stubborn than he is. Getting to the real cause took 24 rounds of debug patches across 18 separate kernel boots . The fix itself was a single changed function call, round up swapped for round down . Torvalds let the AI write the final commit message. A Safety Check That Could Never Trip Buried in the same function was an assertion meant to catch this kind of problem, a check comparing the already-rounded offset against a second boundary value using strict equality. Rounding always produced a value matching that boundary, whether or not the real hardware address underneath was actually misaligned. The one scenario the check existed to catch was exactly the scenario it could never flag. On top of that, it only ran in debug builds with a specific config flag enabled, so most people compiling the kernel never had it active to begin with. The replacement checks that the compression memory fits inside its boundary using an inequality instead of an exact match, a test that can genuinely fail if the same mistake ever creeps back in. What the Rest of the Internet Took From It The story spread past the kernel mailing list fast, and the reaction on Reddit leaned heavily in one direction: this is what using AI for serious engineering actually looks like. Not typing a prompt and shipping whatever comes back, but treating the output the way you’d treat a patch from a stranger: checking it, pushing back on it, and throwing out the parts that don’t hold up. Not everyone thought it changed the bigger picture. A handful of commenters pointed out that Torvalds represents a tiny slice of how people actually use these tools, and that one well-supervised debugging session doesn’t erase concerns about AI-generated code flooding other projects with far less scrutiny than the Linux kernel gets. Still, the dominant reaction was closer to relief than worry. One popular comparison likened AI to a tool: in the hands of someone who knows what they’re doing, it produces excellent results. In the hands of someone who doesn’t, the outcome tends to look more like an accident waiting to happen. More than one commenter suggested a new prompting trick after reading Torvalds’ account: open every debugging session by telling the model it’s talking to Linus Torvalds. The Fix Nobody Will Notice The change landed as commit 818bebe https://github.com/torvalds/linux/commit/818bebeb63dd6bf5f4e07e145f6cdbace520a34c in Torvalds’ own tree, eighteen lines added and five removed in a single file. On his machine, the new rounding rule excludes exactly one page from the usable memory pool, the same page that had been silently breaking things on every boot. Most people running an affected Arc GPU will never know any of this happened. Their screen will just turn on. Somewhere in the commit history now sits proof that the fastest way through a two-year-old bug wasn’t smarter software. It was a maintainer who refused to accept “impossible” as a final answer, and an AI that eventually ran out of ways to say no.