Arch Linux

Verzögerter Start von Programmen

aba

Vielen Dank für deine Mühe.
Ich weiß das zu schätzen.

Nachdem ich nun einige mal mit dem 612er Kernel gebootet und gearbeitet habe, schleicht sich der Eindruck ein auch hier nach jedem boot ein anderes Startverhalten der Programme zu haben.
Solange die Programme nicht abstürzen ist das gerade noch erträglich.
Hauptsache es ist keine Malware die das Verhalten hervorruft.
Ich werde deine vorgeschlagenen Test auf jedenfall durch führen.
Mal sehen was ich daraus lernen kann.

Ich werde das System wohl oder übel Anfang September komplett neu aufsetzen und diesesmal die Grafik Treiber "alle Open Source" belassen, in der Hoffnung wieder ein stabiles und sicheres Betriebssystem zu erhalten.

Herzlichen Dank noch einmal für eure Hilfe.
Gruß aba

GerBra

aba und diesesmal die Grafik Treiber "alle Open Source" belassen

Deine Grafiktreiber sind "OpenSource" - sowohl intel(i915) als auch Nvidia(nouveau) sind im Kernel(source). FIrmware-Blobs brauchst du halt immer.

Nochmal zu evtl. Temperatur-Problemen: Wenn CPU oder Grafikkarte überhitzen dann wird erstmal die CPU-Taktfrequenz runtergedrosselt (CPU-Throtteling). Das führt dann u.a. eben zu einem langsameren System, auch langsameres Starten und bei weiterer Überhitzung schaltet sich das System halt aus.
D.h. du solltest ggf. wirklich mal "in den Laptop" reinschauen (lassen), ob irgendwo Dreck, Staub o.a. ist. Ob die Lüfter noch laufen. Diese erhöhte Temp=langsames System kannst du gerade nach einem "Kaltstart" (z.B. beim ersten Einschalten morgens) relativ schnell kriegen, meist ist das Symptom das nach einigen Minuten es zu bocken anfängt.
Evtl. kannst du doch in diese Richtung etwas feststellen. Viele solcher "mysteriösen Dinge" ließen sich in anderen Threads auf sowas zurückführen.

GerBra

aba Nachdem ich nun einige mal mit dem 612er Kernel gebootet und gearbeitet habe, schleicht sich der Eindruck ein auch hier nach jedem boot ein anderes Startverhalten der Programme zu haben.
Solange die Programme nicht abstürzen ist das gerade noch erträglich.

Du merkst, wie schlecht so ein Symptom zu "debuggen" ist, welches sich vornehmlich aus "Eindrücken" deklariert...

aba Ich werde deine vorgeschlagenen Test auf jedenfall durch führen.

//Edit: Bitte siehe erstmal das Edit ganz unten wegen der Reihenfolge, der ganze Thread ist etwas unübersichtlich geworden, aber ich habe jetzt keine Lust mehr was zu ändern...

Ja, teste die o.a. beiden Kernelparameter mal und behalte dir von beiden mal das Journal vom Boot.
D.h. nach jedem Boot mit einer der Parameter sicherst du dir das Journal dazu mit:
journalctl --system -b > $HOME/journal-b-X
wobei X für sowas wie 1 und 2 und 3 ff. steht, damit es halt unterschiedliche Dateinamen sind.
Bei Bedarf kann man die dann nach dpaste stellen.

//Edit; Und den Test mit einem Testuser, damit man Ursachen ausschließen kann die evtl. nur im $HOME deines Nirmalusers existieren

Weiterhin könnte man ein paar grundlegende Dinge testen:

