Ist mein Lenovo Laptop kaputt?

[pelz]

Hallo zusammen,
habe seit Oktober 2025 ein ThinkPad T16 Gen 4 (AMD) mit Arch-Linux und KDE Plasma.

Anfangs lief alles stabil, seit ca. Dezember 2025 gab es erst anfangs und jetzt permanent eine System-Freezes.
Nichts geht mehr, nur ein kompletter Neustart des Systems hilft.

Hier im Forum wurde das Ganze mit KDE und einem ausbleibenden Patch in Verbindung gebracht.
Seit 3 Tagen der Wechsel von KDE auf XFCE und exakt dasselbe Problem.

Die Frage friert das System nach 5min oder 50min ein.

Ein

journalctl -r -p err

bringt im wesentlichen diese Fehlermeldungen zu Tage:

08 16:52:10 fuchsbau kernel: amdgpu 0000:c4:00.0: amdgpu: MES ring buffer is full.
Mai 08 16:52:07  kernel: amdgpu 0000:c4:00.0: amdgpu: MES ring buffer is full.
Mai 08 16:52:05  kernel: amdgpu 0000:c4:00.0: amdgpu: MES ring buffer is full.
Mai 08 16:52:02  kernel: amdgpu 0000:c4:00.0: amdgpu: MES ring buffer is full.
Mai 08 16:52:00  kernel: amdgpu 0000:c4:00.0: amdgpu: MES ring buffer is full.
Mai 08 16:51:57  kernel: amdgpu 0000:c4:00.0: amdgpu: MES ring buffer is full.
Mai 08 16:51:55  kernel: amdgpu 0000:c4:00.0: amdgpu: MES ring buffer is full.
Mai 08 16:51:52  kernel: amdgpu 0000:c4:00.0: amdgpu: MES ring buffer is full.
Mai 08 16:51:50  kernel: amdgpu 0000:c4:00.0: amdgpu: MES ring buffer is full.
Mai 08 16:51:50  kernel: amdgpu 0000:c4:00.0: amdgpu: failed to reg_write_reg_wait
Mai 08 16:51:50  kernel: amdgpu 0000:c4:00.0: amdgpu: MES failed to respond to msg=MISC (WAIT_REG_MEM)
Mai 08 16:51:44  kernel: amdgpu 0000:c4:00.0: amdgpu: failed to reg_write_reg_wait
Mai 08 16:51:44  kernel: amdgpu 0000:c4:00.0: amdgpu: MES failed to respond to msg=MISC (WAIT_REG_MEM)
Mai 08 16:51:42  kernel: amdgpu 0000:c4:00.0: amdgpu: failed to reg_write_reg_wait
Mai 08 16:51:42  kernel: amdgpu 0000:c4:00.0: amdgpu: MES failed to respond to msg=MISC (WAIT_REG_MEM)
Mai 08 16:51:39  kernel: amdgpu 0000:c4:00.0: amdgpu: failed to reg_write_reg_wait
Mai 08 16:51:39  kernel: amdgpu 0000:c4:00.0: amdgpu: MES failed to respond to msg=MISC (WAIT_REG_MEM)
Mai 08 16:51:36  kernel: amdgpu 0000:c4:00.0: amdgpu: failed to reg_write_reg_wait
Mai 08 16:51:36  kernel: amdgpu 0000:c4:00.0: amdgpu: MES failed to respond to msg=MISC (WAIT_REG_MEM)
Mai 08 16:51:34  kernel: amdgpu 0000:c4:00.0: amdgpu: failed to reg_write_reg_wait
Mai 08 16:51:34  kernel: amdgpu 0000:c4:00.0: amdgpu: MES failed to respond to msg=MISC (WAIT_REG_MEM)
Mai 08 16:51:31  kernel: amdgpu 0000:c4:00.0: amdgpu: failed to reg_write_reg_wait

Frage:
Ist mein Laptop hardwaremäßig kaputt?
Denn in der Garantiezeit liege ich noch, könnte also umtauschen, falls nötig.

Wenn dem nicht so ist, was kann ich tun?
Ein Systemfreeze alle 30min ist kein Zustand

