OpenBSD 72: Rätselhaftes Verhalten

berni51

berni51

Open-Net-FreeBSD user
Ist ja nicht meine erste OpenBSD-Installation, und aktuell hab ich hier 5 Maschinen mit OpenBSD 7.2: X86_64 und arm64. Alle gewohnt robust und problemlos - bis auf eine!

EIn Rechner mit Asus A2F85-M Board und AMD A10 mit GPU, 32 GB RAM und 5 SSDs. Drei der SSD sind für OpenBSD: 512 GB (mSata) fürs System, 512 (nvme) für /home und 512 (nvme) für /var/www. Auf den anderen beiden SSD läuft ein Devuan Chimaera Linux.

Probleme macht auf dieser Hardware nur OpenBSD, das Linux läuft einwandfrei und völlig problemlos. Es sind eigentlich zwei Probleme, von denen ich nicht sicher bin, ob sie zusammenhängen:

1. OpenBSD kann stunden, sogar tagelang laufen, ohne irgendwelche Mucken. Es kann aber auch vorkommen, dass der Rechner in völlig unregelmässigen Abständen hängen bleibt. Dann leuchtet die HD-LED dauerhaft und die Maschine reagiert auf nichts. Dieser Zustand kann zwischen 2 und 30 Sekunden anhalten, danach läuft alles wieder normal weiter - bis zur nächsten Kunstpause. Die Pause sind unabhängig von der Anwendung und passieren im Browser, mit Abiword, mit Gnumeric oder auch auf der Console im MidnightCommander - also sie können eigentlich überall und jederzeit auftreten.

Gemacht habe ich bisher folgendes:
1a.
RAM Dauertest über Nacht, keine Fehler

1b.
smartctl auf die System-SSD losgelassen, bis jetzt rund 20 mal je 30 Minuten: No errors. Die nvme SSD kann smartctl anscheinend nicht ordentlich testen.

1c.
Die beiden nvme SSD umounted und aus dem Board entfernt. Keine Änderung

1d.
Alle Kabel an allen SSD überprüft und getauscht, keine Änderung.

1e.
In allen Logs nach Hinweisen gesucht - nix.


2. Firefox stürzt sporadisch ab, aber nie direkt nach Auftreten von Fehler 1, ab und zu aber ein paar Minuten danach. Aber wirklich reproduzieren konnte ich das nicht.

Immerhin führt der Absturz zu einem Eintrag in .xsession_errors. Hab mal einen Auszug angehängt.
Auffällig erscheint mir, dass die Meldung

Code: 
libEGL warning: failed to open /dev/dri/card0: Permission denied

libEGL warning: DRI2: could not open /dev/dri/card0 (Permission denied)
ATTENTION: default value of option mesa_glthread overridden by environment.
out of memory: 0x0000000000002000 bytes requested
Exiting due to channel error.

mehrfach erscheint, bis es dann zum richtigen Absturz von Firefox führt. Dann kommt diese Meldung:

Code: 
libEGL warning: failed to open /dev/dri/card0: Permission denied

libEGL warning: DRI2: could not open /dev/dri/card0 (Permission denied)
ATTENTION: default value of option mesa_glthread overridden by environment.
out of memory: 0x0000000000002000 bytes requested
Exiting due to channel error.
Crash Annotation GraphicsCriticalError: |[C0][GFX1-]: Receive IPC close with reason=AbnormalShutdown (t=0.379494) [GFX1-]: Receive IPC close with reason=AbnormalShutdown
Crash Annotation GraphicsCriticalError: |[C0][GFX1-]: Receive IPC close with reason=AbnormalShutdown (t=7903.16) [GFX1-]: Receive IPC close with reason=AbnormalShutdown
Exiting due to channel error.
Exiting due to channel error.
Crash Annotation GraphicsCriticalError: |[C0][GFX1-]: Receive IPC close with reason=AbnormalShutdown (t=1290.07) [GFX1-]: Receive IPC close with reason=AbnormalShutdown
Exiting due to channel error.
Exiting due to channel error.
Crash Annotation GraphicsCriticalError: |[C0][GFX1-]: Receive IPC close with reason=AbnormalShutdown (t=7565.97) [GFX1-]: Receive IPC close with reason=AbnormalShutdown
Exiting due to channel error.
Crash Annotation GraphicsCriticalError: |[C0][GFX1-]: Receive IPC close with reason=AbnormalShutdown (t=26.6274) [GFX1-]: Receive IPC close with reason=AbnormalShutdown
Exiting due to channel error.
Crash Annotation GraphicsCriticalError: |[C0][GFX1-]: Receive IPC close with reason=AbnormalShutdown (t=27.0313) [GFX1-]: Receive IPC close with reason=AbnormalShutdown
Exiting due to channel error.
Crash Annotation GraphicsCriticalError: |[C0][GFX1-]: Receive IPC close with reason=AbnormalShutdown (t=26.7873) [GFX1-]: Receive IPC close with reason=AbnormalShutdown
Exiting due to channel error.