RAM
Nimm dir ein externes Bootmedium¹ //Edit ggf. nicht nötig->Siehe Fußnote unten ~~(ArchInstall-ISO, oder grml-iso). Beide haben bei der Bootauswahl den Punkt Memtest oder MemoryTest.~~ Das ist ein Testprogramm für den Arbeitsspeicher. Zum Anschauen kannst du den einfach mal so starten und dann wieder abbrechen/rebooten, um einen Eindruck zu kriegen. Der eigentliche Test sollte über mehrere Stunden laufen, also am besten z.B. über Nacht laufen lassen und morgens dann schauen ob Fehler/Errors gemeldet werden.
//Edit2: Falls die Interpretation schwerfällt mache ein Photo vom Ausgabebildschirm und zeige es.
Festplattentest (alles als root ausführen)
Installiere dir das Paket smartmontools. Poste die Ausgabe von:
smartctl -a /dev/nvme0n1
Dann mache einen langen Test:
smartctl -c /dev/mvme0n1
zeigt dir, wie lange ungefähr der Long/Extended Test dauern würde. Dieser Test kann im Hintergrund während des Arbeitens laufen, der Rechner sollte aber diese Zeit anbleiben bis der Test durch ist.
//Edit3: Den langen test selbst startest du mit:
smartctl -t long /dev/nvme0n1
Nach Ablauf der Zeit (und gib ruhig noch mal etliche Minuten darüber zu) postest du nochmal:
smartctl -a /dev/nvme0n1
Generelle Infos zu smartmontools siehe hier:
https://wiki.archlinux.org/title/S.M.A.R.T.
//Edit666<g> Wenn irgendein Befehl nicht funktioniert, dann bitte den Befehl und die Fehlerausgabe dazu hier posten.
Plasma unter X11 testen
Teste (am besten mit 6.16 Kernel) das Plasma statt unter Wayland unter X11/XOrg startet, Dafür muß das Paket plasma-x11-session installiert sein. Nach einem Reboot sollte im Login-Manager(SDDM) die Sitzung "Plasma (X11)" wählbar sein.
Diese Starten und das Verhalten der Programme etc. beobachten. Falls die Sitzung garnicht startet und oder etwas richtige Probleme macht dann neu starten.
Auf jedenfall vor dem Reboot bitte ein Logfile ablegen, damit man das bei Bedarf anschauen kann:
journalctl --system -b > $HOME/journal-b-mit_X11
Ein Logfile finden wo diese Trap-Fehlermeldungen aus den ersten Tests auftauchen
Im Logfile zum 6.16 was du auf den dpaste-Server abgelegt hast waren diese "Traps" ja nicht enthalten. Ich vermute, unter 6.16 passieren die doch noch, aber halt wohl nicht immer. Deshalb schaue während des Arbeitens bitte immer mal, ob diese Meldungen wieder auftauchen. Dazu in einer Konsole immer mal wieder ausführen:
journalctl -S today | grep "VMM allocation failed: -110" | wc -l
Wenn die Ausgabezahl größer als 0 ist (ganz oben hattest du für den Tag mal 30 Treffer), dann dieses Journal bitte mal hochladen:
journalctl --system -b | wgetpaste -s dpaste
und den Link posten.
Damit man den/die Traps mal im Zusammenhang sehen kann.

//Edit

Es gibt ein neues mesa Paket, schau mal das dein System aktualisiert ist. Mesa wäre auch ein Kandidat für solche Probleme die eingangs(1. Post) nach einem Update auftreten können. Schau also mal, ob das aktuelle mesa etwas ändert.
Als weiteren Test (wir müßten uns auf ein Art reproduzierbares "Testszenario" festlegen):
Schau mal, daß das Paket mesa-utils installiert ist.
Dann teste mal über einen Zeitraum ob das Programm
eglgears_wayland
auch beim wiederholten Starten von diesem "Eindruck" des langen, verzögerten Startens betroffen wäre. Starten kannst du das entweder aus einer Konsole oder über diesen KRunner-Dings (wo du ohne übers Menü also Programme starten/aufrufen kannst)
Das wäre ein gutes Programm mit dem man ggf. "Laufzeittests" machen kann.

¹ Es kann auch ein lokal installiertes Tool memtest verwendet werden, also ohne das man ein externes Bootmedium braucht. Da ich keine große Erfahrung mit UEFI und systemd-boot habe, starte ich mal einen neuen Thread wie das am besten ins bestehende Bootmenü des Rechner zu integrieren ist.
https://forum.archlinux.de/d/35591-memtest86efi-ins-system-integrieren
//Edit: Es scheint zu genügen, einfach das Paket memtest86+-efi zu installieren, es sollte dann automatisch im systemd-bootmenü beim Neustart auftauchen. Klappt das?

