Eine Zeile gegen den GPU-Fehler: Wie Linus Torvalds und KI Intels Xe-Treiber reparierten

Der Einzeiler, der den Fehler behob

Ein einziger Wechsel im Intel-Xe-Grafiktreiber beseitigte einen schweren Speicherfehler auf Battlemage-G21-Hardware. Aus

round_up(value, SZ_128K)

wurde konzeptionell:

round_down(value, SZ_128K)

Der Unterschied ist entscheidend: Der berechnete Wert markierte die Grenze des Speichers, den der VRAM-Allocator verwenden durfte. Durch das Aufrunden konnte ein kleiner Bereich zwischen der tatsächlichen Grenze und der aufgerundeten Adresse fälschlich als freier VRAM erscheinen. Tatsächlich lag dort reservierter Speicher für die flache CCS-Kompression – Metadaten, die die GPU selbst benötigt. Das Abrunden hält den Allocator auf der sicheren Seite dieser Grenze.

Wie aus einer Rundung GPU-Korruption wurde

Sobald der Allocator den reservierten CCS-Bereich als normalen VRAM behandelte, konnten reguläre Speicherbelegungen dessen Metadaten überschreiben. Betroffen waren unter anderem Daten im Umfeld der GPU-Seitentabellen. Die Folgen reichten von Bildfehlern und beschädigten Bildschirminhalten bis zu einem Display-Manager, der sich auf Battlemage-G21-Karten ständig neu startete.

Das Problem war damit mehr als ein simpler Rechenfehler. Der Code behandelte einen Wert so, als wäre er eine Startadresse, obwohl er semantisch eine Grenze darstellte: Er beschrieb, wo der nutzbare Speicher endet. Genau diese Verwechslung machte den Fehler so schwer zu finden – und die endgültige Korrektur so klein.

24 Patches und 18 Kernel-Starts

Torvalds beschrieb die Untersuchung als „Debug-Session aus der Hölle“. Gemeinsam mit einem KI-Assistenten ergänzte und überarbeitete er gezielte Diagnoseausgaben, verfolgte die Speicherberechnungen im Treiber und verglich die von der Hardware gemeldete CCS-Position mit der Grenze, die an den VRAM-Allocator weitergegeben wurde.

Bis die falsche Ausrichtung erkennbar wurde, entstanden 24 Versionen von Debug-Patches und es waren 18 Neustarts mit anschließenden Tests nötig. Die wiederholten Kernel-Starts waren wichtig, weil sich der Fehler nicht nur in einer verdächtigen Quellcodezeile zeigte, sondern auf Hardware- und Display-System-Ebene. Jedes Experiment half dabei, das Verhalten der Speicherverwaltung von anderen möglichen Ursachen der Grafikfehler abzugrenzen.

Die KI beschleunigte die Suche – sie leitete sie nicht

Torvalds nutzte die KI als interaktiven Debugging-Partner. Sie half dabei, Instrumentierung vorzuschlagen, Codepfade nachzuverfolgen und die Ergebnisse der einzelnen Versuche auszuwerten. Dadurch wurde ein großer Teil der wiederholten Handarbeit schneller erledigt.

Als verlässliche Autorität erwies sich der Assistent allerdings nicht. Torvalds zufolge erklärte die KI das Problem mehrfach kurzerhand für unmöglich oder unlösbar und schlug vor, stattdessen einfach einen Bericht zu schreiben. Er selbst hielt die Untersuchung am Laufen, entschied über das nächste Experiment, verwarf falsche Interpretationen und erkannte schließlich die Bedeutung des Offsets im Speichermodell des Allocators.

Darin liegt die wichtigste Lehre dieses Falls: Die KI lieferte Hypothesen und übernahm mechanische Arbeit. Der Experte brachte das nötige Kontextwissen, formulierte überprüfbare Tests, blieb hartnäckig und traf das abschließende Urteil.

In den Kernel aufgenommen – konkrete Backports noch offen

Torvalds verfasste und commitete die Korrektur selbst für den Upstream-Linux-Kernel. Nach den vorliegenden Berichten sollten betroffene, noch gepflegte Stable-Kernel-Reihen die Änderung über den üblichen Backport-Prozess erhalten. Welche stabilen Versionen den Fix tatsächlich enthalten und wann sie erscheinen, lässt sich aus den verfügbaren Quellen jedoch nicht zuverlässig ableiten.

Konkrete Versionsnummern wären daher zum jetzigen Zeitpunkt spekulativ. Nutzer mit betroffener Hardware sollten auf Ankündigungen ihrer Distribution oder der Kernel-Maintainer achten.

Was der Fall über KI im Kernel-Entwicklungsprozess zeigt

Die Episode ist kein Freibrief für automatisch erzeugten Kernel-Code. Sie zeigt vielmehr eine engere, belastbare Anwendung: Ein erfahrener Entwickler kann KI einsetzen, um eine schwierige Debugging-Schleife zu beschleunigen – solange er die Hypothesen, Tests, Änderungen und das Ergebnis selbst verantwortet.

Das ist etwas völlig anderes, als ungeprüfte KI-Patches oder automatisch formulierte Sicherheitsberichte ungefragt an Maintainer zu schicken. Kernel-Entwickler berichteten von einer regelrechten „Flut“ maschinell erzeugter Einsendungen. Aus dem Staging- und Netzwerkbereich kamen zudem Berichte über wachsenden Frust angesichts minderwertiger oder schlecht verstandener Patches.

Auch die häufig genannte Steigerung der Einsendungen um 2.700 Prozent sollte mit Vorsicht betrachtet werden. Die vorliegenden Berichte klären weder Messmethode noch Zeitraum oder die genaue Kategorie hinter dieser Zahl. Besser belegt ist die allgemeinere Entwicklung: KI senkt die Kosten für das Erzeugen von Code und Berichten, während die Prüfung und Sortierung weiterhin Zeit der menschlichen Maintainer bindet.

Torvalds hat außerdem betont, dass Linux nicht grundsätzlich gegen KI-Werkzeuge eingestellt sei – insbesondere dann nicht, wenn sie etwa bei Code-Reviews eingesetzt werden. Der Intel-Xe-Fall markiert die praktische Grenze: KI kann in einem disziplinierten Entwicklungsprozess nützlich sein, ersetzt aber weder Subsystem-Wissen noch reproduzierbare Tests oder die menschliche Verantwortung für den fertigen Patch.

Der finale Patch bestand aus einer Zeile. Die eigentliche Leistung bestand darin, zu erkennen, welche Zeile geändert werden musste – und weiterzusuchen, als die KI bereits behauptete, die Antwort sei nicht zu finden.