Linus Torvalds scova un bug Intel con l'AI e dà una lezione a tutti

Un bug capace di lasciare una macchina Linux davanti a uno schermo nero può scaturire da una singola operazione di arrotondamento. È quanto ha scoperto Linus Torvalds analizzando un problema nel driver grafico Intel Xe: la correzione decisiva consiste sostanzialmente nel sostituire l’uso della funzione round_up() con un round_down(), ma per arrivarci il “re pinguino” ha dovuto modificare il codice di debug 24 volte e riavviare il sistema 18 volte con versioni del kernel contenenti controlli diagnostici diversi.

La parte insolita della storia riguarda il metodo seguito: Torvalds racconta di aver affidato a un sistema di intelligenza artificiale buona parte del lavoro ripetitivo necessario per aggiungere strumenti di debug, interpretarne l’output e restringere progressivamente il campo della ricerca.

Il caso è particolarmente interessante perché riguarda drm/xe, il driver Linux che Intel ha sviluppato come base aggiornata e, quindi, “allo stato dell’arte”, per le GPU più recenti. Xe è entrato nel kernel upstream a partire dalla serie 6.8, inizialmente con numerose piattaforme utilizzabili soprattutto a fini sperimentali; sulle generazioni Xe2 e successive ha poi assunto un ruolo centrale.

Torvalds usa l’AI per un lavoro di debug molto diverso dal semplice “vibe coding”

Linus Torvalds non ha chiesto a un chatbot di “scrivere il driver Intel” e non ha accettato codice generato automaticamente confidando che funzionasse. Il modello ha svolto soprattutto il ruolo di assistente durante una lunga sessione di debugging: aggiungeva controlli, produceva modifiche diagnostiche e aiutava ad analizzare i dati raccolti dopo ogni nuovo avvio.

L’inventore del kernel Linux descrive l’esperienza con una certa dose di ironia. L’AI, racconta, a un certo punto ha dichiarato più volte che il problema sembrava impossibile da risolvere e che sarebbe stato meglio limitarsi a documentarlo. Lui ha insistito. Il modello ha continuato a preparare ulteriore codice diagnostico e a esaminare i risultati, fino a quando le osservazioni accumulate hanno permesso di individuare l’errore.

In pratica, l’AI ha svolto bene la parte più meccanica e paziente del lavoro, ma non ha sostituito la direzione tecnica dell’indagine. È una distinzione importante: il valore non nasce dal numero di righe che il modello riesce a generare, bensì dalla possibilità di accelerare un ciclo ripetitivo che poggia su ipotesi, strumentazione, compilazione, boot, raccolta dei dati e nuova ipotesi.

Perché il problema è diventato improvvisamente riproducibile dopo quasi due anni

Torvalds osserva che non sa con certezza perché il difetto, presente da tempo nel driver drm/xe, abbia iniziato a manifestarsi quasi a ogni boot.

La sua ipotesi è che un aggiornamento di qualche componente in userspace – per esempio Mesa, il compositor o il display manager – abbia cambiato il modo in cui la memoria della GPU viene richiesta e organizzata. Di conseguenza, durante l’avvio, una delle page table usate dalla GPU ha iniziato a essere collocata più spesso proprio nella pagina che il driver riteneva libera, ma che in realtà veniva usata anche dall’hardware Intel per conservare le informazioni necessarie a gestire la compressione della memoria grafica.

Non sarebbe affatto sorprendente. I bug di corruzione della memoria dipendenti dalla disposizione delle allocazioni possono restare silenziosi per mesi o anni.

Basta aggiornare un componente che cambia l’ordine o il momento in cui la GPU alloca le proprie strutture in memoria perché un bug fino a quel momento raro finisca per presentarsi con regolarità. La causa resta nel kernel, anche se il fattore che la rende visibile può trovarsi altrove.

L’aspetto più interessante dell’AI è ciò che non ha fatto

L’intera vicenda potrebbe facilmente ridursi a “Linus Torvalds usa l’AI per correggere Linux“, ma sarebbe una lettura superficiale.

Il modello AI non ha riconosciuto immediatamente l’errore, non ha mostrato una determinazione particolare nel cercarlo e, stando allo stesso Torvalds, ha suggerito più volte di arrendersi. Ha però dimostrato una qualità molto concreta: quando guidato da qualcuno che conosce profondamente il problema, può produrre rapidamente ulteriore strumentazione, modificare il codice diagnostico e aiutare a confrontare grandi quantità di informazioni senza stancarsi del lavoro ripetitivo.

Il ruolo umano rimane evidente: serve decidere quale prompt proporre al sistema, capire se una sua conclusione ha senso, rifiutare un vicolo cieco, scegliere quali dati raccogliere e soprattutto stabilire quando le prove sono abbastanza solide da modificare codice che gestisce direttamente l’hardware.

Persino il messaggio del commit finale ha una piccola particolarità: Torvalds dice di aver lasciato che fosse l’AI a scriverlo. Ma la patch porta la sua firma, deriva da una sessione di debug guidata da lui e contiene una verifica tecnica riproducibile. È una modalità d’uso molto lontana dall’accettazione automatica di codice generato.

Un caso concreto di AI utile nello sviluppo software

Per gli sviluppatori la lezione va oltre Linux e Intel. I modelli generativi sembrano particolarmente utili quando possono lavorare dentro un ciclo sperimentale controllato, dove ogni loro proposta produce dati verificabili. Aggiungere un printk, costruire un controllo, confrontare indirizzi, preparare una patch temporanea o sintetizzare l’output di più boot sono attività che si prestano bene all’automazione assistita.

Con buona pace dei detrattori, i modelli AI non sono Lucifero: e utilizzati con competenza, spirito critico e verifiche puntuali, possono diventare strumenti estremamente utili, soprattutto nelle attività iterative e ripetitive che accompagnano la risoluzione di problemi complessi.

Nel campo del debugging hardware mancano spesso informazioni essenziali: stato interno del dispositivo, timing, registri, disposizione delle allocazioni e comportamento osservato durante l’esecuzione. Nessun modello può dedurre con certezza dati che non possiede; però aiutare a costruire gli esperimenti che li fanno emergere. Sterili prese di posizione “pro AI” o “contro AI” fanno soltanto male e sono generalmente portate innanzi da chi “non si è mai sporcato le mani”.

Alla fine Torvalds ha corretto un problema vecchio di quasi 2 anni cambiando un arrotondamento. Dietro quella singola riga c’erano una GPU Battlemage, memoria CCS sovrapposta alla VRAM allocabile, page table corrotte, un compositor che non riusciva a partire, 24 patch temporanee, 18 boot e un assistente AI che avrebbe preferito arrendersi prima del suo utilizzatore. Più che una dimostrazione della capacità dell’AI di programmare Linux da sola, è forse uno degli esempi più chiari di dove questi strumenti possono davvero far risparmiare lavoro a chi sa già come condurre una verifica tecnica.