//Letztes Edit (hoffentlich<g>)
Du siehst, eine "Menge an Arbeit" für Dich...
Manchmal vermisse ich irgendwo einen "Button zum Klicken" auf dem steht: "Löse alle meine Probleme, aber flott!"
Klick -> Kuchen! ;-)

Der zweite Punkt unten von tuxnix ist auch noch ein Test wert

tuxnix installierte
xf86-video-nouveau Treiber dort inzwischen unnötig geworden

//Bäääh EDIT.....
Das sind jetzt soviele Tests und Edits. Klar ist: Nie mehrere Tests gleichzeitig machen, v.a. wenn man ggf. "Verbesserungen" beobachten will und weiß dann nicht was jetzt was "gebessert" hat <g>
Ich Würde die Tests in dieser Reihenfolge machen:

Testuser
System updaten und Mesa test
Die beiden Kernelparameter
Wie tuxnix sagt, test nach Deinstallation von xf86-video-nouveau
Test mit X11 statt Wayland

Falls obige Tests keine Änderung bringen:

Versuchen Logfiles zu finden wenn der Kerneltrap auftritt
Testszenario, also ob das problem auch mit eglgears_wayland reproduzierbar wäre.
RAM-Test und HD-Test können unabhängig gemacht werden, diese lösen ja kein Problem, finden aber ggf. Ursachen.

So, ich hoffe ich habe alles...

aba

GerBra
🙂 ich habe mir ein paar Widgets installiert die mir die HW Temperaturen, die Drehzahl der Lüfter und den Daten IO der Festplatten und Netzwerk anzeigen. Demzufolge ist die HW nicht die Ursache.

GerBra Deine Grafiktreiber sind "OpenSource" - sowohl intel(i915) als auch Nvidia(nouveau) sind im Kernel(source). FIrmware-Blobs brauchst du halt immer.

Es ist das erste mal, dass ich bei der Installation mit dem archinstall script nicht die default Einstellung der Grafiktreiber ausgewählt habe. Ob das relevant ist? ich weiß es nicht.

Ansonsten, kann ich das System durch installieren und deinstallieren korrupiert haben? Ja, klar.

Ich verstehe noch nicht was das System macht oder nicht macht, selbst wenn ich mir mit eurer Hilfe die Daten anschauen kann. ...

GerBra

aba Es ist das erste mal, dass ich bei der Installation mit dem archinstall script nicht die default Einstellung der Grafiktreiber ausgewählt habe. Ob das relevant ist? ich weiß es nicht.

Ich habe keine Ahnung was archinstall so "macht". Meine bestehende Installation ist von

$ head /var/log/pacman.log 
[2015-12-09 19:40] [PACMAN] Running 'pacman -r /mnt -Sy --cachedir=/mnt/var/cache/pacman/pkg --noconfirm base mc syslinux'

aba Ansonsten, kann ich das System durch installieren und deinstallieren korrupiert haben? Ja, klar.

Verstehe ich nicht ganz. Meinst du durch "Updates"? Ja, jedes Update von Systemnahen Dingen wie Kernel-Treiber können ein Problem sein, i.d.R. sind sie es nicht. Da Archlinux immer die aktuellste Versionen von "Software" verwendet treten viele "neue" Probleme halt verstärkt auf bevor sie ggf. andere Distributionen haben(oder dann nie haben).
Beim Kernel (gerade der aktuelle 6.16.x ist ein Beispiel) bietet es sich halt an z.B. den LongTermSupport ("LTS") Kernel zu verwenden wenn man keine "Überraschungen" durch neue Kernel-Major-Versionen erleben möchte (zumindest meistens). Oder zumindest den LTS-Kernel als "Notlösung" installiert zu haben.

aba Ich verstehe noch nicht was das System macht oder nicht macht, selbst wenn ich mir mit eurer Hilfe die Daten anschauen kann

Glaub mir, auch ich fühle mich sehr oft überfordert v.a. seit systemd + Wayland + UEFI + sonstigen "neuen Sch*iss" <g> Bin da "ein wenig zu alt zu..."

tuxnix

2 Gedanken dazu:

