Vai al contenuto
Offerte

Linus Torvalds usa l’AI e scova un bug nel driver Intel Xe

In questo articolo Indice dei contenuti 3 sezioni

Bastava un arrotondamento sbagliato per mandare in tilt una macchina Linux, e a scoprirlo è stato Linus Torvalds, che ha stanato un bug del driver grafico Intel Xe rimasto nascosto per quasi due anni. La correzione, alla fine, si riduce quasi a niente: sostituire una chiamata a roundup() con rounddown(). Il percorso per arrivarci, però, è stato tutt’altro che immediato, tra 24 modifiche al codice di debug e 18 riavvii del sistema con versioni del kernel che contenevano controlli diagnostici sempre diversi.

La parte che ha fatto discutere non è tanto il difetto in sé, quanto il metodo. Torvalds racconta di aver delegato a un sistema di intelligenza artificiale buona parte del lavoro ripetitivo: aggiungere strumenti di debug, leggerne l’output, restringere pian piano il campo delle ipotesi. Il caso riguarda drm/xe, il driver che Intel ha costruito come base aggiornata per le GPU più recenti, entrato nel kernel upstream con la serie 6.8 e diventato centrale a partire dalle generazioni Xe2.

Un debug guidato dall’uomo, con l’AI a fare la parte noiosa

Nessuno ha chiesto a un chatbot di scrivere il driver Intel al posto degli sviluppatori. Il modello ha fatto l’assistente durante una lunga sessione di debugging: preparava controlli, produceva modifiche diagnostiche, aiutava ad analizzare i dati raccolti dopo ogni nuovo avvio. Il papà del kernel Linux racconta la cosa con una certa ironia, perché a un certo punto l’AI ha dichiarato più volte che il problema sembrava impossibile da risolvere e che tanto valeva documentarlo e basta. Lui ha insistito. E il modello ha continuato a sfornare codice diagnostico finché le osservazioni accumulate non hanno fatto emergere l’errore.

La distinzione conta più di quanto sembri. Il valore non sta nel numero di righe generate, ma nella possibilità di accelerare un ciclo che si ripete uguale a se stesso: ipotesi, strumentazione, compilazione, boot, raccolta dati, nuova ipotesi. Un lavoro paziente, meccanico, che sfianca chiunque.

Perché il difetto è saltato fuori solo adesso

Torvalds ammette di non sapere con certezza perché un problema presente da tempo nel driver drm/xe abbia cominciato a manifestarsi quasi a ogni avvio. La sua ipotesi punta su un aggiornamento in userspace, magari Mesa, il compositor o il display manager, che avrebbe cambiato il modo in cui la memoria della GPU viene richiesta e organizzata. Risultato: durante il boot, una delle page table usate dalla GPU finiva sempre più spesso proprio nella pagina che il driver considerava libera, ma che l’hardware Intel usava per conservare le informazioni sulla compressione della memoria grafica.

Roba che capita. I bug di corruzione della memoria legati alla disposizione delle allocazioni possono restare silenziosi per mesi o anni, poi basta un componente aggiornato che sposta l’ordine delle allocazioni e il difetto diventa quotidiano. La causa resta nel kernel, anche se il fattore scatenante arriva da fuori.

Quello che l’AI non ha fatto

Ridurre la vicenda a un titolo tipo “Torvalds usa l’AI per correggere Linux” sarebbe una lettura sbrigativa. Il modello non ha riconosciuto subito l’errore, non ha mostrato particolare tenacia e più volte ha suggerito di lasciar perdere. Ha però dimostrato una qualità concreta: guidato da chi conosce a fondo il problema, produce in fretta strumentazione aggiuntiva e confronta grandi quantità di informazioni senza annoiarsi.

Il ruolo umano resta scoperto e ben visibile. Serve decidere cosa chiedere, capire se una conclusione ha senso, riconoscere un vicolo cieco, scegliere quali dati raccogliere e stabilire quando le prove bastano per toccare codice che parla direttamente con l’hardware. Persino il messaggio del commit finale, dice Torvalds, lo ha scritto l’AI. Ma la patch porta la sua firma e nasce da una verifica tecnica riproducibile.

Nel debugging hardware mancano quasi sempre informazioni essenziali: stato interno del dispositivo, timing, registri, comportamento durante l’esecuzione. Nessun modello può dedurre dati che non possiede, però può aiutare a costruire gli esperimenti che li fanno emergere. Dietro quella singola riga corretta ci sono una GPU Battlemage, memoria CCS sovrapposta alla VRAM allocabile, page table corrotte, un compositor che non partiva, 24 patch temporanee, 18 boot e un assistente che avrebbe mollato prima del suo utilizzatore.

Condividi:
155 Condivisioni