RX 9060 XT unter Linux: Hardlocks, Mesa 26.2.4 und meine Fehlersuche

Eine neue Radeon, die unter Linux zunächst großartig lief. Dann Spiele, bei denen plötzlich beide Monitore schwarz wurden und der GPU-Lüfter auf 100 Prozent schoss. Keine vernünftige letzte Fehlermeldung. Ich habe die Karte nicht zurückgegeben – ich wollte verstehen, warum das passiert.

Warum ich überhaupt AMD ausprobierte

Ich habe nichts Grundsätzliches gegen NVIDIA, AMD oder Intel. Die Grafikkarte soll meine Programme unterstützen, ordentlich Leistung bringen und – kleine ästhetische Bedingung – möglichst weiß sein. Unter meinen selbst konfigurierten Linux-Systemen gab es mit der RTX 3060 Ti aber immer wieder Reibereien: Ein Gentoo-Setup lief, dann kam ein Spiel, ein Treiberupdate oder ein OBS-Problem, und die Fehlersuche begann erneut.

Bei Kleinanzeigen entdeckte ich eine alte ASUS Strix Radeon R9 380 für 20 Euro. Also andere M.2-SSD rein, Karte eingebaut und Arch, Debian und Gentoo frisch getestet. OBS, Steam, Lutris und WoW Classic: alles 1A mit Sternchen. Debian war bei aktuellen Treiberversionen manchmal eher mein Sorgenkind, aber diese grundlegenden Kompatibilitätstests bestanden.

Dann startete ich Baldur's Gate 3. Die betagte R9 380 war schlicht zu langsam. Da ich die weiße PowerColor RX 9060 XT Hellhound Spectral White 16 GB ohnehin schon länger im Auge hatte, wurde aus einem billigen Experiment beim nächsten Gehalt eine richtige Grafikkarte.

Erst einmal lief alles wunderbar

Mit der Hellhound spielte ich zunächst vor allem Baldur's Gate 3 und WoW Classic. Beide liefen hervorragend. Das ist wichtig: Die RX 9060 XT war nicht vom ersten Start an ein unbrauchbares Problemgerät. Die Schwierigkeiten entdeckte ich später, als ich einmal Lust auf „richtige Grafik“ hatte und S.T.A.L.K.E.R. 2 sowie andere vorher wenig getestete Spiele ausprobierte.

Dazwischen lagen System- und Grafikupdates. Ob sie die Fehler verursacht hatten, kann ich rückblickend nicht beweisen: Für diese Spiele fehlen direkte Vergleichstests vor dem Update. Die zeitliche Nähe ist kein Root-Cause-Nachweis.

Vier Spiele, mehrere unterschiedliche Fehlerbilder

Gerade Quake RTX darf man nicht als identischen Totalausfall bezeichnen. Wenn die Anwendung noch auf Eingaben reagiert und Netzwerkempfang funktioniert, ist zumindest ein Teil des Betriebssystems lebendig. Ein schwarzer Monitor allein sagt nicht, ob Display-Pipeline, Renderer, Treiber, PCIe-Verbindung oder das gesamte System versagt hat.

„Cthulhu, sag wenigstens AUA, bevor du stirbst!“

Das Frustrierendste war, dass beim schwersten Crash häufig keine brauchbare AMDGPU-Meldung unmittelbar davor im Journal stand. Einmal sah ich unter Arch Hinweise in Richtung amdgpu: device lost from bus, aber meist blieb nur: Monitore schwarz, GPU-Lüfter hoch, Neustart. Ich wollte, dass Cthulhu vor dem Blackout wenigstens kurz „Oh, mein Bein!“ ruft, damit ich weiß, wo ich suchen muss.

Bei einem plötzlichen GPU- oder PCIe-Ausfall kann der Kernel gar nicht mehr dazu kommen, eine vollständige Diagnose zu schreiben oder sie dauerhaft zu speichern. Kein Logeintrag ist deshalb kein Beleg für einen fehlerfreien Grafikstack. Ich beobachtete Logs live, testete aber auch hardwareseitig.

journalctl -kf -o short-monotonic

Riser raus, Netzwerkkarte raus, Spiele auf andere Laufwerke

Um mögliche Einflüsse zu isolieren, testete ich die Grafikkarte sowohl mit PCIe-Riser als auch direkt im Mainboard. Ich probierte die BIOS-/PCIe-Konfiguration, entfernte sogar die 10-Gbit-Netzwerkkarte zum NAS und testete die originalen PCIe-Stromkabel ohne die weißen Sleeve-Verlängerungen. Keine dieser Maßnahmen beseitigte die Blackouts.

