Am 14.11.24 um 13:40 schrieb Martin Burnicki:
...
Welcher Kernel läuft da?
Ich hatte in den letzten Tagen ein paar ähnliche Probleme:
Einmal ist mir der Rechner komplett eingefroren, und ich kam nicht mal mehr per SSH drauf.
Ein anderes Mal ist die GUI auch komplett eingefroren, aber SSH-Zugang war noch möglich. In der Ausgabe von "dmesg" tauchten folgende Meldungen auf:
------------------------------------------------------------------------------ kernel: Asynchronous wait on fence 0000:00:02.0:kwin_x11[3167]:70190 timed out (hint:intel_atomic_commit_ready [i915]) kernel: i915 0000:00:02.0: [drm] GPU HANG: ecode 12:0:00000000 kernel: i915 0000:00:02.0: [drm] Resetting chip for stopped heartbeat on rcs0 kernel: i915 0000:00:02.0: [drm] *ERROR* rcs0 reset request timed out: {request: 00000001, RESET_CTL: 00000001} kernel: i915 0000:00:02.0: [drm] *ERROR* rcs0 reset request timed out: {request: 00000001, RESET_CTL: 00000001} kernel: i915 0000:00:02.0: [drm] GuC firmware i915/tgl_guc_70.bin version 70.5.1 kernel: i915 0000:00:02.0: [drm] HuC firmware i915/tgl_huc.bin version 7.9.3 kernel: i915 0000:00:02.0: [drm] HuC authenticated kernel: i915 0000:00:02.0: [drm] GuC submission enabled kernel: i915 0000:00:02.0: [drm] GuC SLPC enabled kernel: Fence expiration time out i915-0000:00:02.0:X[2151]:e0d9f2! kernel: Fence expiration time out i915-0000:00:02.0:Renderer[7029]:3538c6! kernel: i915 0000:00:02.0: [drm] Resetting chip for stopped heartbeat on rcs0 kernel: Fence expiration time out i915-0000:00:02.0:Renderer[7029]:3538c4! ------------------------------------------------------------------------------
Wieder ein paar andere Male war nur ein Fenster (unter KDE/Plasma) eingefroren. In "dmesg" fand ich die Meldung:
------------------------------------------------------------------------------ [10222.715728] x86/split lock detection: #AC: vmx-vcpu-0/25717 took a split_lock trap at address: 0x56029245295a ------------------------------------------------------------------------------
Ich weiß nicht, ob die Meldung relevant ist, aber ich vermute es.
Geschehen ist das Ganze unter (noch) OS Leap 15.5, mit aktuellem Kernel 5.14.21-150500.55.83-default. Zuvor ist der recht neue Rechner immer stabil gelaufen.
Momentan (seit ein paar Tagen) wähle ich beim Booten den älteren Kernel 5.14.21-150500.55.80-default aus, und seitdem ist ein solches Problem nicht mehr aufgetreten.
Daher vermute ich, dass es sich um ein Problem mit dem aktuellen Kernel .83 handelt.
Martin
Mit diesem Kernel und dem davor, *-80-default, habe ich hier auch das Problem, dass mein Gigabyte-MB aus dem Supend-to-Disk zwar aufwacht, aber dann gar nichts mehr geht, nicht mal Netzwerk, und ich ausschalten muss. Seither boote ich *.73-default, damit funktioniert es wie zuvor seit Jahren viele hundert Male... Siehe Mail vom am 18.10., Subject: "Leap 15.5, Kernel 5.14.21-150500.55.80-default und Suspend to Disk - Fehler" Leider steht in den vielen Antwortmails dort keine Lösung (die meisten beziehen sich auf ein Missverständnis), aber jetzt habe ich doch wenigstens einen Hinweis darauf, dass solche Probleme nicht nur bei meiner Hardware auftauchen. Jetzt wär's mal interessant zu wissen, ob das mit Leap 15.6 und dessen 6er Kernel wieder richtig läuft, dann würde ich nicht lange herumsuchen, sondern gleich ein Upgrade machen. -- Viele Grüße Michael