Diese Firefox-Abstürze kommen für mich wie aus heiterem Himmel - einfach zack, Fenster weg. Ähnliches ist auch mit Google möglich, aber wesentlich seltener. Wobei ja auch die Firefox Crashes nicht am laufenden Band vorkommen, manchmal ist tagelang Ruhe.

Irgendeine Idee? Ich hab gerade keine mehr, ausser alles (SSDs, RAM, Board) austauschen. Würd es aber lieber systematisch angehen.

Ach ja: Von diesen Asus A2F85-Boards laufen hier noch etliche in unterschiedlichen Varianten, aber alle mit der gleichen BIOS-Firmware hochgerüstet, teils auch mit OpenBSD. Keines davon macht diese Zicken.

Bin ein bisschen ratlos.

Berni
 
berni51 schrieb:
Immerhin führt der Absturz zu einem Eintrag in .xsession_errors. Hab mal einen Auszug angehängt.
Auffällig erscheint mir, dass die Meldung

Code: 
libEGL warning: failed to open /dev/dri/card0: Permission denied

libEGL warning: DRI2: could not open /dev/dri/card0 (Permission denied)
ATTENTION: default value of option mesa_glthread overridden by environment.
out of memory: 0x0000000000002000 bytes requested
Exiting due to channel error.

mehrfach erscheint, bis es dann zum richtigen Absturz von Firefox führt.
Zum Vergrößern anklicken....
Wenn Du die xorg.conf ergänzen kannst, für den zuständigen Treiber mit ' Option "DRI2" "no" ', dann teste mal damit.

EDIT:

Wenn Du damit kein Erfolg hast, dann teste mal temporär auch mit z. B.:
Code: 
.xsession-errors -> /dev/null
und mit:
Code: 
swap /home/<user>/.cache mfs rw,nodev,nosuid,-s=300m 0 0
 
Zuletzt bearbeitet:
out of memory: 0x0000000000002000 bytes requested
Zum Vergrößern anklicken....
Bei sowas würde ich immer mal den dedicated RAM auf manuell setzen und gönnerhaft 1GB+ zuweisen oder in den anderen BIOSen die settings vergleichen.
Fährst du evtl. eine höhere Auflösung oder hast mehr Monitore dran als bei den anderen? Sind die unterschiedlich angeschlossen DVI, HDMI...?
 
Die RAM-Zuteilung lass ich immer automatisch laufen, bei allen Boards Und alle laufen in FullHD, allerdings an unterschiedlichen Anschlüssen. Der Problemrechner machts über DVI.

@morromett : Was meinst Du mit
Code: 
.xsession-errors -> /dev/null
?
 
Das klappt leider nicht, womöglich ist das Board schon zu alt:

Code: 
Status: Could not create a WebGL context, VENDOR = 0xffff, DEVICE = 0xffff, Sandboxed = no, Optimus = no, AMD switchable = no, Reset notification strategy = 0x0000, ErrorMessage = OffscreenContext Creation failed, GpuChannelHost creation failed.
 
Ich glaube ich hatte das Board sogar mal und das hatte "bei mir" unter Windows 8 und 10 auch rumgezickt ... ist das son älteres aus frühen 2010ern?
 
Mit der Firefox-internen Webseite "about:support" zwischen Linux und OpenBSD vergleichen, wieso die hardwarebeschleunigte 3D-Grafikausgabe unter OpenBSD nicht funktioniert. Ich vermute eine Fehlkonfiguration im Bereich von Mesa 3D.

