Absturz-Ursache finden?

[rola621]

Hallo!

Bin mit meinem System soweit sehr zufrieden, bis auf die Tatsache, dass hin- und wieder (die grafische Oberfläche) einfriert und nur noch das Terminal funktioniert, was sich dann allerdings mit einem

Code: Alles auswählen

sudo service lightdm restart

immer wieder direkt erledigt hat.
Da das nur sehr selten auftritt und dann auch ohne größere Folgen, habe ich das bisher gelassen gesehen.

Heute hatte ich allerdings einen Vorfall, der mich zum tieferen Nachdenken anregt:
Rechner frisch hochgefahren, eine Weile gesurft, anschließend zur Bearbeitung einer Tabelle in LibreOffice Calc übergegangen... nichts rechenintensives also, ziemlich entspannt und unspektakulär.

Dann plötzlich ein freeze, wie ich ihn vom eingangs beschriebenen Freezen der grafischen Oberfläche schon kannte. Keine Reaktion auf Klicks mehr, weder in LibreOffice noch sonstwo. Erster Gedanke: Okay, muss ich wieder Mal

Code: Alles auswählen

sudo service lightdm restart

einsetzen.
Doch ehe ich das machen konnte, wechselte mein Bildschirm zu einem schwarzen Bildschirm und alles was noch da war, ein blinkender Cursor in Form eines Unterstrichs (_), sonst nichts.
Dann kurz gewartet, keinerlei Veränderung.
Habe ihn dann abgewürgt und will mich jetzt auf Fehlersuche begeben.

Dabei habe ich jetzt mal hiermit angefangen:

https://paste.ofcode.org/65SuxYfgAVnjQbSatLckGS

Kann mir bitte jemand sagen ob da ernsthafte Probleme dabei sind, die generell gelöst werden sollten, und welche davon potentiell im Zusammenhang mit dem Absturz oder den lightdm freezes stehen könnten?
Der "große" Absturz mit schwarzem Bildschirm und Cursor war am 05.01.23 um ca. 11:53-11:57, habe nicht genau auf die Uhr geschaut.

Ich freue mich über jeden konstruktiven Beitrag

[hikaru]

Der "große" Absturz mit schwarzem Bildschirm und Cursor war am 05.01.23 um ca. 11:53-11:57, habe nicht genau auf die Uhr geschaut.

In deinem Log findet sich wiederholt diese Meldung:

Code: Alles auswählen

Jan 05 11:53:47 desktop kernel: i915 0000:00:02.0: [drm] *ERROR* rcs0 reset request timed out: {request: 00000001, RESET_CTL: 00000001}

Kippt man die in eine Suchmaschine, dann ergibt sich das Bild, dass es offenbar seit Kernel 5.4 mit gewissen Intel-GPUs immer mal wieder Stabilitätsprobleme gibt. Möglicherweise gibt es einen Workaround mittels eines, oder mehrerer Kernelparameter [1], der aber zu Lasten des Stromverbrauchs geht.


[1] https://bbs.archlinux.org/viewtopic.php ... 7#p2133427

[rola621]

Danke vielmals für Deine Antwort!

Wollte jetzt die in dem verlinkten Beitrag besprochene Methode des arch wikis durchführen und

Code: Alles auswählen

Option "NoAccel" "True"

im besagten configuration file einfügen.

Da wird aber xf86-video-intel als Voraussetzung angegeben, das es scheinbar nur in den arch repos gibt. Was wäre denn das Pendant bei Debian?
Folgendes ist auf meinem System bereits installiert:
xserver-xorg-video-intel
libdrm-intel1
intel-microcode
intel-media-va-driver

Reicht das als Voraussetzung?

Falls ja, würde ich dann wie dort beschrieben diese conf-Datei unter

Code: Alles auswählen

/etc/X11/xorg.conf.d/20-intel.conf

erstellen, und darin dann folgendes einfügen

Code: Alles auswählen

Section "Device"
  Identifier "Intel Graphics"
  Driver "intel"
  Option "NoAccel" "True"
EndSection

Das wäre mal der erste Versuch, oder?

[thunder11]

