RX 6700 XT verursacht Session-Abstürze unter Linux – meist im Desktopbetrieb, selten in Spielen

[Astryn02]

Ich kämpfe seit einiger Zeit mit unerklärlichen Abstürzen unter Linux. Hauptsächlich im normalen Desktopbetrieb (Surfen, Leerlauf, Dateimanager etc.) friert das System ein – der Mauszeiger ist noch für einige Sekunden beweglich, dann werde ich zurück zum Login-Screen geworfen, alle Programme sind geschlossen. Es handelt sich nicht um einen Reboot, sondern um einen Session-Absturz.
Gelegentlich sind grüne oder schwarze Artefakte (Kacheln, Flackern) auf einem oder beiden Monitoren zu sehen – meist kurz vor dem Absturz.

💡 Besonderheit:
Unter GPU-Last (z. B. Unigine Heaven oder glmark2) läuft alles stabil – auch bei längeren Tests. In Spielen tritt das Problem selten auf, am ehesten noch in Minecraft, das im Fenstermodus läuft.


---

💻 System

CPU: Ryzen 5 7500F

GPU: AMD RX 6700 XT (ASUS TUF)

Mainboard: MSI B650 Gaming Plus

RAM: 32 GB DDR5-6000 G.Skill Ripjaws

Netzteil: 750W be quiet! Pure Power 12 M (80+ Gold)

Monitore: LG UltraGear (144Hz) + Samsung (72Hz)
→ Fehler auch mit nur einem Monitor reproduzierbar



---

🧪 Getestet

Distributionen: Nobara, Bazzite, Linux Mint

Desktops: GNOME (X11 & Wayland), KDE Plasma (Wayland), Cinnamon (X11)

VRR: Deaktiviert

XMP/EXPO: Deaktiviert

BIOS: Mehrfach zurückgesetzt

MemTest86+: → Keine Fehler

CPU-Stress: stress-ng → stabil

GPU-Stress: Unigine Heaven, glmark2 → stabil

PCIe-Link: korrekt (16GT/s bei x16)

Treiber: amdgpu (DRM 3.57, KMS aktiv)

Mesa: 24.2.8

Kernel: 6.8.x

Abstürze auch bei 60Hz und nur einem Monitor



---

🧩 Fazit

Das Problem tritt distro- und DE-unabhängig auf, ist am häufigsten bei Desktop- oder Idle-Nutzung zu beobachten. Hohe GPU-Last ist kein zuverlässiger Auslöser.
Daher im Verdacht: defekte GPU, USB-/Chipsatz-Probleme, Kernel/BIOS-Inkompatibilitäten – aber bislang ohne Klarheit.

Frage:
Kennt jemand das Verhalten? Gibt es Tipps zur weiteren Eingrenzung – z. B. AMDGPU-Flags, Firmware, ACPI-Tweaks oder bekannte Bugs mit Navi 22?

 

[PCFreak69]

...ist am häufigsten bei Desktop- oder Idle-Nutzung zu beobachten...

Das ist wahrscheinlich ein Problem mit dem ULPS (Ultra Low Power State) Energiesparmodus der Grafikkarte, so nennt sich das unter Windows, lässt sich mit z.B MSI Afterburner oder in der Windows Registry deaktivieren.

Keine Ahnung ob es den ULPS Energiesparmodus auch unter Linux gibt und wie man es unter Linux abschaltet.

Edit:
Funktioniert auch unter Linux, Kernel-Boot-Parameter amdgpu.ignore_min_pcap=1
Ich habe von Linux aber absolut keine Ahnung und weiß nicht wo man das eintragen muss.

Anfängerfragen - Linux Neuling? Hier ist der richtige Platz für deine Fragen (2)

Editiert. Knoddle hat x11 auf nobara daher passt es mit x11 Paketen. Nun eher die Frage: warum hat Nobara noch x11 obwohl KDE6 doch offiziell für wayland gedacht ist?

www.hardwareluxx.de

https://www.reddit.com/r/linux_gaming/comments/1bgtftb/you_can_now_disable_amd_gpu_lower_power_limit/

 

[Zyxx]

@Astryn02 was gibt denn journalctl für diesen Zeitraum aus? In der Konsole "jourunalctl -r" und dann etwas scrollen bis du zu der Zeit kommst wo es Probleme gab.
Generell laufen RDNA2 Karten wie ein Uhrwerk unter Linux.

Und auch wenn dein Mesa und dein Kernel nicht mehr aktuell sind: Das sollte locker reichen.

Nutzt du den Curve Optimizer im BIOS? Hast du generell dort etwas von Hand eingestellt?
Läuft die Karte auf Stockwerten, oder hast du (bspw. in LACT) an Takt und Powerlimit Änderungen vorgenommen?.

Wenn du willst hier zwei sehr gute Hilfsmittel um die Hardware auf Stabilität abzuklopfen:

Lass den Vulkan Memtest einmal auf deinen PC los:

GitHub - GpuZelenograd/memtest_vulkan: Vulkan compute tool for testing video memory stability

Vulkan compute tool for testing video memory stability - GpuZelenograd/memtest_vulkan

