Linus Torvalds og AI fandt en GPU-fejl, der blev løst med én linje kode

Derfor blev grafikken ødelagt

Da allokatoren behandlede CCS-lageret som almindelig VRAM, kunne nye allokeringer overlappe og overskrive metadata, som GPU’en havde brug for. Korruptionen ramte blandt andet data med forbindelse til sidetabeller og gav symptomer som skærmforstyrrelser og en GDM-loginmanager, der blev ved med at genstarte på Battlemage G21-systemer.

Det var altså ikke blot en banal regnefejl. Problemet var en betydningsfejl i koden: En værdi, der fungerede som en grænse for, hvor den brugbare hukommelse sluttede, blev behandlet som en startadresse. Derfor var den endelige rettelse lille, selv om den var vanskelig at finde.

24 patches og 18 genstarter indsnævrede fejlen

Torvalds og AI-assistenten tilføjede og justerede målrettet fejlsøgningsinstrumentering, fulgte driverens hukommelsesberegninger og sammenlignede den CCS-placering, hardwaren rapporterede, med den grænse, som VRAM-allokatoren fik. Det krævede 24 versioner af debug-patches og 18 cyklusser med genstart og test, før den forkerte afrunding blev afsløret.

Genstarterne var vigtige, fordi fejlen viste sig på både hardware- og displaysystemniveau – ikke kun som en mistænkelig kodelinje. Hvert forsøg gjorde det muligt at skelne problemer med hukommelsesallokering fra andre mulige årsager til grafikfejlene.

AI’en satte fart på arbejdet – men styrede det ikke

Torvalds brugte AI’en som en interaktiv debugging-partner. Den kunne foreslå instrumentering, følge kodeveje og hjælpe med at analysere resultaterne fra de forskellige eksperimenter. Det reducerede det gentagne arbejde ved at teste hypoteser.

Men assistenten var ikke en autoritet, man kunne stole blindt på. Torvalds fortæller, at den flere gange konkluderede, at problemet var umuligt eller uløseligt, og foreslog at skrive en rapport i stedet. Han måtte selv vælge det næste eksperiment, gennemskue forkerte fortolkninger og forstå, hvad forskydningen betød i allokatorens hukommelsesmodel.

Det er den vigtigste pointe i historien: AI’en genererede muligheder og håndterede mekanikken, mens eksperten leverede kontekst, vedholdenhed, testbare hypoteser og den endelige vurdering.

Rettelsen er sendt til Linux-kernen – men stable-versionen er uklar

Torvalds skrev selv rettelsen og committede den til den upstream Linux-kernel. De tilgængelige oplysninger peger på, at berørte vedligeholdte stable-serier forventes at få ændringen via den normale backport-proces. Kilderne fastslår dog ikke pålideligt, hvilke konkrete stable-versioner der får rettelsen, eller hvornår de udgives.

Det er derfor for tidligt at pege på bestemte kernel-versioner. Brugere med den berørte hardware bør holde øje med meddelelser fra deres Linux-distribution eller kernel-maintainere for at se, om en bestemt pakke indeholder rettelsen.

Den bredere lektie om AI i kernel-udvikling

Forløbet er ikke en blankocheck til AI-genereret kernel-kode. Det viser snarere en mere begrænset og holdbar anvendelse: En erfaren udvikler kan bruge AI til at gøre en vanskelig debugging-loop hurtigere, samtidig med at udvikleren selv har ansvaret for hypoteser, testdesign, gennemgang og den færdige patch.

Det er noget helt andet end at sende uprøvede, uopfordrede AI-genererede patches eller sårbarhedsrapporter til maintainere. Kernel-udviklere har beskrevet en “invasion” af maskinskabte bidrag, mens maintainere i blandt andet staging- og netværksområderne har meldt om stigende frustration over patches med lav værdi eller manglende teknisk forståelse.

En ofte gentaget påstand om en stigning på 2.700 procent bør behandles med forsigtighed. Den tilgængelige rapportering dokumenterer ikke målemetoden, tidsperioden eller den præcise kategori bag tallet. Den bedre underbyggede konklusion er mere generel: AI har gjort det billigt at producere kode og rapporter, men det kræver stadig menneskelig tid at gennemgå og sortere materialet.

Torvalds har også argumenteret for, at Linux ikke er kategorisk imod AI-værktøjer – især når de bruges til eksempelvis kodegennemgang. Intel Xe-forløbet viser dog den praktiske grænse: AI kan være nyttig som en del af en disciplineret udviklingsproces, men den erstatter hverken viden om subsystemet, reproducerbare tests eller et menneske, der tager ejerskab for resultatet.

Den endelige patch fyldte én linje. Den egentlige bedrift var at vide, hvilken linje der skulle ændres – og at blive ved, da assistenten sagde, at svaret ikke kunne findes.