Linux AMDGPU Nutzer: Vorsicht bei 6.12+ Kernelversionen -> mögliche Crash/Freeze Probleme

Linux Betriebssystem

bemymonkey

Well-known member
Themenstarter
Registriert
21 Juni 2009
Beiträge
10.346
Moin zusammen,

nachdem mein P14sG3 mit 6850U in der letzten Woche ein paar mal einfach so eingefroren ist habe ich mich auf Fehlersuche begeben und etwas gegraben. Jetzt wollte ich hier im Forum nur mal eben einen Hinweis loswerden, nämlich: Es scheint seit ca. Kernelversion 6.12 ein Problem mit Instabilität im Bereich amdgpu zu geben.

Das äußert sich in der Regel mit Kernel-Fehlermeldungen die Folgendes beinhalten oder so ähnlich:

May 09 21:11:55 simon-deb-p14s kernel: amdgpu 0000:04:00.0: [drm] *ERROR* [CRTC:79:crtc-0] flip_done timed out

oder

May 09 21:11:44 simon-deb-p14s kernel: amdgpu 0000:04:00.0: [drm] *ERROR* dc_dmub_srv_log_diagnostic_data: DMCUB error - collecting diagnostic data


Mit den Keywords habe ich auf gitlab.freedesktop.org jede Menge offene Issues gefunden, die seit ein paar Wochen scheinbar mit vielen unterschiedlichen AMD GPUs auftreten, unter Anderem 780M, 680M, 7xxxXT (Desktop) und auch ältere Karten.

Die Meisten berichten, dass es unter Kernelversionen 6.12.x bis 6.14.x auftritt - aus meiner Sicht besteht also die Chance, dass es eine Regression ist. Daher, falls Ihr z.B. auf Eurem AMD System ein Debian 12 mit 6.1er Kernel laufen habt und grundsätzlich mit Performance/Stromverbrauch zufrieden seid, wäre es momentan vermutlich sinnvoll *nicht* so wie ich in Hoffnung auf bessere Akkulaufzeit auf einen neueren Kernel zu wechseln. Selbiges könnte z.B. für Ubuntu 24.10 oder Mint 22 Nutzer gelten.


Links zu ein paar der Issues, die mir zusammenhängend erscheinen:



Teilweise wird gemunkelt, dass es sich wieder um ein Problem mit PSR (Panel Self Refresh) handelt - das war wohl bei Release von Rembrandt (Ryzen 6000 mit 660M oder 680M, glaub ich) bereits ein Thema. Einige haben berichtet, dass das Ausschalten von PSR per Bootparameter (mal wieder) geholfen hat, und Einige von Euch haben sicherlich noch die alten Bootparameter von damals gesetzt, womit das Problem ja vielleicht einfach umgangen wird.


Vielleicht hat sich ja hier auch schon jemand mit dem Thema beschäftigt und hat mehr Ahnung.
 
Ah, daher kommt also der Fehler. Ich hatte das in den den letzten Wochen hin und wieder bei meinem GPD Win Max 2 mit einer 780M und hatte schon einen Hardwarefehler in Betracht gezogen. Allerdings tritt es so selten auf, dass es noch nicht ultra störend geworden ist.

Dann hoffe ich mal, dass bald ein Fix erscheint.
 
Moin,
interessant, danke. Ich hatte bis dato keine Probleme mit dieser Konstellation:
Ryzen 5 PRO 7540U w/ Radeon 740M Graphics

Habe einmal geschaut und dieses gefunden:
Code:
~# dmesg |grep -i error
[    1.244987] RAS: Correctable Errors collector initialized.
[    3.459885] amdgpu 0000:64:00.0: Direct firmware load for amdgpu/gc_11_0_1_mes_2.bin failed with error -2

Allerdings nutze ich ausschließlich den X-Server.

Zur Vollständigkeit:
Code:
~# uname -a
Linux T16 6.12.12+bpo-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.12-1~bpo12+1 (2025-02-23) x86_64 GNU/Linux
Beitrag automatisch zusammengeführt:

Ich habe gerade einmal auf Kernel 6.12.22+bpo-amd64 aktualisiert. Den beschriebenen Fehler habe ich aber weiterhin nicht.
 
Zuletzt bearbeitet:
Achso, ja, ganz vergessen: Bei mir ist das seit dem 09.05. insgesamt 4x aufgetreten (inklusive heute). Ist bei mir also auch relativ selten.

Bei manchen in den Issues ist aber von mehrmals am Tag oder sogar alle paar Minuten die Rede...