Die tatsächliche PCIe-Kette war zeitweise: 00:03.1 Root Port → 53:00.0 Switch Upstream → 54:00.0 Switch Downstream → 55:00.0 GPU, mit einem beobachteten Link von 8 GT/s ×8. Das ist ein untersuchenswerter Befund, aber nicht automatisch die Crash-Ursache – zumal direkte Slot-Tests ebenfalls scheiterten.

Das Netzteil ist von Corsair; Modell und Wattzahl kenne ich derzeit nicht sicher. Es hat nach meiner Erinnerung einen 6+2-Pin- und einen 6-Pin-PCIe-Stromanschluss. Modelle mit zwei benötigten 8-Pin-Steckern kamen deshalb schon beim Kauf nicht infrage. Der OC-/Silent-Dual-BIOS-Schalter der Hellhound brachte beim Test keinen erkennbaren Unterschied. An ein Firmware-Flash dachte ich nur als allerletzte Option; durchgeführt habe ich es nicht.

Der zweite Verdächtige: SATA-CRC-Fehler

Zwischen den Gaming-Hängern tauchten zusätzlich Meldungen zur Samsung 860 EVO an ata2 auf: BadCRC, READ FPDMA QUEUED und harte SATA-Link-Resets. Das ist ein echter technischer Befund und verdient eine separate Untersuchung von Kabeln, Ports und gegebenenfalls Testlaufwerken.

Um ihn von der GPU-Hypothese abzugrenzen, kopierte ich problematische Spiele von der SATA-SSD erst auf die System-NVMe und später auf die andere NVMe. Die Grafikabstürze blieben zunächst bestehen. Daher ist die ursprüngliche SATA-SSD als alleinige Erklärung wenig überzeugend. Die SATA-Verbindung selbst ist noch nicht repariert oder abschließend diagnostiziert; die geplanten Kabel- und Porttests folgen separat.

Gleiche S.T.A.L.K.E.R.-Runde, anderes Betriebssystem

Ich hatte noch eine separate Windows-11-NVMe, eigentlich für Battlefield. Damit konnte ich einen guten Kontrollversuch durchführen: S.T.A.L.K.E.R. 2, derselbe Spielstand, „Weiterspielen“, vom Spawnpunkt einmal um die Basis laufen. Grafik weitgehend auf Maximum, dieselbe RX 9060 XT. Unter Windows lief diese Runde ohne Probleme. Battlefield lief ebenfalls wie gewohnt.

Das ist deutlich aussagekräftiger als ein anderer Benchmark, aber noch kein gerichtsfester Beweis gegen die Hardware. Linux und Windows verwenden verschiedene Grafik- und Treiberpfade, und die Settings müssen nicht in jedem Detail identisch sein. Der Vergleich zeigt, dass die Linux-spezifische Ausführung als Ursache wesentlich interessanter wurde.

112 Watt: eine Hypothese, kein Wunder-Fix

WoW Classic begrenze ich schon lange auf 60 FPS, selbst am 144-Hz-Monitor. Warum unnötig Leistung verbraten, wenn das Spiel wunderbar läuft? Frühere Undervolting-Versuche unter Windows hatten gezeigt, wie viel Strom man sparen kann. Also kam mir die Frage: Ist vielleicht das Netzteil, ein Kabel oder ein Lastwechsel der Auslöser?

Ich setzte das GPU-Power-Limit testweise von 160 auf 112 Watt. Das reduzierte zunächst manche Hardlocks, aber nicht zuverlässig: Die kurzen Stalls blieben bestehen, und nicht alle vollständigen Abstürze verschwanden. Außerdem verändern Power-Limits Takte und andere Betriebszustände. Eine Verbesserung beweist daher keinen Netzteildefekt. Bei 112 W stürzte Arma 3 weiterhin hart ab; Quake RTX verlor die Bildausgabe, während Spiel und LocalSend weiterliefen. Bei Black Flag Resynced kam es weiterhin teilweise nach etwa 3–10 Minuten Gameplay zu Blackouts.

Beta-Kernel, Mesa-Versionen – und endlich 26.2.4

