Linus Torvalds en AI vinden een GPU-bug die met één regel werd opgelost

Een wijziging van één regel verhielp een ernstige fout in de Intel Xe-grafische driver op Battlemage G21-hardware. De weg naar die oplossing was echter allesbehalve eenvoudig. Linus Torvalds vertelde dat een AI-assistent hem hielp bij een groot deel van het repetitieve debugwerk: er waren 24 versies van debugpatches en 18 starts van de Linux-kernel nodig. Tegelijkertijd bleef de assistent herhaaldelijk volhouden dat het probleem onmogelijk op te lossen was.

De oplossing van één regel

De fout zat in de berekening van de grens tussen normaal VRAM en gereserveerde opslag voor de flat Compute Command Streamer (CCS) in de Intel Xe-driver. Conceptueel werd deze bewerking gewijzigd van:

round_up(value, SZ_128K)

naar:

round_down(value, SZ_128K)

Dat verschil is belangrijk. De berekende waarde gaf aan tot waar de VRAM-allocator geheugen als beschikbaar mocht beschouwen. Door die grens naar boven af te ronden, kon het kleine gebied tussen de echte grens en de afgeronde grens ten onrechte als vrije ruimte worden aangeboden. Dat gebied was in werkelijkheid gereserveerd voor CCS-compressiemetadata. Naar beneden afronden houdt de allocator aan de veilige kant van de grens.

Hoe de verkeerde afronding GPU-corruptie veroorzaakte

Zodra de allocator de CCS-opslag als normaal VRAM behandelde, konden gewone geheugenallocaties deze opslag overlappen en overschrijven. Daardoor raakte metadata beschadigd die de GPU nodig had, waaronder gegevens die verband hielden met paginatabellen. Op Battlemage G21-systemen leidde dat onder meer tot beeldcorruptie en een displaymanager van GDM die eindeloos bleef herstarten.

Het probleem was dus meer dan een simpele rekenfout. De code behandelde een waarde alsof die een beginadres was dat moest worden uitgelijnd, terwijl de waarde feitelijk een limiet aangaf: het punt waar bruikbaar geheugen ophoudt. Dat verklaart waarom de uiteindelijke correctie zo klein was, maar zo lastig te vinden bleek.

24 patches en 18 kernelstarts

Torvalds omschreef het onderzoek als een “debugsessie uit de hel”. Samen met de AI-assistent voegde hij gerichte instrumentatie toe en paste die steeds aan. Ze volgden de geheugenberekeningen van de driver en vergeleken de door de hardware gemelde CCS-positie met de grens die aan de VRAM-allocator werd doorgegeven. Pas na 24 versies van debugpatches en 18 herstarts met nieuwe tests werd duidelijk dat de verkeerde afrondingsrichting de oorzaak was.

De vele herstarts waren van belang omdat het probleem zich niet alleen als verdachte broncode manifesteerde. De gevolgen waren zichtbaar op het niveau van de hardware en het grafische systeem. Elke test hielp om gedrag van de geheugenallocator te onderscheiden van andere mogelijke oorzaken van de beeldproblemen.

AI versnelde het onderzoek, maar leidde het niet

Torvalds gebruikte de assistent als een interactieve partner tijdens het debuggen. De AI hielp bij het voorstellen van instrumentatie, het volgen van codepaden en het analyseren van de uitvoer van opeenvolgende experimenten. Daarmee werd vooral het repetitieve werk sneller.

De assistent was echter geen betrouwbare autoriteit. Volgens Torvalds concludeerde de AI meerdere keren dat het probleem onmogelijk of onoplosbaar was en stelde ze voor om er maar een rapport over te schrijven. Hij bleef zelf bepalen welk experiment de volgende stap was, herkende verkeerde interpretaties en begreep wat de betreffende offset betekende binnen het geheugenmodel van de allocator.

Dat onderscheid is de kern van dit verhaal. De AI genereerde mogelijkheden en hielp bij de uitvoering; de expert leverde de context, de volharding, de toetsbare experimenten en het uiteindelijke oordeel.

Waar de fix terechtkwam

Torvalds schreef en committeerde de oplossing voor de Intel Xe-driver in de upstream Linux-kernel. Volgens de beschikbare berichtgeving zouden betrokken onderhouden stabiele kernelreeksen de wijziging via het gebruikelijke backportproces ontvangen. De bronnen bieden echter geen betrouwbare basis om specifieke stabiele versies of releasedata te noemen.

Gebruikers met de betreffende hardware kunnen daarom het beste afgaan op aankondigingen van hun Linux-distributie of de kernelonderhouders om te controleren of een bepaalde kernelversie de fix bevat.

Wat dit zegt over AI in kernelontwikkeling

Deze gebeurtenis is geen algemene goedkeuring van door AI gegenereerde kernelcode. Ze laat vooral een beperktere en beter verdedigbare toepassing zien: een deskundige kan AI inzetten om een moeilijke debugcyclus te versnellen, terwijl die deskundige verantwoordelijk blijft voor de hypothese, het testontwerp, de controle en de patch.

Dat verschilt sterk van het versturen van ongeteste, ongevraagde AI-patches of kwetsbaarheidsmeldingen naar onderhouders. Linux-ontwikkelaars hebben gesproken over een “toestroom” van machinaal gegenereerde bijdragen. Onderhouders van staging en networking hebben daarnaast hun frustratie beschreven over patches met weinig waarde of zonder aantoonbaar begrip van het subsysteem.

Een vaak herhaalde claim over een stijging van 2.700 procent moet voorzichtig worden geïnterpreteerd. De aangeleverde berichtgeving maakt niet duidelijk hoe dat cijfer is gemeten, op welke periode het betrekking heeft en welke categorie inzendingen precies is geteld. De beter onderbouwde conclusie is algemener: AI heeft de kosten van het produceren van code en bugrapporten verlaagd, maar het beoordelen en sorteren van al die inzendingen blijft mensenwerk.

Torvalds heeft bovendien betoogd dat Linux niet categorisch tegen AI-tools is, zeker niet wanneer die bijvoorbeeld voor code review worden gebruikt. De Intel Xe-sessie maakt de praktische grens duidelijk: AI kan nuttig zijn binnen een gedisciplineerd engineeringproces, maar vervangt geen kennis van het subsysteem, reproduceerbare tests of menselijke verantwoordelijkheid voor het resultaat.

De uiteindelijke patch bestond uit één regel. De echte prestatie was weten welke regel moest worden aangepast — en blijven zoeken toen de assistent zei dat het antwoord niet te vinden was.