Dennis HilkLinux-DiagnoseEN

Linux Gaming Repair Center

Ein Spiel friert bei Bewegung durch die Welt ein

Streaming-Pausen, GPU-Fehler und vollständige Hard-Locks trennen; die dokumentierten Cthulhu-Beobachtungen bleiben ein ungelöstes Beispiel.

Redaktionelle Quellenprüfung: Diagnosehilfen öffnen
Auf dieser Seite
  1. Der Cthulhu-Fall liefert Hinweise, keine gelöste Diagnose
  2. Bewegung kann mehrere unabhängige Pfade belasten
  3. Ein niedrigeres Power-Limit verändert den Versuch
  4. Hinweise sammeln
  5. Ein kontrollierter Test
  6. Passende Diagnosehilfen
  7. Quellen und Grenzen

Der Cthulhu-Fall liefert Hinweise, keine gelöste Diagnose

Die vom Nutzer berichtete Untersuchung betraf einen Ryzen 7 5800X3D und eine RX 9060 XT / Navi 44 unter NixOS; dabei wurden Kernel 7.2.8, Mesa/RADV 26.1.8 und Vulkan 1.4.x genannt. Dies sind übermittelte Falldetails und keine verifizierte Empfehlung für aktuelle Versionen. Leichte Spiele blieben stabil; Bewegung in einem anspruchsvollen Spiel verursachte Pausen von 1–2 Sekunden oder Hard-Locks mit schwarzen Displays und maximaler Lüfterdrehzahl. Teilweise fehlte eine letzte hilfreiche GPU-Meldung; ein früherer Arch-Test meldete das Verschwinden der GPU vom Bus. Weder Log-Stille noch der Bewegungsauslöser bestimmen eine einzelne Ursache.

Bewegung kann mehrere unabhängige Pfade belasten

Bewegung kann neue Assets, Shader- oder Pipelinearbeit, Allokationen, CPU-Simulation und andere GPU-Einreichungen verlangen. GPU-Ausführung, PCIe-Transport, Kernel/Firmware und Grafik-Userspace parallel zum Speicherpfad untersuchen. Im Fall gab es zusätzlich ata2-Schnittstellenfehler, BadCRC, READ FPDMA QUEUED und Link-Resets: Das sind reale Speicherbefunde, möglicherweise unabhängig vom GPU-Fehler. READ FPDMA QUEUED benennt einen Warteschlangen-Lesebefehl und ist allein kein Fehler. Der Umzug auf NVMe beseitigte das berichtete Problem nicht; das schwächt eine reine SATA-Erklärung, repariert aber weder den separat scheiternden SATA-Pfad noch schließt es alle übrigen I/O-Zugriffe aus.

Ein niedrigeres Power-Limit verändert den Versuch

Das berichtete GPU-Limit von 112 W verhinderte einige harte Abstürze, während Pausen blieben. Dies ist eine Korrelation, kein Beweis für ein defektes Netzteil oder einen gelösten Treiberfehler. Ein Limit verändert Takt, Leistung und Timing und kann dadurch mehrere Mechanismen beeinflussen. Kurze Pausen, GPU-Resets und vollständige Hard-Locks als unterschiedliche Ergebnisse erfassen. Originaleinstellungen behalten und Versuche beenden, die wiederholt hartes Ausschalten erfordern. Tatsächlichen Spiel-Mount, Shadercache-Ort und Swap prüfen, bevor sämtliche relevanten Zugriffe der NVMe zugerechnet werden. Einen belegten Speicher-Linkfehler anhand eigener Hinweise reparieren und die separate GPU-Untersuchung fortsetzen.

Vor Änderungen Hinweise sammeln

Führe jeden Befehl einzeln in der passenden Host- oder Spielumgebung aus. Lies zuerst Voraussetzungen und Einordnung. Die Website zeigt Befehle an und führt sie niemals aus.

Lesende Beobachtung

journalctl -k -b -1 -o short-monotonic --no-pager

Voraussetzungen: Persistentes Kerneljournal des vorherigen Boots und Leserecht.

Nach Neustart GPU-, PCIe- und ATA-Meldungen mit beobachtetem Pausenzeitpunkt vergleichen. Alle drei Klassen behalten; fehlende gespeicherte Logs belegen kein fehlerfreies Intervall.

Lesende Beobachtung

findmnt -T "/path/to/game"

Voraussetzungen: util-linux findmnt und echtes Spielverzeichnis; normalerweise keine erhöhten Rechte nötig.

Pfad durch installiertes Spielverzeichnis ersetzen. Zugehörigen Mount erfassen; dies identifiziert nicht separat Prefix, Shadercache oder Swapgerät.

Lesende Beobachtung

iostat -xz 1

Voraussetzungen: sysstat installiert; Gerätenamen müssen den relevanten Mounts zugeordnet werden.

Aufeinanderfolgende Geräteintervalle während einer sicheren kurzen Route beobachten. Erhöhte Wartezeiten nahe einer Pause stützen eine I/O-Prüfung und keine bestätigte GPU-Erklärung. Der erste Bericht kann den Zeitraum seit Boot abdecken. Mit Strg+C beenden.

Lesende Beobachtung

lspci -t

Voraussetzungen: pciutils auf dem Host; dies ist eine lesende Topologieansicht.

PCI-Topologie lesen und Bridges im GPU-Pfad bestimmen. Eine vorhandene Bridge belegt keinen Defekt; Topologie mit AER- und Linkbeobachtungen verbinden.

Ein kontrollierter Test mit Rückweg

Eine bereits sichere kurze Reproduktion verwenden und nur spielinternes FPS-Limit oder eine Streaming-Einstellung ändern. Jede Pause, jeden Reset und Hard-Lock getrennt mit Zeitpunkten notieren. Den Fallwert von 112 W nicht auf beliebige Hardware übertragen.

Rücknahme: Erfasste Spieleinstellung wiederherstellen und Monitoring beenden. Wurde separat ein Power-Limit-Versuch gewählt, den dokumentierten Originalwert dieses Systems über seine unterstützte Steuerung wiederherstellen; es gibt hier keinen universellen sysfs-Pfad.

Was der Test nicht belegen kann: Der Fall bleibt ungelöst. Seine veröffentlichten Akzeptanzlogs sind als synthetisch und anonymisiert gekennzeichnet; sie ergänzen keinen GPU-Timeout zur ursprünglichen Beobachtung ohne letzte Fehlermeldung. Power-Limit-Reaktion, VRAM-Änderungen und SATA-Resets belegen keine gemeinsame Einzelursache.

Quellen und Geltungsbereich

Diese redaktionelle Prüfung verwendet Originalquellen von Projekten und Distributionen. Sie belegt keine auf deiner Hardware reproduzierte Lösung. Installierte Versionen, Spielumgebung und gewählte Grafik-API können das Ergebnis verändern.