Wenn RAM und Kühlung als Fehlerquellen ausgeschlossen sind, dann könnte ein inxi -G schnell Aussagen über die Zusammenarbeit von Kernel, Grafiktreibern und mesa hergeben. Zumindest zeigt es den Status von Dingen wie OpenGL und Vulkan an und genau daran könnte es hakeln wenn Anwendungen zu lange brauchen bis ihre Darstellung steht.
Inxi installieren: pacman -S inxi
Was den Betrieb mit wayland (und xwayland) angeht, so ist der von @aba installierte
xf86-video-nouveau Treiber dort inzwischen unnötig geworden. Er sollte normaler Weise nicht stören, aber falls im Wayland-Betrieb Verzögerungen auftauchen, würde ich ihn auch mal probeweise entfernen, nicht dass hier im Hintergrund ein Gerangel zwischen den Treibern stattfindet.

aba

Hallo zusammen.
Ich habe den größten Teil des gestrigen Tage damit verbracht die Laptop HW zu testen.
Unter anderem habe ich ein neues Dell BIOS installiert.
Das Dell BIOS hat umfangreiche und ausführliche Tests mit welcher die gesammte HW gestet werden kann.
Leider sind die Ergebnisse nicht sehr ausführlich. Laut dieser Tests hat die HW keinerlei Probleme.
Ich habe noch zwei live Systeme auf USB Sticks. Rescue und ein altes Knoppix 9.x.
Ich habe einige HW Test damit wiederholt. Ich konnte keine HW Fehler feststellen.

Den Tipp von tunix habe ich befolgt und den xf86-video-nouveau Treiber entfernt.
Herunterfahen und Neustart des Laptops erfolgte ohne Fehlermeldungen.
Das OS scheint den Treiber nicht zu vermissen.

[u-admin@X12 ~]$ inxi -G
Graphics:
  Device-1: Intel Alder Lake-P GT2 [Iris Xe Graphics] driver: i915 v: kernel
  Device-2: NVIDIA GA107M [GeForce RTX 3050 Mobile] driver: nouveau
    v: kernel
  Device-3: CN02JJ9G8LG00242B6JZA01 Integrated_Webcam_HD driver: uvcvideo
    type: USB
  Display: wayland server: X.org v: 1.21.1.18 with: Xwayland v: 24.1.8
    compositor: kwin_wayland driver: X: loaded: modesetting dri: iris,zink
    gpu: i915 resolution: 1: 3440x1440~100Hz 2: 3840x2400~60Hz
  API: EGL v: 1.5 drivers: iris,swrast
    platforms: gbm,wayland,x11,surfaceless,device
  API: OpenGL v: 4.6 compat-v: 4.5 vendor: intel mesa v: 25.2.1-arch1.4
    renderer: Mesa Intel Iris Xe Graphics (ADL GT2)
  API: Vulkan Message: No Vulkan data available.
  Info: Tools: api: clinfo, eglinfo, glxinfo, vulkaninfo
    de: kscreen-console,kscreen-doctor wl: wayland-info
    x11: xdpyinfo, xprop, xrandr
[u-admin@X12 ~]$ inxi -s
Sensors:
  System Temperatures: cpu: 43.0 C mobo: 36.0 C
  Fan Speeds (rpm): cpu: 1001 fan-1: 1000 fan-2: 1028
[u-admin@X12 ~]$

Die Startverzögerungen der Programmaufrufe sind nach wie vor vorhanden.
Auch dass diese Verzögungen von Boot zu Boot unterschiedlich stark ausgeprägt sind.

/Edit
ich habe gerade eine Session mit dem Kernel 6.12 hinter mir.
Es besteht kein Zweifel mehr daran, dass sich das OS ungeachtet des Kernel gleich schlecht verhält.
Zusätlich habe ich beim Herunterfahren nun regelmäßig SDDM Probleme
(siehe: SDDM verzögert das Herunterfahren).

GerBra

aba ch habe gerade eine Session mit dem Kernel 6.12 hinter mir.
Es besteht kein Zweifel mehr daran, dass sich das OS ungeachtet des Kernel gleich schlecht verhält.
Zusätlich habe ich beim Herunterfahren nun regelmäßig SDDM Probleme