Ich weiss ja nicht was du für eine Maschine hast, aber
xserver-xorg-video-intel hab ich bei mir nicht installiert. Aus dem Kommentar dazu:

Von der Nutzung dieses Treibers wird abgeraten, wenn Ihre GPU hinreichend
aktuell ist (ca. 2007 und neuer). Sie können versuchsweise diesen Treiber
deinstallieren und stattdessen den Server seinen eingebauten
»modesetting«-Treiber nutzen lassen.

Prozessor: Intel Core i9-9900

Code: Alles auswählen

Graphics (TESTING):
  Device-1: Intel CoffeeLake-S GT2 [UHD Graphics 630] driver: i915 v: kernel
  Display: x11 server: X.Org v: 21.1.10 driver: X: loaded: modesetting
    unloaded: fbdev,vesa dri: iris gpu: i915 resolution: 3840x2160~60Hz
  API: EGL v: 1.5 drivers: iris,swrast platforms: gbm,x11,surfaceless,device
  API: OpenGL v: 4.6 vendor: intel mesa v: 23.2.1-1 renderer: Mesa Intel
    UHD Graphics 630 (CFL GT2)

[rola621]

Code: Alles auswählen

       _,met$$$$$gg.          desktop@desktop 
    ,g$$$$$$$$$$$$$$$P.       --------------- 
  ,g$$P"     """Y$$.".        OS: Debian GNU/Linux 12 (bookworm) x86_64 
 ,$$P'              `$$$.     Host: B560M DS3H V2 
',$$P       ,ggs.     `$$b:   Kernel: 6.1.0-17-amd64 
`d$$'     ,$P"'   .    $$$    Uptime: 5 hours, 59 mins 
 $$P      d$'     ,    $$P    Packages: 2635 (dpkg), 20 (flatpak) 
 $$:      $$.   -    ,d$$'    Shell: bash 5.2.15 
 $$;      Y$b._   _,d$P'      Resolution: 1920x1080, 1920x1080 
 Y$$.    `.`"Y$$$$P"'         DE: Xfce 4.18 
 `$$b      "-.__              WM: Xfwm4 
  `Y$$                        WM Theme: Default-hdpi 
   `Y$$.                      Theme: Adapta-Red-Nokto [GTK2] 
     `$$b.                    Icons: AD-Tangerine-Suru [GTK2] 
       `Y$$b.                 Terminal: xfce4-terminal 
          `"Y$b._             Terminal Font: Monospace 13 
              `"""            CPU: 11th Gen Intel i7-11700 (16) @ 4.800GHz 
                              GPU: Intel RocketLake-S GT1 [UHD Graphics 750] 
                              Memory: 4850MiB / 31886MiB                                   
CPU: 8-core 11th Gen Intel Core i7-11700 (-MT MCP-)
speed/min/max: 800/800/4800:4900 MHz Kernel: 6.1.0-17-amd64 x86_64 Up: 5h 59m
Mem: 5334.0/31886.4 MiB (16.7%) Storage: 2.73 TiB (44.1% used) Procs: 348
Shell: Bash inxi: 3.3.26

Ich weiß auch garnichtmehr ob ich xserver-xorg-video-intel manuell installiert habe oder nicht, glaube aber, dass das bei der Installation automatisch mitgemacht wurde.

Wenn ich das Paket jetzt also deinstalliere, wie lasse ich dann "stattdessen den Server seinen eingebauten »modesetting«-Treiber nutzen" ?

Wie würdet ihr der Reihe nach konkret vorgehen, also wie würdet ihr die genannten möglichen Lösungswege priorisieren?

[thunder11]

Das hab ich auch :

Code: Alles auswählen

      _,met$$$$$gg.          thunder's Kiste 
    ,g$$$$$$$$$$$$$$$P.       ------------------------------ 
  ,g$$P"     """Y$$.".        OS: Debian GNU/Linux trixie/sid x86_64 
 ,$$P'              `$$$.     Kernel: 6.5.0-5-amd64 