EGL wird ja offenbar unterstützt und vom Webbrowser Firefox verwendet? => Zeile "WebGL-1-Treiber: WSI Info" und Zeile "WebGL-2-Treiber: WSI Info" der Firefox-internen Webseite "about:support" müssen EGL-Einträge enthalten!

Funktioniert der klassiche OpenGL-Test für den Desktoprechner:
Code: 
# glxgears -info
Running synchronized to the vertical refresh.  The framerate should be
approximately the same as the monitor refresh rate.
GL_RENDERER   = Mesa DRI Intel(R) HD Graphics 620 (KBL GT2)
GL_VERSION    = 3.0 Mesa 21.2.4
GL_VENDOR     = Intel Open Source Technology Center
GL_EXTENSIONS = <Riesenliste an Erweiterungen>
298 frames in 5.0 seconds = 59.501 FPS
298 frames in 5.0 seconds = 59.525 FPS
300 frames in 5.0 seconds = 59.940 FPS
294 frames in 5.0 seconds = 58.768 FPS
299 frames in 5.0 seconds = 59.555 FPS
 
Zuletzt bearbeitet von einem Moderator:
Wenn der User in der Gruppe "staff" ist, sollten die limits ok sein. Ansonsten den User in die Gruppe "staff" aufnehmen.

Es gibt einige Einstellungen unter Firefox (about:config), die ich mir "damals" mal notiert habe. Ich weiss allerdings nicht, ob die noch notwendig oder aktuell sind:

Firefox Beschleunigung und Webrenderer:

layers.acceleration.force-enable = true
gfx.webrender.all = true

Den JIT-compiler zu deaktivieren hat damals einen guten Geschwindigkeitsgewinn gebracht, wenn man kein WASM usw. benoetigt:

javascript.options.baselinejit = false
javascript.options.ion = false
javascript.options.wasm = false
javascript.options.asmjs = false
 
Ohne Erfahrungen in dem Bereich, aber kann es sein, dass die SSD vielleicht intern irgendwelche Aufraeumarbeiten macht? Meines Wissens hat OpenBSD ja kein Trim implementiert. Vielleicht ist das die Ursache. Bei Linux duerfte ja automatisch mal ein Trim laufen. Ist aber mehr anhand der Beschreibung eine Vermutung bzw. Idee, die ich da hatte. Ich wuesste da auch nicht so wirklich, wie man das verifizieren koennte.

Bei den SSDs, die ich im Einsatz habe, hab ich sowas noch nicht beobachtet. Das sind aber auch keine NVME SSDs.
 
@CommanderZed : Hier laufen noch etliche Boards aus der A2F85-Reihe, alle eigentlicg ganz ordentlich. Bis auf dieses eine. Klar, die sind alle schon zwischen 7 und 9 Jahre als, das besagte Board ist von 2014.

@GrandDixence : Die glx-tools laufen durch, die Ergebnisse sind ähnlich wie bei dir:
Code: 
berni@tc58:~$ glxgears -info
Running synchronized to the vertical refresh.  The framerate should be
approximately the same as the monitor refresh rate.
GL_RENDERER   = AMD ARUBA (DRM 2.50.0 / 6.0.0-0.deb11.6-amd64, LLVM 11.0.1)
GL_VERSION    = 3.1 Mesa 20.3.5
GL_VENDOR     = X.Org


317 frames in 5.0 seconds = 63.378 FPS
301 frames in 5.0 seconds = 59.998 FPS
301 frames in 5.0 seconds = 60.001 FPS
300 frames in 5.0 seconds = 60.000 FPS
300 frames in 5.0 seconds = 59.999 FPS
300 frames in 5.0 seconds = 59.999 FPS
300 frames in 5.0 seconds = 59.999 FPS
301 frames in 5.0 seconds = 60.000 FPS
300 frames in 5.0 seconds = 60.000 FPS
301 frames in 5.0 seconds = 60.000 FPS
300 frames in 5.0 seconds = 60.000 FPS
301 frames in 5.0 seconds = 60.000 FPS
300 frames in 5.0 seconds = 59.999 FPS
300 frames in 5.0 seconds = 59.999 FPS

@midnight : Ich weiss nicht, ob ob ich mich am Firefox festbeissen sollte. Die Hänger können ja überall auftreten, sogar auf der Console. Beim Firefox kommts natürlich öfter vor, weil der häufig benutzt wird. Vielleicht hängen ja auch die Aussetzer und die Abstürze überhaupt nicht zusammen - man weiss es nicht.

