round_up(value, SZ_128K)

till:

round_down(value, SZ_128K)

Skillnaden är avgörande. Värdet beskrev slutpunkten för det minne som VRAM-allokeraren fick använda. När gränsen avrundades uppåt kunde det lilla området mellan den verkliga gränsen och den avrundade gränsen felaktigt se ut som ledigt minne. Området var i själva verket reserverat för CCS-komprimeringsmetadata.

Genom att avrunda nedåt stannar allokeraren på den säkra sidan av gränsen.

Därför blev avrundningsfelet så destruktivt

När allokeraren betraktade CCS-lagringen som vanligt VRAM kunde normala minnesallokeringar överlappa och skriva över metadata som grafikprocessorn behövde. Korruptionen påverkade bland annat data kopplade till sidtabeller och ledde till skärmfel samt en GDM-displayhanterare som startade om i all oändlighet på Battlemage G21.

Det handlade alltså inte bara om ett enkelt räknefel. Problemet var en betydelsekrock i koden: värdet behandlades som om det vore en startadress som skulle justeras, trots att det fungerade som en gräns som markerade var det användbara minnet tog slut.

Det förklarar varför den slutliga korrigeringen blev så liten – och varför den var så svår att hitta.

24 patchar och 18 uppstarter ringade in felet

Torvalds och AI-assistenten lade till och ändrade riktad instrumentering, följde drivrutinens minnesberäkningar och jämförde CCS-positionen som hårdvaran rapporterade med den gräns som skickades vidare till VRAM-allokeraren. Det krävdes 24 versioner av felsökningspatchar och 18 omstarter med tester innan den felaktiga avrundningen blev tydlig.

De många omstarterna var viktiga eftersom felet visade sig på hårdvaru- och displaysystemnivå, inte bara som en misstänkt kodrad. Varje experiment hjälpte till att skilja problem med minnesallokering från andra möjliga orsaker till grafikfelen.

AI:n skyndade på arbetet – men ledde det inte

Torvalds använde assistenten som en interaktiv felsökningspartner. Den kunde föreslå instrumentering, följa kodvägar och hjälpa till att analysera resultaten från de olika experimenten. På så sätt minskade mängden monotont arbete i hypotesprövningen.

Men AI:n var ingen tillförlitlig auktoritet. Enligt Torvalds drog den flera gånger slutsatsen att problemet var omöjligt eller olösligt och föreslog att man i stället skulle skriva en rapport om det. Han höll själv undersökningen på rätt spår genom att välja nästa experiment, upptäcka när en tolkning var fel och förstå vad förskjutningen betydde i allokerarens minnesmodell.

Det är den viktigaste lärdomen från händelsen. AI:n kunde generera förslag och sköta mycket av det praktiska; experten stod för sammanhanget, uthålligheten, testningen och det slutliga omdömet.

Fixen är inskickad – men exakta stabilversioner är inte bekräftade

Torvalds skrev och committade fixen för Intel Xe-drivrutinen till den uppströmsversion av Linux-kärnan. Tillgänglig rapportering pekar på att berörda underhållna stabila kärnserier skulle få ändringen genom den vanliga processen för bakportering, men källorna här fastställer inte på ett tillförlitligt sätt vilka stabilversioner eller releasedatum som gäller.

Det är därför för tidigt att ange specifika versioner. Användare med berörd hårdvara bör invänta besked från sin distribution eller från kärnans underhållare för att bekräfta att en viss version innehåller lösningen.

En mer nyanserad bild av AI i kärnutveckling

Händelsen är inte ett generellt godkännande av AI-genererad kärnkod. Den visar snarare ett mer avgränsat och hållbart användningsområde: en erfaren utvecklare kan använda AI för att snabba upp en svår felsökningsloop, samtidigt som människan behåller ansvaret för hypotesen, testdesignen, granskningen och patchen.

Det skiljer sig tydligt från att skicka oprövade, oombedda AI-patchar eller sårbarhetsrapporter till underhållare. Kärnutvecklare har beskrivit en ”anstormning” av maskingenererade bidrag, medan underhållare inom staging och nätverk har rapporterat växande frustration över patchar med lågt värde eller utan tillräcklig förståelse för systemet.

Ett ofta upprepat påstående om en ökning på 2 700 procent bör hanteras försiktigt. Den tillgängliga rapporteringen visar inte hur siffran har mätts, vilken tidsperiod den gäller eller exakt vilken typ av inskick den avser. Den mer välunderbyggda slutsatsen är generell: AI har gjort det billigare att producera kod och rapporter, men kostnaden för att granska och sortera materialet hamnar fortfarande hos mänskliga underhållare.

Torvalds har också sagt att Linux inte kategoriskt motsätter sig AI-verktyg, särskilt när de används för exempelvis kodgranskning. Felsökningen av Intel Xe visar den praktiska gränsen: AI kan vara användbart inom en disciplinerad ingenjörsprocess, men ersätter inte kunskap om delsystemet, reproducerbara tester eller mänskligt ansvar för resultatet.

Den slutliga patchen var en rad. Den verkliga bedriften var att förstå vilken rad som behövde ändras – och att fortsätta leta när assistenten hävdade att svaret inte gick att hitta.