',$$P       ,ggs.     `$$b:   Uptime: 8 hours, 49 mins 
`d$$'     ,$P"'   .    $$$    Packages: 3438 (dpkg), 6 (flatpak) 
 $$P      d$'     ,    $$P    Shell: bash 5.2.21 
 $$:      $$.   -    ,d$$'    Resolution: 3840x2160 
 $$;      Y$b._   _,d$P'      DE: Xfce 4.18 
 Y$$.    `.`"Y$$$$P"'         WM: Xfwm4 
 `$$b      "-.__              WM Theme: RedmondXP-hidpi 
  `Y$$                        Theme: Prof-XFCE-2.1-Light-Panel [GTK2/3] 
   `Y$$.                      Icons: Tango [GTK2/3] 
     `$$b.                    Terminal: Thunar 
       `Y$$b.                 CPU: Intel i9-9900 (16) @ 5.000GHz 
          `"Y$b._             GPU: Intel CoffeeLake-S GT2 [UHD Graphics 630] 
              `"""            Memory: 5756MiB / 31751MiB 
                              Font: Noto Sans Mono 13 [GTK2/3] 

inxi mach aber mehr sinn

Sie können versuchsweise diesen Treiber
deinstallieren und stattdessen den Server seinen eingebauten
»modesetting«-Treiber nutzen lassen.

Ich hab den irgendwann gelöscht und einen Neustart gemacht -- gut war es.
Kannst ja vor und nach dem "Umbau"mal

Code: Alles auswählen

inxi -G

oder

Code: Alles auswählen

inxi -Gxx

laufen lassen und vergleichen.

Interessant wäre da diese Zeile im Vergleich:

Code: Alles auswählen

Display: x11 server: X.Org v: 21.1.10 driver: X: loaded: modesetting

Ob es daran aber liegt ? Keine Ahnung.

[rola621]

aktuell:

Code: Alles auswählen

inxi -G
Graphics:
  Device-1: Intel RocketLake-S GT1 [UHD Graphics 750] driver: i915 v: kernel
  Device-2: AIRHUG 02 type: USB driver: uvcvideo
  Display: x11 server: X.Org v: 1.21.1.7 driver: X: [b]loaded: modesetting[/b]
    unloaded: fbdev,vesa dri: iris gpu: i915 resolution: 1: 1920x1080~60Hz
    2: 1920x1080~60Hz
  API: OpenGL v: 4.6 Mesa 22.3.6 renderer: Mesa Intel Graphics (RKL GT1)

nach Deinstallation von xserver-xorg-video-intel:

Code: Alles auswählen

inxi -G
Graphics:
  Device-1: Intel RocketLake-S GT1 [UHD Graphics 750] driver: i915 v: kernel
  Device-2: AIRHUG 02 type: USB driver: uvcvideo
  Display: x11 server: X.Org v: 1.21.1.7 driver: X: [b]loaded: modesetting[/b]
    unloaded: fbdev,vesa dri: iris gpu: i915 resolution: 1: 1920x1080~60Hz
    2: 1920x1080~60Hz
  API: OpenGL v: 4.6 Mesa 22.3.6 renderer: Mesa Intel Graphics (RKL GT1)

scheint also so, als wäre des entfernte Paket ohnehin nicht aktiv im Einsatz gewesen, da der modesetting Treiber vorher ja bereits geladen war, oder?
Daher wahrscheinlich gut, dass ich mich um das Paket erleichtert habe.

Da das aber offensichtlich nicht die Ursache gewesen sein kann weil ja zuvor bereits modesetting aktiv war, würde ich mich an die im archwiki beschriebene Vorgehensweise machen.

Habe jetzt also die Datei erstellt via

Code: Alles auswählen

sudo mousepad /etc/X11/xorg.conf.d/20-intel.conf

und folgendes eingefügt

Code: Alles auswählen

Section "Device"
  Identifier "Intel Graphics"
  Driver "intel"
  Option "NoAccel" "True"
EndSection

Jetzt nochmal ein Neustart

[rola621]

beim Hochfahren während des Neustarts bekam ich eine rote Meldung "Failed to start lightdm.service" und konnte mich dann über die Kommandozeile bei Debian anmelden, was ich auch tat.
Habe dann über die Kommandozeile via

Code: Alles auswählen

sudo rm /etc/X11/xorg.conf.d/20-intel.conf

das ganze wieder rückgängig gemacht, und mit

Code: Alles auswählen

sudo service lightdm restart

war ich dann zum Glück wieder zurück in der grafischen Oberfläche.
Bin alles andere als der Terminal Bastler... daher habe ich jetzt etwas Bedenken, durch weitere Experimente mehr kaputtzumachen als ich gutes tue..

Wie würdet ihr angesichts der bisherigen Versuche weiter vorgehen?

EDIT:
habe es jetzt noch mit der alternativ beschriebenen Methode probiert:

Alternatively, try to disable the 3D acceleration only with the DRI option:

Option "DRI" "False"

Habe also diese Option statt der vorherigen Option gesetzt.

Ergebnis nach Neustart das Gleiche: "Failed to start lightdm.service"

Habe ich irgendwas falsch gemacht, oder kann ich daraus jetzt schließen, dass es bei mir nicht an den genannten Optionen gelegen hat?

[peter1969]

Hallo

Du hast nach der Deinstallation von xserver-xorg-video-intel versucht, deinen Rechner mit genau diesem gelöschten Treiber zu starten:

Code: Alles auswählen

Section "Device"
  Identifier "Intel Graphics"
  Driver "intel"
  Option "NoAccel" "True"
EndSection

Irgendwie erscheint es mir logisch, dass das nicht ging . Installiere das Paket wieder, dann sollte es gehen.

[rola621]

Danke für den Hinweis, klingt soweit logisch!

Allerdings:

Einerseits wird von der Verwendung des Intel Treibers aus xserver-xorg-video-intel abgeraten:

Von der Nutzung dieses Treibers wird abgeraten, wenn Ihre GPU hinreichend
aktuell ist (ca. 2007 und neuer). Sie können versuchsweise diesen Treiber
deinstallieren und stattdessen den Server seinen eingebauten
»modesetting«-Treiber nutzen lassen.

andererseits werden hier Lösungsvorschläge präsentiert, die auf der Anpassung der Konfiguration des Intel Treibers beruhen.

Was ich mich jetzt halt frage:

- Ist da vom gleichen Intel Treiber die Rede? Gibt es nur diesen einen aus diesem Paket, der für mein System bzw. GPU in Frage kommt?

- wie in vorherigem Beitrag von mir dokumentiert, war vor und nach der Deinstallation von xserver-xorg-video-intel der modesetting-Treiber aktiv.

Ich halte also laut meiner Logik mal fest:
Zum Zeitpunkt der Abstürze war der modesetting-Treiber aktiv, ein Intel-Treiber war nicht geladen.
Nach Deinstallation von xserver-xorg-video-intel war immer noch der modesetting-Treiber aktiv.
Daher würde ich jetzt gerne versuchen, einen passenden Intel-Treiber für die GPU zu laden.

Bleiben dann allerdings noch die Fragen offen:
- welchen Intel-Treiber nutzen und wie diesen aktivieren/laden?
- wenn der korrekte Treiber geladen ist habe ich ja immer noch 4 Optionen:
A) den Intel-Treiber dann nutzen wie er ist, und schauen was passiert
B) den Intel-Treiber + Option "NoAccel" "True" im conf-File nutzen
C) den Intel-Treiber + Option "DRI" "False" im conf-File nutzen
D) den Intel-Treiber mit beiden Optionen gleichzeitig aktiviert nutzen?

Welche der Optionen würdet ihr wählen, und wie dabei vorgehen?
Oder alle einfach durchprobieren? (Falls ja in welcher Reihenfolge?)

[MSfree]

andererseits werden hier Lösungsvorschläge präsentiert, die auf der Anpassung der Konfiguration des Intel Treibers beruhen.

Auch wenn dein Link Aktualität suggeriert, diese Emfpehlungen sind 20 Jahre alt und können getrost ignoriert werden.

[GregorS]

andererseits werden hier Lösungsvorschläge präsentiert, die auf der Anpassung der Konfiguration des Intel Treibers beruhen.

Auch wenn dein Link Aktualität suggeriert, diese Emfpehlungen sind 20 Jahre alt und können getrost ignoriert werden.

Woran erkennst Du, dass die Empfehlungen 20 Jahre alt sind?

Gruß

Gregor

[MSfree]

Woran erkennst Du, dass die Empfehlungen 20 Jahre alt sind?

Reine Erinnerung. Auf meinem damaligen Notebook (Penium-M von 2006) mußt ich anfangs genau solche Einträge erzeugen, damit die damals brandneue Intelgraphik funktionierte.

[wanne]

Willkommen in der Welt von X11, seinen 5Mio. APIs und Desighnänderungen über die selbst die X.Org-Entwickler selbst sagen, dass sie den Überblick verloren haben.

Zuerst mal kennt Linux eigentlich keine Treiber. Da es Open Source ist kann jeder eigentlich die Unterstützung für seine Hardware direkt rein programmieren. Linux kann aber zur Übersichtlichkeit in Module unterteilt werden, die oft die Funktion eines Treibers einnehmen und dann oft auch so genannt werden. In deinem Fall ist i915 für deine Grafikkarte zuständig. Es dürfte die weit wichtigere Sache als alles nachfolgende sein.

X11 wurde ursprünglich mit der Idee entwickelt, dass es Hardware-2D-Acceleratoren gibt und man dann generische Treiber für X11 schreiben (die dann auf allen Betriebssystemen laufen) kann die diese Hardware bedienen. Nu kann auf keinem modernen Betriebssystem ein einfaches Programm (wie der X-Server) direkt auf die Hardware zugreifen noch gibt es noch dedizierte 2D-Acceleratoren. Deswegen gab es in X11 fake Treiber die dann mit dem Modul im Kernel gesprochen haben um die 2D Befehle umzusetzen (und dafür meist als root laufen mussten) das wäre xserver-xorg-video-intel. Mit der Zeit etablierten der Kernel generischere APIs wie man auf beliebige GPU zugreifen kann. – Die einfachste ist, dass du einfach Farbbytes nach /dev/fb0 schreiben kannst. Kannst du mit cat [Bild] > /dev/fb0. Der fbdev-X11-Trebier macht das. Ist aber sehr ineffizient. Alternativ gab es den sehr beschränkten vesa und eben mit DRM KMS das der modesetting-X11-Treiber nutzt. – Da DRM für alle Programme zugänglich ist, kann X.Org seither als nicht-root laufen. Da das geht sind meisten Programme heute dazu übergegangen (oft über über OpenGL) direkt DRM zu nutzen und den X11-Server nur noch für Verwaltungsfunktionen wie Fenster-Verschieben oder die Zwischenablage zu nutzen. (Was dann zu Wayland geführt hat, dass stark vereinfacht ein anderes Wort für "Anwendungen: Zeichnet eure Fenster doch selber!" ist.)


* Entsprechend: DRI=false wird dir ziemlich sicher deine Grafik killen, weil da jetzt alles drüber läuft. Und selbst wenn da noch die alten APIs als Backup existieren hat X.Org unter Debian erstmal keine Rechte die zu nutzen.
* Der alte xserver-xorg-video-intel Treiber sollte eigentlich noch für deine Karte funktionieren. Ich tippe aber dass es nicht damit getan ist einfach Intel in die xorg.conf zu schreiben den wieder zum Laufen zu bekommen sondern da sich da zu viel geändert hat, hässlich kompliziert wird.
* NoAccel schaltet alle 2D-Acceleration-APIs ab und macht alles in Software. Theoretisch ist das ein großer Performance-Einschnitt. Da real eh fast alle Programme am X.Org vorbei zeichnen zweifle ich das es einen Unterschied macht. – Aber ebenso dass es irgend welche Bugs umgeht.

Aus gleichem Grund vermute ich dass deine Suche nach Fehlern im X11 fehlgeleitet ist. Das Ding macht nicht mehr viel. Würde mal zur Schadenseinkreisung ne andere grafische Oberfläche die X11 und Wayland kann in beiden Modi verwenden. Wenn es in allen drei fällen auftritt weist du, dass es am Kernel (und damit vermutlich im i915) liegt und dass vermutlich nur ein Kernelupdate oder andere Kernelparameter helfen. Tritt es auch da nur unter X11 auf kannst du wirklich weiter an deinem X.Org rum basteln. Tritt es in keinem der Fälle auf, ist deine grafische Oberfläche schuld.

Daher wahrscheinlich gut, dass ich mich um das Paket erleichtert habe.

Debian hat da ein komisches Abhängigkeitsmanagement. Wenn man einen Treiber tendiert es dazu, andere Teile von X.Org auch entfernen zu wollen. Deswegen lass ich die immer lieber rum liegen. So groß sind sie nicht.

[peter1969]

Ich hatte mal ein ähnliches Problem mit einer alten exotischen Nvidia Grafik, die vom Modesetting-Treiber offensichtlich nicht voll unterstützt wurde. Die Lösung war, anstatt Modesetting den Nvidia-Treiber zu benutzen.

Probier halt mal folgendes aus:

1. installiere xserver-xorg-video-intel wieder

2. Erzeuge die Datei /etc/X11/xorg.conf.d/20-intel.conf mit dem Inhalt:

Code: Alles auswählen

Section "Device"
  Identifier "Intel Graphics"
  Driver "intel"
EndSection

3. Starte neu und überprüfe den Erfolg mit folgendem Befehl (falls der Intel-Treiber benutzt wird, müssen diverse Intel-Einträge erscheinen):
$ sudo grep -e intel /var/log/Xorg.0.log

Falls das Einfrieren nun aufhört, gut. Falls nicht, probiere zusätzlich Optionen aus.

[rola621]

Danke vielmals für Eure Beiträge!
Es gibt wieder ein paar Neuigkeiten:

Geändert habe ich zunächst mal nichts, es ist aber heute mal wieder ein Vorfall gewesen, der etwas komisch war.
Zunächst alles wie immer, habe den Rechner genutzt, Browser, Email etc., und bin dann in der Wohnung unterwegs gewesen, Rechner war weiterhin an.
Das letzte Mal aktiv am Rechner war ich um ca. 19:00 herum..
Als ich dann um ca. 21:10 wiederkam war der Rechner aus. Ich erstmal verwundert, System hochgefahren, erstmal alles wie immer. Hatte keine wichtigen Programme offen oder so, nur ein LaTex-Dokument, das aber ohnehin oft zwischengespeichert wurde.

Dann habe ich mal den Log auf Errors untersucht und wieder die Intel Geschichte vermutet, habe aber nichts dazu gefunden.
Habe dann die komplette logdatei in eine Textdatei überführt und zu der Uhrzeit gescrollt, wo ich ihn wieder hochgefahren habe, um mir dann das anzusehen was davor passiert ist.
Richtig schlau werde ich daraus jetzt allerdings nicht:

https://paste.ofcode.org/Zt6z6B44yEsXPKVatYURgB

Kann von Euch jemand was damit anfangen?

___
Da aber der letzte Error scheinbar definitiv was mit Intel zu tun hatte, bin ich jetzt mal der Empfehlung von Peter gefolgt, und der Neustart ist erstmal gelungen!

Direkt nach dem Neustart waren meine beiden Bildschirme nichtmehr wie sonst zu einem großen zusammengefügt sondern die Ausgabe wurde auf jedem Bildschirm identisch/gespiegelt angezeigt.
Habe das jetzt wieder in den Anezigeeinstellungen umgestellt und passt.
Es kann auch placebo sein, aber irgendwie wirkt die Grafik auf mich jetzt insgesamt irgendwie ausgewogener.

Die geforderte Ausgabe sieht folgendermaßen aus:
42072

und:

Code: Alles auswählen

inxi -G
Graphics:
  Device-1: Intel RocketLake-S GT1 [UHD Graphics 750] driver: i915 v: kernel
  Device-2: AIRHUG 02 type: USB driver: uvcvideo
  Display: x11 server: X.Org v: 1.21.1.7 driver: X: loaded: intel dri: iris
    gpu: i915 resolution: 1: 1920x1080~60Hz 2: 1920x1080~60Hz
  API: OpenGL v: 4.6 Mesa 22.3.6 renderer: Mesa Intel Graphics (RKL GT1)

Der intel ist also jetzt aktiv, bin mal gespannt wie sich das alles jetzt entwickelt.
Wegen dem plötzlichen runterfahren heute Abend, denkt ihr das hängt auch mit dem intel zusammen?

[peter1969]

Keine Ahnung. Falls Dein Rechner nun vernünftig läuft, bitte eine Rückmeldung geben. Ist ja für alle interessant

[rola621]

bis jetzt läuft alles vernünftig und ohne Errors... ich berichte entweder in ein paar Monaten nochmal falls sich nix tut, oder wieder sobald es den nächsten Error gibt
Danke für Eure Unterstützung!!

[wanne]

Ich hatte mal ein ähnliches Problem mit einer alten exotischen Nvidia Grafik, die vom Modesetting-Treiber offensichtlich nicht voll unterstützt wurde. Die Lösung war, anstatt Modesetting den Nvidia-Treiber zu benutzen.

Der wird ja auch weiter entwickelt. NVIDIA ist ja der einzige, der an der Idee mit den extra X11-Treibern festhält. Intel hat seinen dagegen öffentlich aufgegeben. – Tut aber offensichtlich immer noch.

[rola621]

Also leistungstechnisch habe ich irgendwie das Gefühl, dass es mit dem intel Treiber nicht so flüssig läuft.
Beim Abspielen von normalen 460p Videos ruckelt es bspw. anfangs ein wenig und es dauert eine Weile bis es flüssig läuft.
Müsste mal mit dem modesetting treiber vergleichen ob es damit genauso ist, jetzt will ich aber erstmal den inteltreiber auf die „langzeitprobe“ stellen, um zu sehen ob der freeze nochmal auftritt…

[wanne]

Beim Abspielen von normalen 460p Videos ruckelt es bspw. anfangs ein wenig und es dauert eine Weile bis es flüssig läuft.

Wie gesagt eigentlich sollte kein Videoplayer fürs Video-Abspielen noch irgend was mit dem X11-Treiber noch irgend was machen. Die machen alle seit Jahrzehnten DRM und kein X11-mehr, weil es ohne grauenhaft ruckelt. Da solltest du keine Performance-Unterschiede sehen. Was aber sein, kann ist, dass dir die Erkennung fürs Hardwaredecoding kaputt geht. Guck mal was dein Player da macht.

[rola621]

okay, wie kann ich das genau analysieren?
Verstehe ich es richtig, dass ich DRM bevorzugen sollte? Bin in der Materie nicht so tief drin, aber langfristig kaputtmachen will ich mir natürlich nichts!
Wie würdest Du an meiner Stelle weiter verfahren? Ich kann gerne noch ein paar Analysen schicken, wenn Ihr mir sagt was hier aufschlussreich ist?

[GregorS]

Beim Abspielen von normalen 460p Videos ruckelt es bspw. anfangs ein wenig und es dauert eine Weile bis es flüssig läuft.

Wie gesagt eigentlich sollte kein Videoplayer fürs Video-Abspielen noch irgend was mit dem X11-Treiber noch irgend was machen. Die machen alle seit Jahrzehnten DRM und kein X11-mehr, weil es ohne grauenhaft ruckelt. Da solltest du keine Performance-Unterschiede sehen. Was aber sein, kann ist, dass dir die Erkennung fürs Hardwaredecoding kaputt geht. Guck mal was dein Player da macht.

Ich lese nur interessiert mit und versuche, dem Ganzen zu folgen. Jetzt frage ich mich, was DRM und X11 miteinander zu tun haben. Ich kenne DRM als „Digitales Rechte-Management“. Meinst Du etwas Anderes?

Gruß

Gregor

[MSfree]

Ich kenne DRM als „Digitales Rechte-Management“.

Direct Rendering Manager

[rola621]

Gerade eben war es mal wieder soweit, ich hatte ein LaTeX-Dokument in Texstudio offen, nebenher firefox, ansonsten nix besonderes. War für 1,5h in der Küche, komme wieder und der Rechner ist aus.

Ausgabe von sudo journalctl -r -p err

Code: Alles auswählen

Jan 14 23:18:34 desktop systemd-cryptsetup[32284]: Failed to deactivate: Device>
Jan 14 23:18:34 desktop systemd-cryptsetup[32284]: Device nvme0n1p3_crypt is st>
Jan 14 23:18:34 desktop systemd-cryptsetup[32285]: Failed to deactivate: Device>
Jan 14 23:18:34 desktop systemd-cryptsetup[32285]: Device nvme1n1p1_crypt is st>
-- Boot 177d5192cbc14b49a0c0078adfd33d14 --
Jan 13 23:16:06 desktop systemd-cryptsetup[110673]: Failed to deactivate: Devic>
Jan 13 23:16:06 desktop systemd-cryptsetup[110673]: Device nvme1n1p1_crypt is s>
Jan 13 23:16:06 desktop systemd-cryptsetup[110672]: Failed to deactivate: Devic>
Jan 13 23:16:06 desktop systemd-cryptsetup[110672]: Device nvme0n1p3_crypt is s>
-- Boot 1d75ef2a522f40d198bc4ff5421914e1 --
Jan 12 01:23:35 desktop systemd-cryptsetup[28578]: Failed to deactivate: Device>
Jan 12 01:23:35 desktop systemd-cryptsetup[28578]: Device nvme0n1p3_crypt is st>
Jan 12 01:23:35 desktop systemd-cryptsetup[28579]: Failed to deactivate: Device>
Jan 12 01:23:35 desktop systemd-cryptsetup[28579]: Device nvme1n1p1_crypt is st>
-- Boot 993f0c83be674af28fceb4db9a09f750 --
Jan 11 21:45:21 desktop kernel: watchdog: watchdog0: watchdog did not stop!
Jan 11 21:45:20 desktop systemd-cryptsetup[5704]: Failed to deactivate: Device >
Jan 11 21:45:20 desktop systemd-cryptsetup[5704]: Device nvme1n1p1_crypt is sti>
Jan 11 21:45:20 desktop systemd-cryptsetup[5703]: Failed to deactivate: Device >
Jan 11 21:45:20 desktop systemd-cryptsetup[5703]: Device nvme0n1p3_crypt is sti>

und das restliche journalctl um den Zeitpunkt herum liest sich so:
https://nopaste.debianforum.de/42074

festgestellt, dass der Rechner aus ist habe ich gegen 19:00, dann wieder hochgefahren, was auch in dem log scheinbar so erscheint. Das letzte mal, als ich das gleiche Thema hatte war kurz davor auch schon etwas im log von CRON/crontab/timeshift... kann das irgendwas damit zu tun haben?
Timeshift ist aktuell so eingestellt, dass es stündlich einen Snapshot erstellt, und davon 3 Stück behält.
Nach 19:00 (beim wiederhochfahren warscheinlich) steht da auch was von hibernation... kann da vielleicht was im argen liegen, dass der Rechner irgendwie wegen einem timeshift backup fälschlicherweise in hibernation gegangen ist oder so?


Bin mittlerweile komplett verunsichert und weiß nichtmehr was ich machen oder denken soll.

Ich denke nicht, dass das mit dem plötzlich ausgeschaltetem Rechner mit dem iGPU Treiber zu tun hat, könnte es mir aber auch vorstellen. Wie seht ihr das? Gäbe es denn einen DRM-Treiber für meine "Intel RocketLake-S GT1 [UHD Graphics 750]" ?
Wo würdet ihr an meiner Stelle jetzt weitermachen, um wieder das zuverlässige Debian zu haben das ich kenne und liebe? Habe in letzter Zeit eigentlich nichts großartig geändert, weshalb es mich besonders wundert, dass sich der Rechner selbstständig zu machen scheint.
Bin um jeden Tip dankbar, der wieder etwas Struktur in mein Gedankenchaos und Verzweiflung bringt.

Und die DRM-Sache liest sich auch sehr spannend und vor allem effizient und unabhängig. Kann ich das mit meinem Setup denn einfach bewerkstelligen, oder ist hierzu ein Wechsel des DesktopEnvironments notwendig, oder irgendwas Richtung Wayland etc.?
Windowmanager, X11 etc. sind für mich irgendwie sowas wie ein heißes Eisen an das ich mich nie rantraue, weil ich viel zu viel Bedenken habe, was zu vermurksen und am Ende dann nixmehr zu sehen


Hier auch nochmal ausführlichere Hardware-Infos zu meinem System:
https://linux-hardware.org/?probe=01f214a86d