Ob das mit X/Wayland was zu tun hab weiß ich nicht, das hatte aber ChatGPT aus irgendeinem Grund auch vermutet.
 
Ich bin hier auf Fedora 41 mit Kernel 6.14 und einem Ryzen 8845HS/Radeon 780M unterwegs und hatte noch keinerlei Probleme.
Allerdings hat meine Mini-PC auch keinen Akku und ist nicht ganz so kraß auf Stromsparen konfiguriert.
 
Ich bin ja Intel + Nvidia Nutzer, und muss wegen meiner Karte den proprietären Treiber nutzen. In manchen Nvidia Foren wurde der Bug auch schon diskutiert. Aber weil Nvidia die Angewohnheit ihre Treiber gerne mal inklusive Bugs zu shippen, wusste niemand ob jetzt der Treiber oder der Kernel das Problem ist. Noch dazu, wenn man, wie ich, ein Rolling Release nutzt. 🤪

Edit: Ah sehe, ist ein anderer Bug. Da geistert aktuell aber auch noch ein anderes Problem durch die Foren.
 
Einfrieren des Systems geht auch mit Intel / Intel bei Kernel 6.1, einem Thinkpad von 2008 mit Akku von 2011. Wenn man die "Künstliche Intellienz" anschubst mit Hinweis auf einen alten Akku, holla, da geht richtig etwas. Dann habe ich die "KI" gefragt, ob es an tp-smapi-dkms liegen kann. Und jau, unser seit Jahrzehnten verwendetes tp-smapi kann natürlich den Rechner einfrieren lassen, aber sowas von. Dann habe ich "KI" 61 Grad CPU Temperatur verraten, und ratet mal, was dann auf einmal ein altes Thinkpad einfrieren lässt. :D
 
das hatte aber ChatGPT aus irgendeinem Grund auch vermutet.
Dann habe ich die "KI" gefragt, ob es an tp-smapi-dkms liegen kann
Ihr geht aber nicht beide noch zusätzlich zu einer Wahrsagerin, um die Systemfehler zu debuggen, oder? :D So oft wie die LLMs halluzinieren, da würde ich mich auf deren Aussagen niemals verlassen.

Ich nutze übrigens Fedora 42 mit Wayland, da ist aktuell Kernel 6.14 an Bord. Es betrifft also auch neuere Kernel.
 
Die Probleme hatte ich mit 6.12 auch. Seit 6.14 sind sie scheinbar verschwunden (780M).
 
Ihr geht aber nicht beide noch zusätzlich zu einer Wahrsagerin, um die Systemfehler zu debuggen, oder? :D So oft wie die LLMs halluzinieren, da würde ich mich auf deren Aussagen niemals verlassen.
Um so einen Fehler grob einzugrenzen ist die KI tatsächlich nützlich - gerade wenn man so wenig zum Thema weiß, dass man Schwierigkeiten hat die Frage überhaupt erst zu formulieren. Man kann einfach die Logdatei reinkippen und sagen, "Wasn da los?"

Dass man die Antworten erst ernst nehmen sollte, wenn man sie aus anderer Quelle bestätigen konnte, dürfte hoffentlich klar sein. Deswegen bei X vs. XWayland auch die klare Anmerkung, dass das die KI vorgeschlagen hatte - entsprechend vorsichtig sollte man mit dieser Info umgehen.

Ich hatte gestern aufgrund der Kommentare zu PSR auf den Issues übrigens mal PSR per Bootparameter ausgestellt - soweit erst mal so gut, mal gucken ob bzw. wie lang das durchhält.
 
Moin,
habt Ihr denn alle keine Systeme mit X mehr? Wayland war bei mir (Debian 12) das unvollkommenste und instabilste, was ich in 25 Jahren Linux erleben durfte. Gut, Debian Stable ist nicht hipp aktuell, sondern soll einfach stabil laufen. Wayland habe ich daher sogar weitgehend entfernt.

Mir fiel eben auch ohne "KI" auf, dass die Betroffenen scheinbar alle mit Wayland arbeiten. Ich hatte mit X dagegen nie Probleme mit dem genannten Gerät unter KDE. Ganz ohne "KI" vermute ich einmal, dass wir es eher mit einem Wayland- Thema zu tun haben könnten, als mit einem Kernel- Problem.
 
Wie gut Wayland funktioniert, hängt wohl stark von der Desktopumgebung ab. Mit einer aktuellen Version von KDE Plasma läuft das bei mir sehr stabil und vor allem Features wie fractional scaling möchte ich nicht mehr missen, da ich drei Monitore in sehr unterschiedlichen Größen und Auflösungen an meinem Gerät hängen habe. Unter X ist das ein extremer Performancekiller.