github.com

Nach einigen Minuten gibt die Konsole aus das es reichen würde es so lange laufen zu lassen, gönn dem Ganzen dann aber nochmal 20 Minuten mehr.
Treten Fehler auf? So stimmt etwas mit der Karte nicht.

Anschließend schau einmal das du "stressapptest" installierst, das ist bei allen gängigen Distributionen griffbereit.
"stressapptest -W -s 3600 -v 10 --pause_delay 15000" sollte maximalen Druck auf CPU/RAM legen und eine Stunde lang werkeln.
Wenn hier Fehler auftreten so muss genauer auf Speicher und CPU geschaut werden.

Geht während eines dieser Tests der PC ganz aus, dann eventuell mal das Netzteil checken

 

[Astryn02]

Kurz vor dem Absturz meldete der AMD-Grafiktreiber (amdgpu) wiederholt folgende Fehler:

Fence fallback timer expired on ring sdma0

flip_done timed out

commit wait timed out

hw_done or flip_done timed out

Lestenreiche stresstests habe ich schon durchgeführt ich werde trotzdem mal deine versuchen. ram lief die ganze nacht mit memtest ohne probleme und auch cpu stresstest liefen durch ohne mucken.

einige optimizer hatte ich tatsächlich an aber nachdem ich das bios zurückgesetzt hatte blieben die probleme unverändert

 

[PCFreak69]

Kurz vor dem Absturz meldete der AMD-Grafiktreiber (amdgpu) wiederholt folgende Fehler:
Fence fallback timer expired on ring sdma0

flip_done timed out

commit wait timed out

Das scheint tatsächlich ein Low Power Limit Problem zu sein.

Hast du mal im Kernel-Boot-Parameter amdgpu.ignore_min_pcap=1 getestet?
In meinem Post 2 im Edit beschrieben.

Das GPU Low Power Limit Problem tritt bei AMD Grafikkarten relativ oft auf.

 

[Astryn02]

Das scheint tatsächlich ein Low Power Limit Problem zu sein.

Hast du mal im Kernel-Boot-Parameter amdgpu.ignore_min_pcap=1 getestet?
In meinem Post 2 im Edit beschrieben.

Das GPU Low Power Limit Problem tritt bei AMD Grafikkarten relativ oft auf.

werde ich später sofort austesten

 

[Zyxx]

Der Bootparameter bewirkt allerdings das die Karte nicht mehr konform nach ihrem GPU BIOS läuft, sondern die Grenzwerte nach unten hin ignoriert und niedrigere Spannungen erlaubt als vorgesehen.

Ob das die Lösung wäre?

 

[PCFreak69]

Der Bootparameter bewirkt allerdings das die Karte nicht mehr konform nach ihrem GPU BIOS läuft, sondern die Grenzwerte nach unten hin ignoriert und niedrigere Spannungen erlaubt als vorgesehen.

Nicht nur niedriger auch höhere Spannungen, vor allen dingen lässt sich die AMD GPU mit CoreCtrl Einstellen, mit amdgpu.ignore_min_pcap=1

Allerdings würde ich vorher testen ob man die GPU Spannung auch ohne diese Einstellung mit CoreCtrl verändern kann.
Die AMD GPU sollte die Spannung nicht zu weit senken und nicht zu weit runter Takten, denn genau hier stürzt die AMD GPU ab.

 

[Zyxx]

Eigentlich reicht es amdgpu.ppfeaturemask=0xffffffff in den Startparameter zu packen um die Spannungen und Takte einer RDNA regeln zu können.
Beachte auch das CoreCtrl ungefragt den CPU Governour auf Performance stellt und energy_performance_preference verstellt.

Hier würde ich eher zu LACT raten, das überlebt auch Standby und Ruhezustand verlässlich und funktioniert.

Aber bevor man an der GPU den Takt und die Spannung verstellt, welche Stock eigentlich rund laufen müsste, sollte immer noch geklärt werden was die Ursache der Blackscreens ist.

 

[PCFreak69]

...sollte immer noch geklärt werden was die Ursache der Blackscreens ist.

Das lässt sich ganz einfach klären, indem man etwas im Hintergrund laufen lässt das die GPU immer leicht auslastet, sodass der Energiesparmodus nie verwendet wird.
Wenn die GPU mit dem Energiesparmodus nicht zurecht kommt, ist die GPU normalerweise defekt.

Das Problem lässt sich in Windows relativ leicht umgehen indem man den Ultra Low Power State deaktiviert, die GPU ist dann meistens noch viele Jahre ohne ständige abstürze nutzbar.

 

[Zyxx]

Du gehst dabei aber davon aus das ULPS hier das Problem ist und die GPU der Verursacher.

 

[PCFreak69]

Was soll es sonst sein, wenn unter geringer GPU Last oder hoher GPU Auslastung keine abstürze auftreten?
Und die GPU nur beim Ladebildschirm in Games oder im Windows idle abstürzt, wenn die GPU weit runter Taktet.

 

[Zyxx]

Warten wir ab was die Tests zeigen, ich bin just skeptisch, mehr wollte ich nicht zum Ausdruck bringen.