round_up(value, SZ_128K)

till:

round_down(value, SZ_128K)

Skillnaden är avgörande. Värdet beskrev slutpunkten för det minne som VRAM-allokeraren fick använda. När gränsen avrundades uppåt kunde det lilla området mellan den verkliga gränsen och den avrundade gränsen felaktigt se ut som ledigt minne. Området var i själva verket reserverat för CCS-komprimeringsmetadata.

Genom att avrunda nedåt stannar allokeraren på den säkra sidan av gränsen.

Därför blev avrundningsfelet så destruktivt

När allokeraren betraktade CCS-lagringen som vanligt VRAM kunde normala minnesallokeringar överlappa och skriva över metadata som grafikprocessorn behövde. Korruptionen påverkade bland annat data kopplade till sidtabeller och ledde till skärmfel samt en GDM-displayhanterare som startade om i all oändlighet på Battlemage G21.

Det handlade alltså inte bara om ett enkelt räknefel. Problemet var en betydelsekrock i koden: värdet behandlades som om det vore en startadress som skulle justeras, trots att det fungerade som en gräns som markerade var det användbara minnet tog slut.

Det förklarar varför den slutliga korrigeringen blev så liten – och varför den var så svår att hitta.

24 patchar och 18 uppstarter ringade in felet

Torvalds och AI-assistenten lade till och ändrade riktad instrumentering, följde drivrutinens minnesberäkningar och jämförde CCS-positionen som hårdvaran rapporterade med den gräns som skickades vidare till VRAM-allokeraren. Det krävdes 24 versioner av felsökningspatchar och 18 omstarter med tester innan den felaktiga avrundningen blev tydlig.

De många omstarterna var viktiga eftersom felet visade sig på hårdvaru- och displaysystemnivå, inte bara som en misstänkt kodrad. Varje experiment hjälpte till att skilja problem med minnesallokering från andra möjliga orsaker till grafikfelen.

AI:n skyndade på arbetet – men ledde det inte

Torvalds använde assistenten som en interaktiv felsökningspartner. Den kunde föreslå instrumentering, följa kodvägar och hjälpa till att analysera resultaten från de olika experimenten. På så sätt minskade mängden monotont arbete i hypotesprövningen.

Men AI:n var ingen tillförlitlig auktoritet. Enligt Torvalds drog den flera gånger slutsatsen att problemet var omöjligt eller olösligt och föreslog att man i stället skulle skriva en rapport om det. Han höll själv undersökningen på rätt spår genom att välja nästa experiment, upptäcka när en tolkning var fel och förstå vad förskjutningen betydde i allokerarens minnesmodell.

Det är den viktigaste lärdomen från händelsen. AI:n kunde generera förslag och sköta mycket av det praktiska; experten stod för sammanhanget, uthålligheten, testningen och det slutliga omdömet.

Fixen är inskickad – men exakta stabilversioner är inte bekräftade

Torvalds skrev och committade fixen för Intel Xe-drivrutinen till den uppströmsversion av Linux-kärnan. Tillgänglig rapportering pekar på att berörda underhållna stabila kärnserier skulle få ändringen genom den vanliga processen för bakportering, men källorna här fastställer inte på ett tillförlitligt sätt vilka stabilversioner eller releasedatum som gäller.

Det är därför för tidigt att ange specifika versioner. Användare med berörd hårdvara bör invänta besked från sin distribution eller från kärnans underhållare för att bekräfta att en viss version innehåller lösningen.

En mer nyanserad bild av AI i kärnutveckling

Händelsen är inte ett generellt godkännande av AI-genererad kärnkod. Den visar snarare ett mer avgränsat och hållbart användningsområde: en erfaren utvecklare kan använda AI för att snabba upp en svår felsökningsloop, samtidigt som människan behåller ansvaret för hypotesen, testdesignen, granskningen och patchen.

Det skiljer sig tydligt från att skicka oprövade, oombedda AI-patchar eller sårbarhetsrapporter till underhållare. Kärnutvecklare har beskrivit en ”anstormning” av maskingenererade bidrag, medan underhållare inom staging och nätverk har rapporterat växande frustration över patchar med lågt värde eller utan tillräcklig förståelse för systemet.

Ett ofta upprepat påstående om en ökning på 2 700 procent bör hanteras försiktigt. Den tillgängliga rapporteringen visar inte hur siffran har mätts, vilken tidsperiod den gäller eller exakt vilken typ av inskick den avser. Den mer välunderbyggda slutsatsen är generell: AI har gjort det billigare att producera kod och rapporter, men kostnaden för att granska och sortera materialet hamnar fortfarande hos mänskliga underhållare.

Torvalds har också sagt att Linux inte kategoriskt motsätter sig AI-verktyg, särskilt när de används för exempelvis kodgranskning. Felsökningen av Intel Xe visar den praktiska gränsen: AI kan vara användbart inom en disciplinerad ingenjörsprocess, men ersätter inte kunskap om delsystemet, reproducerbara tester eller mänskligt ansvar för resultatet.

Den slutliga patchen var en rad. Den verkliga bedriften var att förstå vilken rad som behövde ändras – och att fortsätta leta när assistenten hävdade att svaret inte gick att hitta.