Vielen Dank für eure Hilfe und Zeit

 

[100%Laie]

Fehlerhaftes Update damals im Dezember? (Erlebt bei WIN7 und Update für den BROWSER IE !!)
Du hast nie die Systemwiederherstellung auf "November .." probiert? Jetzt wohl schwierig?
Dann wüßtest du, ob es am T16 selbst liegt.
Oder jetzt USB-LIVE ein anderes LINUX.

 

[NameHere]

Hast du den Kernelparameter gesetzt wie im Workaround vorgeschalgen?

It's been going on for months with no fix in sight. Given the severityof the issue, work around it by setting amdgpu.dcdebugmask=0x10 inthe kernel command line, which disables panel self-refresh. Theconsequence will be slightly higher power usage, but this seems worthit to avoid system freezes and hard reboots.

https://invent.kde.org/kde-linux/kde-linux/-/merge_requests/431

 

[sedot]

Ist dein System aktuell, welche Kernel-Version nutzt du?
So wie es auf mich wirkt, gab es auch Probleme mit amdgpu, die inzwischen behoben sein sollten.
In diesem sehr langen Thread erwähnt ein User, dass seine GPU mit +200 Mhz übertaktet war, ein absenken des Taktes mit LACT behob das Problem. Kannst ja mal mit nvtop prüfen.

 

[Sykehouse]

Fehlerhaftes Update damals im Dezember? (Erlebt bei WIN7 und Update für den BROWSER IE !!)

Willkommen, Zeitreisender. Wir schreiben das Jahr 2026, es ist viel passiert, was Sie verpasst haben.

 

[siebengescheit]

Ist mein Laptop hardwaremäßig kaputt?

die Frage wirst nur beurteilen können wenn du mit mehreren Betriebssystemen den gleichen Fehler hast.

 

[Habicht]

ein ThinkPad T16 Gen 4 (AMD) mit Arch-Linux und KDE Plasma.

Hier im Forum wurde das Ganze mit KDE und einem ausbleibenden Patch in Verbindung gebracht.
Seit 3 Tagen der Wechsel von KDE auf XFCE und exakt dasselbe Problem.

Dein Problem hat nichts mit KDE oder XFCE zu tun und ich glaube auch nicht, dass dein T16 kaputt ist.

Ob es kaputt ist, kannst du ja mit jedem x-beliebigen Live-System testen - meine Vermutung als Ursache für dein Problem ist aber eher, dass du mit Arch überfordert bist.
Da du es ja nicht selber schaffst, deine Probleme zu lösen (und bei Arch sollte man das können), wäre eventuell wohl eher eine etwas konservativere Distri wie bspw. Debian angesagt.

 

[Rossie]

Ob es kaputt ist, kannst du ja mit jedem x-beliebigen Live-System testen

Nicht wenn es ein Bug des AMD Treibers ist, der im Kernel von vielen (aktuellen) Distros steckt. Wenn es einen Fix gibt, sollte der bei Arch relativ schnell ankommen. Wenn der Fehler erst seit Dezember auftritt, sollte ein älterer Kernel Abhilfe schaffen bzw. ein Test mit einer Live-Distro mit älterem Kernel (vor 6.18) Klarheit bringen.

EDIT: Der hier referenzierte Patch soll Abhilfe für 6.18/19 schaffen: https://github.com/NixOS/nixos-hardware/issues/1801

 

[sedot]

@Habicht
Ist doch egal mit welcher Distribution sich @pelz auseinandersetzt, im Moment ist es Arch. Distrohopping ist nicht zwingend zielführend.

 

[pelz]

Hast du den Kernelparameter gesetzt wie im Workaround vorgeschalgen?

Hm, hatte ich gemacht, damals mit KDE Plasma. Mit leider Null Effekt.

Ist dein System aktuell, welche Kernel-Version nutzt du?

uname -r

6.18.26-2-lts

Ob es kaputt ist, kannst du ja mit jedem x-beliebigen Live-System testen