Debian setze ich privat nicht mehr ein, da die Pakete mir einfach zu angestaubt sind. Das mag in Serverumgebungen gut funktionieren, aber nicht auf dem Desktop.

Zum Vergleich:

Fedora 42: KDE Plasma 6.3.5
Debian 12: KDE Plasma 5.27.2

Da werden in der Zwischenzeit viele Bugs gefixt worden sein und die Fixes sind noch nicht in der Distribution aufgetaucht.
 
habt Ihr denn alle keine Systeme mit X mehr? Wayland war bei mir (Debian 12) das unvollkommenste und instabilste, was ich in 25 Jahren Linux erleben durfte. Gut, Debian Stable ist nicht hipp aktuell, sondern soll einfach stabil laufen. Wayland habe ich daher sogar weitgehend entfernt.
Da wo ich kein xRDP brauche habe ich nur noch Wayland am Laufen. Bis auf AMD Plattformen habe ich damit keinerlei Instabilitäten gehabt - und bei der ersten AMD Plattform (P15v Gen3) traten die Instabilitäten genauso unter X11 auf, da es sich um Firmware/EC Probleme handelte. Bei dem aktuellen Problem hier im Thread gehe ich bisher auch nicht davon aus, dass Wayland vs. X11 relevant ist.

Debian 12 mit Gnome und Wayland ist jedenfalls meiner Meinung nach 100% stabil. Gibt's da Probleme liegt's an der Hardware-Wahl oder einer Fehlkonfiguration.
 
mal ne Frage eines Laien hierzu: mein L14 A Gen 1 ist Ryzen 4500 mit AMD GPU.
Linux hatte ich vor Jahren schon diverse genutzt auf anderen Systemen, aber nicht auf diesem Thinkpad. Mit dem Livestick Linux Mint 22 gebootet scheint jedoch alles zu laufen, keine der genannten Probleme aufgetreten.

ach ja, die Frage: sollte ich da Mint Debian in Betracht ziehen oder ist Mint 22 mit Ubuntu-Unterbau die bessere Variante?
 
Mit dem Livestick Linux Mint 22 gebootet scheint jedoch alles zu laufen, keine der genannten Probleme aufgetreten.
Das ist doch schon mal gut. Das Problem kann zwar auch erst nach mehreren Tagen mal auftreten aber es kann auch gut sein, dass nur neuere AMD Geräte betroffen sind.

ach ja, die Frage: sollte ich da Mint Debian in Betracht ziehen oder ist Mint 22 mit Ubuntu-Unterbau die bessere Variante?
Ich würde ja einfach direkt "echtes" Debian nehmen... aber bei der Wahl zwischen Mint und LMDE spielt wohl viel Geschmack und Philosophie mit. Wenn Du gerade erst mit der Linux-Sache auf dem Thinkpad loslegst, würde ich tendenziell die Version nehmen die mehr Nutzer und dementsprechend auch wesentlich mehr Support bekommt. -> Normales Mint mit Ubuntu-Unterbau.
 
Leider muss ich doch noch ein Followup posten: Nach ca. 2 Wochen seit dem Ausschalten von PSR ist bei mir das Problem erneut aufgetreten. :(

Immerhin scheint PSR ausschalten das Problem etwas zu reduzieren...
 
Jetzt hat es mich auch erwischt. Der Rechner friert unvermittelt ein. Ganz aber nicht, denn zumindest auf Aktivieren des Numlock reagiert er noch...
Dann nach etwas Zeit blinkt das Bild, an - aus - an - aus - bleibt aus.

Was hat sich bei mir geändert: Von bookworm auf das RC von trixie aktualisiert. Da ich den Kernel 6.12.22+bpo-amd64 bereits unter bookworm störungsfrei in Betrieb hatte, war das Update auf 6.12.31-amd64 auch kein großer Sprung.

Den Kernel 6.12.22+bpo-amd64 habe ich noch installiert und jetzt auch von diesem gestartet. Aber eine Dauerlösung ist das sicherlich nicht.
 
Ich hatte das Problem seit Mitte Mai gar nicht mehr (hoffentlich hab ich's jetzt nicht "gejinxt" :D). Aktuell läuft hier Fedora mit Kernel 6.14.9.
 
  • ok1.de
  • IT Refresh - IT Teile & mehr
  • thinkstore24.de
  • Preiswerte-IT - Gebrauchte Lenovo Notebooks kaufen

Werbung

Zurück
Oben