Bestimmte Programme frieren ein nach Laptop-Wechsel
Hallo Liste, seit gestern kämpfe ich mit einem nervenden Problem. Ich habe einen neuen Laptop bekommen, mein älterer Dell Latitude wurde durch einen neueren Dell Latitude ersetzt. Dabei wurde die SSD aus dem alten in den neuen gewechselt. All das lief ohne Probleme. Gestern habe ich aber festgestellt, dass bestimmte Programme mit dem Display oder WM - so vermute ich - nicht funktionieren. Betroffen sind: Zoom, Vivaldi, Discord und Teams for Linux. All diese Programme starten und zeigen recht normal die GUI. Danach aber passiert nichts - ich kann Schaltflächen klicken, aber da passiert gar nichts. Vivaldi zeigt auch nur einen blanken Screen (grau), danach passiert nichts. Alle anderen Programme, z.B. Firefox, Thunderbird, LlibreOffice usw. funktionieren wie bisher. Ich habe diese "Problemprogramme" von Konsole aus gestartet, da kommt keine Fehlermeldungen o.ä. Ich bin etwas ratlos, hätte jemand eine Idee, wo ich schrauben könnte? Ich verwende XFCE4 als WM, die Kiste hat i915 als Grafiktreiber. Ich habe wage im Kopf, so etwas auch mal früher gehabt zu haben. Nur kann ich mich nicht daran erinnern, wie ich es damals gelöst habe :-) Gruß, Kimmo
Kimmo Elo schrieb:
Gestern habe ich aber festgestellt, dass bestimmte Programme mit dem Display oder WM - so vermute ich - nicht funktionieren. Betroffen sind: Zoom, Vivaldi, Discord und Teams for Linux.
All diese Programme starten und zeigen recht normal die GUI. Danach aber passiert nichts - ich kann Schaltflächen klicken, aber da passiert gar nichts. Vivaldi zeigt auch nur einen blanken Screen (grau), danach passiert nichts. Alle anderen Programme, z.B. Firefox, Thunderbird, LlibreOffice usw. funktionieren wie bisher.
Eventuell ein OpenGL-Problem. Probier mal export LIBGL_ALWAYS_SOFTWARE=1 dann wird die Software-Implementierung benutzt (sollte zumindest; ich hatte schon den Fall, dass das nicht beachtet wurde und konnte mir das nicht erklären - unter Leap 15.6 geht es auf jeden Fall). Das könnte je nach Programm zwar zu langsam sein, aber wenn dann was angezeigt wird, handelt es sich um ein Problem mit der Hardware-Unterstützung von OpenGL. Leider sind die wahren Ursachen für solche Probleme schwer zu finden, manchmal helfen bestimmte Konfigurationen für den X11-Server. -- Manfred Härtel, DB3HM mailto:Manfred.Haertel@rz-online.de http://rz-home.de/mhaertel
Hallo, Am 14.11.24 um 09:51 schrieb Kimmo Elo:
Hallo Liste,
seit gestern kämpfe ich mit einem nervenden Problem. Ich habe einen neuen Laptop bekommen, mein älterer Dell Latitude wurde durch einen neueren Dell Latitude ersetzt. Dabei wurde die SSD aus dem alten in den neuen gewechselt. All das lief ohne Probleme.
Gestern habe ich aber festgestellt, dass bestimmte Programme mit dem Display oder WM - so vermute ich - nicht funktionieren. Betroffen sind: Zoom, Vivaldi, Discord und Teams for Linux.
All diese Programme starten und zeigen recht normal die GUI. Danach aber passiert nichts - ich kann Schaltflächen klicken, aber da passiert gar nichts. Vivaldi zeigt auch nur einen blanken Screen (grau), danach passiert nichts. Alle anderen Programme, z.B. Firefox, Thunderbird, LlibreOffice usw. funktionieren wie bisher.
Ich habe diese "Problemprogramme" von Konsole aus gestartet, da kommt keine Fehlermeldungen o.ä.
Ich bin etwas ratlos, hätte jemand eine Idee, wo ich schrauben könnte? Ich verwende XFCE4 als WM, die Kiste hat i915 als Grafiktreiber.
Ich habe wage im Kopf, so etwas auch mal früher gehabt zu haben. Nur kann ich mich nicht daran erinnern, wie ich es damals gelöst habe :-)
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
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
participants (4)
-
Kimmo Elo
-
Manfred Haertel, DB3HM
-
Martin Burnicki
-
Michael Behrens