Ich fand in tiefen Forendiskussionen weitere Nutzer mit teils ähnlichen RDNA4-/Linux-Problemen. Das machte einen bekannten oder gerade bearbeiteten Softwarefehler für mich plausibler. Also probierte ich zunächst auch einen neueren Beta-Kernel. Der half nicht, teilweise wurde es schlimmer. Andere Mesa-Stände führten zu ebenso wenig Erfolg; zwei heiß diskutierte Ansätze verursachten bei mir sogar schnellere Blackouts. Die genauen Versionsnummern sind nicht mehr sicher, deshalb erfinde ich sie nicht.

Ich änderte immer genau eine Sache, testete und zog dann erst die nächste Änderung in Betracht. Schließlich kam Mesa 26.2.4. Das war die erste von mir getestete Version, mit der Arma 3 nicht schon beim Weltbeitritt hart abstürzte und S.T.A.L.K.E.R. 2 mit normalem Power-Limit wieder längere Zeit spielbar war. Kernel und Firmware blieben dabei reguläre NixOS-Pakete; die angepasste Mesa-Version wird explizit in meiner configuration.nix eingebunden, auch für 32-Bit-Anwendungen.

boot.kernelPackages = pkgs.linuxPackages_latest;
# In hardware.graphics:
mesaVersion = "26.2.4";
# 64-bit and 32-bit Mesa packages are overridden

Mit dieser Mesa-Version hob ich das Power-Limit kontrolliert an: 112 → 120 → 130 → 140 → 150 → 160 W, jeweils mit S.T.A.L.K.E.R. als Test. Der frühere sofortige Absturz blieb dabei aus. Das deutet auf eine Veränderung im Grafik-Softwarestack hin. Welcher Patch oder welcher Codepfad dafür verantwortlich ist, ist damit nicht bewiesen.

CTHULHU CRASH LAB: Die Tests interaktiv vergleichen

Das kleine Lab ist eine lokale, statische Aufbereitung meiner Notizen. Es misst keine Hardware, verändert keine Einstellungen und stellt keine Live-Diagnose. Wähle ein Spiel und vergleiche die früheren Symptome, den 112-Watt-Versuch und den heutigen Softwarestand.

Der Stand nach rund zehn Stunden Spielen

Die genannten Einzelzeiten sind Teil der grob geschätzten Gesamtspielzeit und dürfen nicht einfach als unabhängige Stunden zusätzlich addiert werden. Mesa 26.2.4 ist die erste von mir getestete Version mit dieser deutlichen Verbesserung. Das heißt nicht, dass der zugrundeliegende Bug eindeutig identifiziert oder vollständig behoben ist.

Wie an der TS 250 X: Hauptdüse wechseln, dann testen

Bei der Fehlersuche halte ich mich an dieselbe Regel wie beim Schrauben an meinem Motorrad. Noch letzte Woche habe ich an meiner TS 250 X gearbeitet: Wenn ich Hauptdüse, Luftfilter und Nadel gleichzeitig ändere, weiß ich hinterher nicht, welche Maßnahme welche Wirkung hatte. Also ändere ich immer nur einen Faktor und teste erneut.

Genauso habe ich mich durch Riser, PCIe, Datenträger, Stromkabel, Kernel und Mesa gearbeitet. Nein, ich wollte die Hellhound nicht einfach zurückgeben. Ich hatte mit NVIDIA eigene Probleme, und ein Markentausch beantwortet keine technische Frage.

Mein Fazit lautet deshalb nicht „AMD kaputt“ und auch nicht „Mesa 26.2.4 hat garantiert alles repariert“. Sondern: **Nicht aufgeben. Wenn man herausfindet, warum etwas passiert, hat man wieder etwas gelernt.** Cthulhu ist jetzt weitgehend spielbar. Die allerletzte Ursache haben wir noch nicht erwischt.

Quellen, Reproduzierbarkeit und Grenzen

Hardwarekonfiguration, Fotos und erhaltene Systemaufnahmen stammen aus dem Cthulhu-Eintrag im Computer Museum; das öffentliche Cthulhu-Konfigurationsarchiv dokumentiert Linux-Setups, aber nicht sämtliche früheren Tests. Technischer Hintergrund: Linux-Kernel-Dokumentation zu AMDGPU, Mesa-Dokumentation, ArchWiki: AMDGPU. Meine Spielzeiten, Fehlerbilder und Entscheidungen sind eigene Beobachtungen.

Offen: exaktes Netzteilmodell, die bestimmten erfolglosen Mesa-Versionsnummern, der konkrete Upstream-Fix und die noch separat zu testenden SATA-Kabel/Ports. Bitte meine Beispielwerte nicht als Garantie für andere Navi44-GPUs oder als Rezept für Firmware-Flashing verstehen.