Logfile von diesem Boot?
Mit -b -1 kriegst du das vom letzten Boot (daß weißt du ggf. ja)

Dann konzentriere dich bitte auf den 6.16..
Machst du noch etwas mit den anderen Testpunkten die ich vorschlug?

//Edit: Ich bin nicht sicher ob ob das schon mal gefragt wurde: Gibt es noch eine Windows-Installation auf diesem Rechner? Oder ein anderes System?

tuxnix

Um für die Testerei etwas zu haben, bei der die Langsamkeit mit der Anwendungen geöffnet werden, gemessen werden kann, hab ich ein Skript geschrieben.
Wayland hat keine interne Möglichkeit zu überprüfen wann ein Fenster tatsächlich erscheint.
Aber man kann screenshots machen und die Zeit messen.

#!/bin/bash

mkdir -p /home/$USER/Test
rm /home/$USER/Test/*.png

TIME=$(date +%s%N)

# Anwedungstest
#APP=alacritty
APP=konsole
$APP &
PID=$!

i=0
while [ $i -le 6 ]
do
    SNAPTIME=$(date +%s%N)
    DURATION=$((($SNAPTIME-$TIME)/1000000))
    #grim /home/$USER/Test/${APP}-${DURATION}ms.png
    spectacle -bno ~/Test/${APP}-${DURATION}ms.png
    ((++i))
done

kill $PID

# eglgears_wayland
TIME=$(date +%s%N)

eglgears_wayland &
PID=$!

i=0
while [ $i -le 6 ]
do
    SNAPTIME=$(date +%s%N)
    DURATION=$((($SNAPTIME-$TIME)/1000000))
    #grim ~/Test/gears-${DURATION}ms.png
    spectacle -bno ~/Test/gears-${DURATION}ms.png
    ((++i))
done

kill $PID

Man kann dann im ~/Test Ordner schauen (dolphin hat eine Vorschau), welcher snapshot als erstes ein neu geöffnetes Konsolenen-Fester zeigt. Der Name der .png Datei zeigt die Millisekunden an die es gedauert hat. Die Empfindlichkeit der Messung wird dabei von der Geschwindigkeit von spectacle bestimmt.

Ich hoffe damit lässt sich schnell feststellen ob eine Kombination von Treibern und Kernel Probleme macht. Bei mir (ein sehr alters Notebook) benötigt konsole 1384ms bis es auf einem plasma wayland Desktop erscheint.
Die Zahnräder erscheinen nach 5ms.

//Edit 1: eglgears_wayland - Test eingefügt.
//Edit 2: Umstellung auf ms.

GerBra

@tuxnix
Deshalb fragte ich ja ob z.B. eglgears_wayland davon auch betroffen ist.
Dann kann man Startzeiten (da dieses Programm nicht forkt) relativ einfach so messen:
$ time timeout 1 eglgears_wayland
Andere dieser "Demo-Programme" für GL/Vulkan/Testsuites können so genausi genutut werden.

Aber irgendwie kommen von aba wenig Rückmeldungen, langsam macht das IMHO keinen Sinn mehr.

tuxnix

GerBra Aber irgendwie kommen von aba wenig Rückmeldungen

@aba hat gestern erst den ganzen Tag am Rechner gesessen, vielleicht muss er auch noch mal was anderes tun. 😉

Ich hab jetzt den eglgears_wayland Zahnradtest mal mit ins script gepackt.
Als Orientierung ist der Test recht gut. Aber viel mehr als läuft oder läuft nicht gibt er eigentlich nicht her.

Ich würde vorschlagen ein zweites Script anzulegen, wenn es tiefer gehen soll.
glmark2-es2-wayland wäre so ein Kandidat, da muss ich mich aber noch mal schlauer machen welche anderen Tests sonst nach aussagekräftig sind.

Oben bei der ixni -G Ausgabe ist mir aufgefallen das vulkan nicht läuft. Und für die Nvidia Grafik gibt es keine dedizierte Ausgabe zu was sie fähig ist. Ist das normal? ich hab keine Nvidia-Grafik.

GerBra

Meine Ausgangslage bei dem ganzen Primborium ist/war:

Das starten von Konsole produzierte zweimal Kernel-Traps bzgl. nouveau Post#11
Ein zusammenhängesndes Logfile mit diesen Traps war nicht zu bekommen, Nachfragen ob diese Traps immer noch passieren - unbeantwortet.

Nachfrage nach Liste der Updates aus dem "Update" des OP: unbeantwortet.
Lange Liste mit möglichen Tests um ggf. eine Änderung oder wenigstens für mich nachvollziehbaren Conent(Logs) zu kriegen: unbeantwortet. Alle meine vorgeschlagenen Tests machen m.E. einen Sinn.

Einzige aktuelle Reaktion: jetzt gibt es irgendwas mit SDDM beim runterfahren. Logs? Ha!

Was wollen wir denn mit Laufzeittests für Programme "rausfinden", ohne überhaupt zu wissen (Logs) auf welches drunterliegende "Szenario" sich 6,345 S beziehen?

Alle Aussagen beziehen sich nur auf iregdwelche "Eindrücke", die wechselhaft wie dieser August sind...
Wenn ich dieses Problem hätte, wüßte ich wie ich zu agieren hätte um Dinge "einzukreise" (Tests oben). Vorteil: ich würde ergebnisse sofort im Kontext sehen. In so einem Forum wie hier ist das IMHO bei so einem "Problem" wie es sich aktuell darstellt nicht leistbar - zumindest von meiner Seite nicht, der reingesteckte Aufwand steht nicht im Verhältnis.
Deswegen, ich denke ich bin raus.

//Edit: Um da nochmal drauf einzugehen:

tuxnix Oben bei der ixni -G Ausgabe ist mir aufgefallen das vulkan nicht läuft. Und für die Nvidia Grafik gibt es keine dedizierte Ausgabe zu was sie fähig ist. Ist das normal? ich hab keine Nvidia-Grafik.

Ist denn Vulkan für Wayland/Plasma überhaupt relevant? Ich meine, das Plasma/QT rein über (optimal) OpenGL rendern (bin aber nicht sicher). Zu inxi: Nicht vergessen, das ist ein HybridGraphic System, ich weiß nicht WAS inxi in dem Moment "abfragt". Beide GPUs nutzen auf jedenfall Mesa. Soweit ich im Log gesehen habe, wird OptimusManager auf aba's System verwendet. (Auch da muß ich sagen, fehlt mir die praktische Erfahrung mit Hybrid-GPUs. Um ggf. vulkaninfo mit der jeweiligen GPU zu prüfen habe ich das gefunden:
https://wiki.archlinux.org/title/Vulkan#Switching_between_devices
Aber m.E. ist das ein Nebenkriegsschauplatz...

//Edit: Wenn man garnicht weiterkommt mit testen - und die Infos bzgl. Updates aus Post#1 kämen - dann gäbe es auch die Holzhammer-Methode, per ArchlinuxRollbackMachine auf den Software-Stand vor dem "Update" zurückzugehen (-Syyuu AFAIK). Dann sollte ja alles wieder so sein wie vorher (wenn es nicht generell eine andere Ursache jat).

tuxnix

Mein Skript sollte schlicht von diesen "gefühlten Eindrücken" weg führen. So zumindest die Intension.
Er hat ja schon einiges bewerkstelligt und ist dann aber um die Ecke gebogen.
Ja, ich mach auch erst einmal langsam. und falls es hier weiter gehen sollte, müssen wir halt darauf achten, das eines nach dem anderen abgehandelt und adäquat beantwortet wird.
Man liest von einander! 😉

aba

Danke für die Vorschläge und pardon für die späte Rückmeldung.

Ich habe gestern meinen alten Desktop auf Vordermann gebracht.
Diese Hardware kenne ich seit 10 Jahren und glaube sie gut einschätzen zu können.
Seit ein paar Monaten läuft ein Arch Linux System auf diesem Desktop, welches ich per archinstall script installiert habe. Auch die Applicationen, die ich für meine Arbeitsumgebung brauche sind installiert.
Ich schaue mir die Hardware mit SystemRescue 12.x live system an (USB ISO), weil ich damit ausreichend gut zurecht zurecht komme.

[u-admin@Z87 ~]$ inxi
CPU: quad core Intel Core i7-4771 (-MT MCP-) speed/min/max: 3501/800/3500 MHz
Kernel: 6.16.4-arch1-1 x86_64 Up: 13m Mem: 2.51/31.03 GiB (8.1%)
Storage: 20.49 TiB (48.5% used) Procs: 265 Shell: Bash inxi: 3.3.38
[u-admin@Z87 ~]$ inxi -G
Graphics:
  Device-1: Intel Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics
    driver: i915 v: kernel
  Display: wayland server: X.org v: 1.21.1.18 with: Xwayland v: 24.1.8
    compositor: kwin_wayland driver: X: loaded: modesetting dri: crocus
    gpu: i915 resolution: 3440x1440~50Hz
  API: EGL v: 1.5 drivers: crocus,swrast
    platforms: gbm,wayland,x11,surfaceless,device
  API: OpenGL v: 4.6 compat-v: 4.5 vendor: intel mesa v: 25.2.1-arch1.4
    renderer: Mesa Intel HD Graphics 4600 (HSW GT2)
  API: Vulkan v: 1.4.321 drivers: intel surfaces: N/A
  Info: Tools: api: clinfo, eglinfo, glxinfo, vulkaninfo
    de: kscreen-console,kscreen-doctor wl: wayland-info x11: xdpyinfo,xprop

Es ist mein Referenzsystem geworden, um zu beurteilen, wie gut und zuverlässig ein Linux auf einer "einfachen" und "gut abgehangenen" Hardware läuft.
Jetzt widme ich mich wieder meinem Laptop, der eine nahezu identische Arch Installation wie der Desktop hat aber alles andere als zuverlässig läuft.
Dafür er hat mir verdeutlicht was ich alles nicht weiss und wie unsäglich schwer es mir fällt herauszufinden, ob und wie HW und SW unter Linux arbeiten.
Mit Ausnahme der beiden GPUs im Laptop wage ich zu behaupten, dass der ganze Rest der Hardware ausreichend gut funktioniert. Ich mache eine neue Diskussion auf um meine GPU Fragen zu beantworten und komme dann hierhin zurück um dort anzuknüpfen wo ich aufgehört habe.
🙂 aba

GerBra

Wenn man hier mit dem betreffenden System noch weitermachen will (nach so viel Tagen und ggf. Änderungen) wäre mein Vorschlag:

ein komplettes Systemupdate vornehmen
den aktuellen 6.16.x booten
Einen "subjektiven" Eindruck erhalten ob der "Verzögerungen"/"Langsamkeit"
Am besten nach dem Start ein komplettes Journal (journalctl -b) auf einen Pastebin legen

Und:

In einer Konsole das hier:
journalctl --system --follow --grep "cut here"
mitlaufen lassen. Das filtert das fortlaufende Journal auf Kerneltrap-Meldungen.
Ganz normal eine Zeitlang arbeiten, Programme und Konsole öffnen/schließen etc.
Dieses Terminal mit dem Journal immer beobachten.
Sobald dort Zeilen ausgegeben werden (also "Treffer") dann brauchen wir dieses gesamte Journal (pastebin). Am besten noch beschreiben, was man gemacht hat als dort "Treffer" gefunden wurden (Firefox geöffnet, Libreoffice, dies_und_das)
Wenn über einen längeren Zeitraum nichts gefunden wird, dann das auch mitteilen.

Also:
1 x Logfile von einem 6.16.x Boot mit aktuellem System
Logfiles sobald von der beobachtenden Konsole Treffer für "Kerneltraps" gefunden würden.

aba

~~Klingt vernünftig. Wird erledigt.~~

Gibt es eine Möglichkeit sich den Diskussionsverlauf herunter zu laden?
oder muss ich dazu die Browser tools z.b. Drucken bemühen?

Ich denke es ist genug. Verschwendet nicht länger eure Zeit.
@Administrator: Bitte das Konto von aba entgültig schließen.

GerBra

aba herunter zu laden?

Ad hoc wüßte ich nicht.
Handy? Zweiter Rechner?
Ausdrucken/Abspeichern als PDF? (Schützt den Wald, und so...)

« Vorherige Seite