@xbit : Ja, gut möglich. Leider hab ich noch keine Idee, wie ich das testen kann. Die smartmontools finden ja nichts, und die hab ich schon zig Stunden laufen lassen. Immer alles zu 100% OK. Wobei die allerdings nicht an die nvme's rankommen.

Die bisherigen Tipps hab ich mittlerweile alle durch, aber ohne Erfolg. Bleibt fast nur noch der Austausch von Board und SSD. Hab schon mal ins Regal gegriffen.
 
berni51 schrieb:
Hier laufen noch etliche Boards aus der A2F85-Reihe, alle eigentlicg ganz ordentlich. Bis auf dieses eine. Klar, die sind alle schon zwischen 7 und 9 Jahre als, das besagte Board ist von 2014.
Zum Vergrößern anklicken....

War nur son Gedanke, sollte keine generelle Kritik sein und ist ja auch noch um Jahre moderner als das was der ein-oder-andere user hier so vorstellt ;)

Letztlich war das in meinem damaligen "Fernseh" PC - aber ich bin noch mal in mich gegangen, ich glaube auf der Arbeit hatten wir auch einige (50? 75?) PCs damit, diese APUS waren damals echt nen ganz guter Deal für Büro-PCs gegenüber ähnlich teuren i3 fand ich. Ich bin mir aber nicht zu 100% sicher ob es das Mainboard war - die liefen eigentlich unauffällig.

Neben Board und SSDs kann man natürlich auch immer die üblichen verdächten (Netzteil etc) nicht komplett ausschließen für die dubiosesten Feehler.
 
Bei unerklärlichen Problemen ist es auch immer ein sehr guter Tipp sich einmal die Stromversorgung anzuschauen. Sterbende Netzteile können die abartigsten Nebenwirkungen haben und die treten tatsächlich meist nicht mal unter Volllast auf.
 
Ich frage mich auch, ob die PCIe-Karte hier nicht irgendwie Ungewolltes macht. Ich kenne das Board bzw. die Baureihe, da gibts keinen Slot für NVMe onboard und die x16-Slots erwarten eigentlich eine GPU, da consumer board. Je nach settings UEFI ja/nein wirkt sich das auch auf die Karten und Speichergeräte aus bzw. werden nach Umstellen und erneutem Betreten vom BIOS diesbezüglich weitere Settings freigeschaltet. Ich hatte mal eine weitere NIC-Karte gesteckt, damit kam kein Bild via onboard-Ausgang. Das klappte erst, nachdem ich die Option multiGPU (aus der Erinnerung sollte es so heißen) aktivierte.
Haben deine anderen Boards auch diese Karte? Ist die Firmware der Karte aktuell? Höchst seltsam natürlich, dass es bei dir mit anderen Betriebssystem einfach läuft.
 
Board, SSD und Netzteil liegen schon bereit. Die übrigen Boards der gleichen Reihe laufen alle ausnahmslos ebenfalls mit nvme's, teilweise bis zu drei Stück. Die Firmware ist überalll die letzt-mögliche.
Was mir noch auffällt: Unter OpenBSD ist die Schrift auf der Console ein klein wenig anders als sonst. Nicht schlechter, fransig oder blass, einfach einen Tick anders.
Bis auf die PCIe-Karten stecken übrigens keine weiteren Karten im Board.
 
Die abgebildete Ausgabe von glxgears ist von Linux. Unter Linux funktioniert offenbar die hardwarebeschleunigte 3D-Grafikausgabe mit dieser Grafikkarte.

Hier sollte die glxgears-Ausgabe von Linux mit der von OpenBSD verglichen werden. Die abgebildeten Fehlermeldungen und der WebGL-Aquariumtest deuten klar auf einen Fehler unter OpenBSD im Bereich der hardwarebeschleunigten 3D-Grafikausgabe hin. Dem Firefox wurde ja sogar (mitten im Betrieb?) der Stecker der direkten Kommunikation (DRI) mit der Grafikkarte gezogen!

