Xorg stürzt durch viele Anwendungen ab...

Rosendoktor

Well-Known Member
Hallo,

nach dem letzten pkg upgrade vor ein paar Tagen bringen plötzlich viele Anwendungen den X Server zum Absturz. Der crashed einfach und ich lande wieder am Login Screen. In den Logs steht nichts dazu, jedenfalls nichts was ich mit dem Absturz in Verbindung bringen könnte.

System ist FreeBSD 12.0, aktuell, die Pakete sind aus quarterly. DE ist MATE. Hardware ist ein Lenovo X220.

Diese Anwendungen crashen den X Server: Firefox, Chromium, Seamonkey, XSane, VLC, LibreOffice
Diese laufen einwandfrei: Evolution, der ganze Desktop (MATE), MPlayer, GIMP, Emacs, PDF Viewer, FileZilla, Bildbetrachter

Ohne Browser und Office ist das FreeBSD momentan nicht brauchbar.

Leider habe ich überhaupt keinen Plan was die Anwendungen die den Crash verursachen gemeinsam haben. Ich weiß auch nicht wie ich herausfinden soll woran es liegt, die Logs sind nicht hilfreich. Irgendwelche Tipps?

Robert
 
Hallo Robert,
ich habe da keine negativen Erfahrungen zu berichten. Nutze FreeBSD 12.0-p3, XFCE, Firefox 66.0.2 und Thunderbird 60.6.1. Ach, mein Laptop ist ein Lenovo W500...
VG Norbert
 
Da könnte man in verschiedene Richtungen suchen ...

Wird der Speicher knapp? Also sowohl RAM als auch, falls vorhanden, swap? Dann wird als letzter Ausweg ein "fetter" Prozess gekillt. ZFS kann sehr viel RAM beanspruchen -- auf meinen Clients mit eher wenig RAM habe ich die ARC Größe per sysctl beschränkt, damit sie stabil laufen.

Sind alle Ports in einem konsistenten Zustand? Eventuell hilft ein kompletter Rebuild.

Gibt es Probleme mit direct rendering? Vielleicht mal testen, ob das Problem verschwindet, wenn kein kms Treiber geladen ist?
 
Gibt es Probleme mit direct rendering? Vielleicht mal testen, ob das Problem verschwindet, wenn kein kms Treiber geladen ist?
Danke, das war der entscheidende Tip ;)

Habe i915kms aus der kldlist="" in der rc.conf entfernt, dann war die Auflösung zwar falsch aber alle Anwendungen liefen wenigstens wieder.

Da war doch mal was mit drm, drm2 usw. und Modulen in /boot/modules/ statt in /boot/kernel und so... Das Verzeichnis /boot/modules war aber leer, also hab' ich das Paket drm-fbsd12.0-kmod installiert, und dann das Modul /boot/modules/i915kms.ko in rc.conf geladen, jetzt funktioniert es wieder.

Keine Ahnung was da passiert war, das Notebook lief bis zum letzten pkg upgrade einwandfrei und ich dachte die drm Geschichte wäre schon umgestellt gewesen...

Na ja, egal. Danke nochmal!

Grüße,

Robert
 
Da war doch mal was mit drm, drm2 usw. und Modulen in /boot/modules/ statt in /boot/kernel und so...
Ja, da gibt es gerade die unschöne Situation, dass DRM Treiber inzwischen separat entwicket und als Port bereitgestellt werden (die werden nach /boot/modules installiert wie alle Module, die nicht zum Kernel gehören), die alten deprecated Versionen im Kernel aber noch da sind. Die werden im nächsten Release endlich verschwinden. Ich baue alles selbst auf meinem Server und habe da den Kernel Build so konfiguriert, dass DRM und DRM2 deakiviert sind, um genau das zu vermeiden, dass ich irgendwo aus Versehen eine uralt-Version lade :)
 
die alten deprecated Versionen im Kernel aber noch da sind
Weil man den Schreikindern, für das Entfernen der alten Module ein mindestens dreifacher Weltuntergang war, ja wieder nachgeben musste. Das ist ein zumindest mich zunehmend nervendes Pattern bei FreeBSD, bei FCP-101 (Entfernen alter 10 und 100 MBit/s NIC-Treiber) wiederholt es sich auch gerade. Weil eine kleine, aber sehr laute Gruppe ihre Migrationsprozesse nicht im Griff hat, lässt man die breite Masse leiden.
 
Ja, da gibt es gerade die unschöne Situation, dass DRM Treiber inzwischen separat entwicket und als Port bereitgestellt werden (die werden nach /boot/modules installiert wie alle Module, die nicht zum Kernel gehören), die alten deprecated Versionen im Kernel aber noch da sind.

Frage dazu, wo wird denn ein Modul zuerst gesucht wenn es ohne Pfad in der rc.conf angegeben wird? In /boot/modules, oder in /boot/kernel?
 
In letzterem. Ich bin mir nicht ganz sicher, glaube aber, dass /boot/modules überhaupt nicht im Suchpfad für Module ist.
 
glaube aber, dass /boot/modules überhaupt nicht im Suchpfad für Module ist.
Warum glauben, wenn man alles nachsehen kann?
/etc/rc.d/kld nutzt die Funktion load_kld aus /etc/rc.subr, diese nutzt kldload(8).
In der Manpage dazu steht:

If a bare filename is requested it will only be loaded if it is found within the module path as defined by the sysctl kern.module_path.

Code:
# sysctl kern.module_path
kern.module_path: /boot/kernel;/boot/modules;/boot/dtb;/boot/dtb/overlays

QED.

Rob
 
Zurück
Oben