Hm, das stimmt.
Mit Windows 11 habe ich diese Probleme bisher nicht. Diese Aussage ist leider nicht zwingend valide, weil ich Windows 11, wenn überhaupt, nur kurze nutzte, um das System aktuell zu halten.

So wie es ausschaut wäre ein Wechsel vom LTS Kernel auf den aktuellen Kernel durchaus eine Überlegung wert, oder beim LTS bleiben und mit geänderten Bootparametern starten.

Was wäre die bessere Wahl?

Vielen Dank

 

[Habicht]

Was wäre die bessere Wahl?

Ich denke mal, das kannst nur du selber entscheiden.

Versuch es doch einfach, bau diesen "NixOS-Patch" mal in deinen LTS-Kernel ein - wenn es funktioniert, dann gut, wenn nicht, dann versuch es mal mit dem aktuellsten Kernel, dürfte irgendwas mit 7.1.x sein.

Ansonsten, Arch-basierte Livesyteme gibt es ja z.B. von CachyOS - damit wärst du nah dran an deinem Arch und könntest es so einfach mal ausprobieren.

@Habicht
Distrohopping ist nicht zwingend zielführend.

Hmmm, es ging mir eigentlich gar nicht um Distrohopping - aber ja, hast recht, wenn ich den betreffenden Beitrag jetzt im nachhinein lese, könnte der Eindruck entstehen.

 

[sedot]

So wie es ausschaut wäre ein Wechsel vom LTS Kernel auf den aktuellen Kernel durchaus eine Überlegung wert, oder beim LTS bleiben und mit geänderten Bootparametern starten.

Wenn du keinen zwingenden Grund hast den LTS Kernel zu nutzen installier den aktuellsten Kernel. Arch ist eine Rolling Release Distribution. 😉

 

[whats4]

ich würde....
...ned auf high level herumtun, wenn ich vermutete, meine hardware könnte ein problem haben.
mit high level ist alles auf betriebssystem-ebene gemeint.

ich würde drunter, weit drunter ansetzen.
auf dem low level alle funktionen resten.

also mit bootbaren testumgebungen, wurscht ob pinguin oder PE basiert.
idealerweise mehrere .
cpu funktionalität
basic mainboardfunktionen,
ram testen, extensiv, weil ram nun mal tricky is.
datenträger

...und erst, wenn geklärt is, daß auf der ebene alles is, wie es sein soll...
kommt betriebsystemebene.
weil vorher machts ned soviel sinn, wie man sieht.
außer "geht ned, zickt" kommt ned soviel bei raus, weil recht blinde herumprobiererei und hoffnung.
leider oft genug an symtomen, ned an ursachen.

is irgendwas "unter der bs ebene", sollte sich das zudem in allen betriebssystemen zeigen.

aber ja... fehlerdiagnose is was für jemand, der die geduld des langstreckenläufers hat.
das und die erfahrung.

 

[100%Laie]

Logik des Zeitreisenden: Erst feststellen, ob T16 schuld und Garantiefall.
Da der Fehler "glücklicherweise" regelmäßig in kurzen Abständen auftritt und du einfach WIN laufen lassen kannst, ist diese Klärung doch einfach.
Danach überlegen, was im Dezember passiert ist, wo evtl. etwas deinstalliert werden könnte o. ä.
Erst dann in LINUX "in die Tiefe".

 

[Kontrapaganda]

Nicht böse gemeint, aber Arch ist und bleibt eine "Selbstbau-Distribution" für Fortgeschrittene, die vom Nutzer erwartet sein Betriebssystem in weiten Teilen manuell zu konfigurieren. Wenn du dich damit überfordert fühlst oder die das einfach zu lästig ist, ist das keine Schande.

Es gibt genügend Auswahl an zuverlässigen Enduser grade Distributionen. Auf dem G4 Thinkpad muss der Kernel auch nicht zwangsläufig brandaktuell sein.

Wenn es unbedingt brandaktuell sein soll, führt an Tumbleweed wohl kein Weg vorbei.

 

[Linuxfreakgraz]

1. Kernel Version Downgraden, das kann pacman.

2. Bug an Kernel.org melden.