Es sollte klar sein, dass heute (praktisch) jede grafische Bedienoberfläche und deren GUI-Anwendungen mehr oder weniger Gebrauch von hardwarebeschleunigter 3D-Grafikausgabe machen. Unter Wayland wird ausschliesslich 3D verwendet. Bei X11/X.org kann noch ein (hoffentlich verschwindend kleiner) Anteil 2D sein.

Funktioniert die hardwarebeschleunigte 3D-Grafikkarte instabil oder gar nicht, kann man das Betriebssystem des Desktoprechners in eine virtuelle Maschine à la "VMware Workstation" verbannen, da ansonsten defakto unbrauchbar.
 
Ja, das war Linux. Konnnte erst jetzt neu booten und das ganze unter OpenBSD wiederholen. Das sieht schon deutlich unerfreulicher aus:

Code: 
[berni@tc58 ~] $ glxgears -info
libGL error: MESA-LOADER: failed to retrieve device information
libGL error: image driver extension not found
libGL error: failed to load driver: radeon
libGL error: failed to open /dev/dri/card0: Permission denied
libGL error: failed to open /dev/dri/card0: Permission denied
libGL error: failed to load driver: r600
GL_RENDERER   = llvmpipe (LLVM 13.0.0, 256 bits)
GL_VERSION    = 4.5 (Compatibility Profile) Mesa 22.1.7
GL_VENDOR     = Mesa/X.org
VisualID 1288, 0x508
1634 frames in 5.0 seconds = 326.693 FPS
1811 frames in 5.0 seconds = 362.079 FPS
1843 frames in 5.0 seconds = 368.482 FPS
1829 frames in 5.0 seconds = 365.790 FPS
1847 frames in 5.0 seconds = 369.387 FPS
1808 frames in 5.0 seconds = 361.429 FPS
1857 frames in 5.0 seconds = 371.308 FPS
1860 frames in 5.0 seconds = 371.917 FPS
1852 frames in 5.0 seconds = 370.222 FPS
1856 frames in 5.0 seconds = 371.170 FPS
1864 frames in 5.0 seconds = 372.740 FPS
1855 frames in 5.0 seconds = 370.874 FPS
1134 frames in 134.8 seconds =  8.415 FPS
1824 frames in 5.0 seconds = 364.620 FPS
1844 frames in 5.0 seconds = 368.708 FPS
1844 frames in 5.0 seconds = 368.621 FPS
1860 frames in 5.0 seconds = 371.848 FPS
1837 frames in 5.0 seconds = 367.360 FPS
1841 frames in 5.0 seconds = 368.114 FPS
1857 frames in 5.0 seconds = 371.274 FPS
1829 frames in 5.0 seconds = 365.677 FPS
1606 frames in 5.0 seconds = 321.013 FPS
1429 frames in 5.0 seconds = 285.605 FPS
1672 frames in 5.0 seconds = 334.329 FPS
1538 frames in 5.0 seconds = 307.302 FPS
1577 frames in 5.0 seconds = 315.288 FPS
1818 frames in 5.0 seconds = 363.583 FPS
1665 frames in 5.0 seconds = 332.910 FPS
1823 frames in 5.0 seconds = 364.561 FPS
1821 frames in 5.0 seconds = 364.087 FPS
1827 frames in 5.0 seconds = 365.314 FPS
1819 frames in 5.0 seconds = 363.787 FPS
1815 frames in 5.0 seconds = 362.918 FPS
1719 frames in 5.0 seconds = 343.742 FPS
1563 frames in 5.0 seconds = 312.557 FPS
1363 frames in 5.0 seconds = 272.592 FPS
1836 frames in 5.0 seconds = 367.173 FPS
1847 frames in 5.0 seconds = 369.394 FPS
1435 frames in 5.0 seconds = 286.892 FPS
1143 frames in 5.0 seconds = 228.479 FPS

Könnte ich hier ein MESA-Problem haben?
 
Und gleich noch eins hinterher, diesmal als root:

Code: 
[root@tc58 ~] # glxgears -info
Running synchronized to the vertical refresh.  The framerate should be
approximately the same as the monitor refresh rate.
GL_RENDERER   = AMD ARUBA (DRM 2.50.0 / 7.2, LLVM 13.0.0)
GL_VERSION    = 3.1 Mesa 22.1.7
GL_VENDOR     = X.Org

VisualID 1288, 0x508
373 frames in 5.0 seconds = 74.459 FPS
301 frames in 5.0 seconds = 59.999 FPS
300 frames in 5.0 seconds = 60.000 FPS
301 frames in 5.0 seconds = 60.003 FPS
300 frames in 5.0 seconds = 59.997 FPS
301 frames in 5.0 seconds = 60.003 FPS
301 frames in 5.0 seconds = 59.999 FPS
300 frames in 5.0 seconds = 60.000 FPS
301 frames in 5.0 seconds = 59.999 FPS
301 frames in 5.0 seconds = 60.002 FPS
301 frames in 5.0 seconds = 60.000 FPS
300 frames in 5.0 seconds = 59.999 FPS
301 frames in 5.0 seconds = 59.995 FPS
301 frames in 5.0 seconds = 60.006 FPS
301 frames in 5.0 seconds = 59.998 FPS
301 frames in 5.0 seconds = 60.002 FPS
300 frames in 5.0 seconds = 60.000 FPS
300 frames in 5.0 seconds = 60.000 FPS
301 frames in 5.0 seconds = 60.002 FPS
301 frames in 5.0 seconds = 59.999 FPS
301 frames in 5.0 seconds = 60.000 FPS
300 frames in 5.0 seconds = 60.000 FPS
301 frames in 5.0 seconds = 60.002 FPS
301 frames in 5.0 seconds = 60.000 FPS

Sollte sich das Problem etwa als simpler permission-Fehler herausstellen?
 
Schocking!!! Ich glaube, mein wm war Schuld, also der fluxbox. Werd ich über Nacht versuchen zu verifizieren. :eek:
 
Mein Problem scheint gelöst - und es war nicht der Fluxbox. Angeregt durch eure Hinweise auf die Grafik und die möglichen Tests dazu (Web-Aquarium, glxgears) und die sonderbaren Reaktionen meiner Grafik darauf hab ich in dieser Richtung weiter recherchiert. Und bei reddit gab es tatsächlich eine Beitrag dazu.
Die Lösung: Etwa vor 2 Jahren hat OpenBSD die device nodes für die Grafik geändert von /dev/drm0 auf /dev/dri/card0. Alle dafür releveanten Änderungen hätten bei einem Upgrade angepasst werden sollen - und das hat wohl nicht immer korrekt funktioniert. Der xenodm beispielsweise hätte die Dateiattribute von /dev/dri/card0 auf den Benutzer von Xorg beim Start ändern müssen. Hat er aber nicht.
Bei mir hat heut nacht ein enfaches sysmerge gereicht, das in Ordnung zu bringen. Seitdem sieht die Ausgabe von glxgears - info auch vernünftig aus:
Code: 
[berni@tc58 ~] $ glxgears -info
Running synchronized to the vertical refresh.  The framerate should be
approximately the same as the monitor refresh rate.
GL_RENDERER   = AMD ARUBA (DRM 2.50.0 / 7.2, LLVM 13.0.0)
GL_VERSION    = 3.1 Mesa 22.1.7
GL_VENDOR     = X.Org
VisualID 1288, 0x508
306 frames in 5.0 seconds = 61.149 FPS
301 frames in 5.0 seconds = 60.003 FPS
301 frames in 5.0 seconds = 59.998 FPS
301 frames in 5.0 seconds = 59.999 FPS
301 frames in 5.0 seconds = 60.003 FPS
301 frames in 5.0 seconds = 59.998 FPS
301 frames in 5.0 seconds = 60.000 FPS
300 frames in 5.0 seconds = 60.000 FPS
301 frames in 5.0 seconds = 60.002 FPS
301 frames in 5.0 seconds = 59.998 FPS
301 frames in 5.0 seconds = 60.000 FPS
301 frames in 5.0 seconds = 60.001 FPS
301 frames in 5.0 seconds = 59.999 FPS
301 frames in 5.0 seconds = 60.000 FPS
Seitdem läuft auch das Web-Aquarium und bislang gab es weder die Hänger noch Abstürze von Firefox.

Das hätte ich ohne diese Diskussion und eure Beiträge so schnell wohl nicht herausgefunden. Mein Dank ist euch gewiss!

Gut gelaunt
Berni
 

Anhänge

  • Download.webp
    Download.webp
    102,2 KB · Aufrufe: 90
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben