Nach freebsd-update Grafikprobleme

[Andy_m4]

auch auf dem Holzweg, oder?

Mag sein. Es ist ja auch nur eine Vermutung, das die Probleme am Grafiktreiber liegt. Wenn auch eine Plausible.
Und da man sich eh drum kümmern muss, kann man es ja auch machen und dann gucken, ob es das Problem fixt.

Eigentlich braucht auch X keinen drm

Nicht zwingend. Aber dann bist Du bestenfalls in irgendeinem VESA-Mode und viele Möglichkeiten der Grafikkarte liegen brach.
Es gibt dann zwar noch die Xorg-eigenen Grafiktreiber, aber zumindest für neuere Grafik-Hardware werden die ja nicht mehr gepflegt.

Hmm. den Treiber kompilieren scheint bis jetzt keine Auswirkungen auf das System zu haben.

Es wäre echt schön, wenn wir mal die oben dargelegten Schritte durchgehen würden, anstatt das hier zusammenhangslos irgendwelche Dinge gepostet werden.
Ich weiß nicht mal, ob Du die gemacht hast oder nur ein Teil davon oder was auch immer.

[drm] Initialized i915 1.6.0 20201103 for drmn0 on minor 0

sieht erst mal gut aus.
Mit ls -ahl /dev/dr* sollte auch das entsprechende Device im /dev-Verzeichnis zu sehen sein.

den Treiber kompilieren scheint bis jetzt keine Auswirkungen auf das System zu haben.

Was heißt das denn konkret? Hast Du immer noch das selbe Problem wie im Ausgangsposting beschrieben?

 

[Tatzahn]

@Andy_m4 ganz konkret bin ich alle deine Punkte durchgegangen bis zu dem Punkt
#pkg install gpu-firmware-intel-kmod
weil da die erste Fehlermeldung kam

danach
# kldload i915kms
kldload: can't load i915kms: module already loaded or in kernel

als nächstes

tail -n 50 /var/log/messages
Dec 29 18:00:33 freebsdt420 kernel: fbd0: not attached to vt(4) console; another device has precedence (err=17)
Dec 29 18:00:33 freebsdt420 kernel: ichsmb0: <Intel Cougar Point SMBus controller> port 0xefa0-0xefbf mem 0xf2524000-0xf25240ff irq 18 at device 31.3 on pci0
Dec 29 18:00:33 freebsdt420 kernel: smbus0: <System Management Bus> on ichsmb0
Dec 29 18:00:33 freebsdt420 kernel: acpi_wmi0: <ACPI-WMI mapping> on acpi0
Dec 29 18:00:33 freebsdt420 kernel: acpi_wmi0: Embedded MOF found
Dec 29 18:00:33 freebsdt420 kernel: ACPI: \_SB.WMI1.WQBA: 1 arguments were passed to a non-method ACPI object (Buffer) (20221020/nsarguments-361)
Dec 29 18:00:33 freebsdt420 kernel: acpi_wmi1: <ACPI-WMI mapping> on acpi0
Dec 29 18:00:33 freebsdt420 kernel: acpi_wmi1: Embedded MOF found
Dec 29 18:00:33 freebsdt420 kernel: ACPI: \_SB.WMI2.WQBB: 1 arguments were passed to a non-method ACPI object (Buffer) (20221020/nsarguments-361)
Dec 29 18:00:33 freebsdt420 kernel: wlan0: Ethernet address: 08:11:96:26:40:6c
Dec 29 18:00:33 freebsdt420 kernel: lo0: link state changed to UP
Dec 29 18:00:33 freebsdt420 kernel: iwn0: iwn_read_firmware: ucode rev=0x12a80601
Dec 29 18:00:33 freebsdt420 kernel: wlan0: link state changed to UP
Dec 29 18:00:33 freebsdt420 kernel: umodem0 on uhub3
Dec 29 18:00:33 freebsdt420 kernel: umodem0: <Lenovo F5521gw, class 2/0, rev 2.00/0.00, addr 3> on usbus1
Dec 29 18:00:33 freebsdt420 kernel: umodem0: data interface 2, has CM over data, has break
Dec 29 18:00:33 freebsdt420 kernel: umodem1 on uhub3
Dec 29 18:00:33 freebsdt420 kernel: umodem1: <Lenovo F5521gw, class 2/0, rev 2.00/0.00, addr 3> on usbus1
Dec 29 18:00:33 freebsdt420 kernel: umodem1: data interface 4, has CM over data, has break
Dec 29 18:00:33 freebsdt420 kernel: umodem2 on uhub3
Dec 29 18:00:33 freebsdt420 kernel: umodem2: <Lenovo F5521gw, class 2/0, rev 2.00/0.00, addr 3> on usbus1
Dec 29 18:00:33 freebsdt420 kernel: umodem2: data interface 10, has CM over data, has break
Dec 29 18:00:33 freebsdt420 kernel: cdce0 on uhub3
Dec 29 18:00:33 freebsdt420 kernel: cdce0: <Lenovo F5521gw, class 2/0, rev 2.00/0.00, addr 3> on usbus1
Dec 29 18:00:33 freebsdt420 kernel: ue0: <USB Ethernet> on cdce0
Dec 29 18:00:33 freebsdt420 kernel: ue0: Ethernet address: 02:80:37:ec:02:00
Dec 29 18:00:33 freebsdt420 ntpd[1391]: ntpd 4.2.8p18-a (1): Starting
Dec 29 18:00:33 freebsdt420 kernel: Security policy loaded: MAC/ntpd (mac_ntpd)
Dec 29 18:00:33 freebsdt420 ntpd[1391]: Command line: /usr/sbin/ntpd -p /var/db/ntp/ntpd.pid -c /etc/ntp.conf -f /var/db/ntp/ntpd.drift
Dec 29 18:00:33 freebsdt420 ntpd[1391]: ----------------------------------------------------
Dec 29 18:00:33 freebsdt420 ntpd[1391]: ntp-4 is maintained by Network Time Foundation,
Dec 29 18:00:33 freebsdt420 ntpd[1391]: Inc. (NTF), a non-profit 501(c)(3) public-benefit
Dec 29 18:00:33 freebsdt420 ntpd[1391]: corporation. Support and training for ntp-4 are
Dec 29 18:00:33 freebsdt420 ntpd[1391]: available at https://www.nwtime.org/support
Dec 29 18:00:33 freebsdt420 ntpd[1391]: ----------------------------------------------------
Dec 29 18:00:33 freebsdt420 ntpd[1392]: leapsecond file ('/var/db/ntpd.leap-seconds.list'): good hash signature
Dec 29 18:00:33 freebsdt420 ntpd[1392]: leapsecond file ('/var/db/ntpd.leap-seconds.list'): loaded, expire=2025-06-28T00:00:00Z last=2017-01-01T00:00:00Z ofs=37
Dec 29 18:00:34 freebsdt420 kernel: .
Dec 29 18:01:25 freebsdt420 su[1589]: pepe to root on /dev/pts/0
Dec 29 18:01:57 freebsdt420 devd[1117]: check_clients: dropping disconnected client
Dec 29 18:05:28 freebsdt420 wpa_supplicant[380]: wlan0: RSN: Group rekeying completed with 7c:ff:4d:b5:2c:d8 [GTK=CCMP]
Dec 29 18:15:28 freebsdt420 syslogd: last message repeated 1 times
Dec 29 18:25:28 freebsdt420 syslogd: last message repeated 1 times
Dec 29 18:35:28 freebsdt420 syslogd: last message repeated 1 times
Dec 29 18:45:28 freebsdt420 syslogd: last message repeated 1 times
Dec 29 18:55:28 freebsdt420 syslogd: last message repeated 1 times
Dec 29 19:05:28 freebsdt420 syslogd: last message repeated 1 times
Dec 29 19:15:28 freebsdt420 syslogd: last message repeated 1 times
Dec 29 19:25:28 freebsdt420 syslogd: last message repeated 1 times
Dec 29 19:35:28 freebsdt420 syslogd: last message repeated 1 times

Und ja das Fehlerbild ist exakt noch vorhanden

 

[Tatzahn]

unter /var/log/Xorg.0.log hab ich noch das hier gefunden:
[ 44.808] (II) LoadModule: "intel"
[ 44.809] (WW) Warning, couldn't open module intel
[ 44.809] (EE) Failed to load module "intel" (module does not exist, 0)

 

[Andy_m4]

ganz konkret bin ich alle deine Punkte durchgegangen bis zu dem Punkt

Danke für die Info.

weil da die erste Fehlermeldung kam

Ja ok. Jedenfalls die Firmware scheint ja da zu sein. Da musst Du Dir also erst mal keine Sorgen drum machen.

kldload: can't load i915kms: module already loaded or in kernel

Der Treiber ist also geladen.

unter /var/log/Xorg.0.log hab ich noch das hier gefunden

In Deinem Home-Verzeichnis liegt nicht noch irgendwo ein Xorg-Log herum? Ich meine nämlich, wenn man über startx geht, das er das dann im Home-Verzeichnis ablegt.

[ 44.808] (II) LoadModule: "intel"

Soweit ich weiß, ist der intel-Treiber bei Xorg der Xorg-eigene Treiber (wird eigentlich nur noch benutzt für ältere Intel-GPUs).
Normalerweise (sofern nicht anders konfiguriert) probiert Xorg mehrere Sachen durch, bis er ein funktionierendes Grafiksetup gefunden hat. Daher findet man Fehler im Log, selbst wenn es funktioniert.
Ich würde mal im Log nach
/dev/dr
suchen. Alles was rund darum auftaucht, könnte für Dein Problem interessant sein.
Unglücklicherweise hab ich jetzt kein Gerät mit Intel-GPU und FreeBSD 14.2 zur Hand, damit ich schnell mal nachgucken könnte, wie es normalerweise aussehen müsste.

Im Augenblick weiß ich auch nicht so recht weiter. Denn deine Setup hat ja unter einer früheren FreeBSD-Version schon funktioniert, was ja die Vermutung nahe liegt das da alles in Ordnung ist und es nur am Treiber liegt.
Man könnte auch noch mal eine ältere Treiberversion versuchen. Die unter /usr/ports/graphics/drm-515-kmod (oder gar /usr/ports/graphics/drm-510-kmod ; wobei die unter FreeBSD 14.2 vielleicht gar nicht mehr funktioniert).

Ich hab zur Zeit ein ähnliches Problem. Auch bei mir gibts mit dem Upgrade nach 14.2 Probleme. Allerdings sieht das Fehlerbild anders aus (Bildschirm schwarz nach laden des Treibers) und ich hab auch andere Grafikhardware (AMD). Da kam ich aber noch nicht dazu, mich darum zu kümmern.

 

[pit234a]

Mag sein. Es ist ja auch nur eine Vermutung, das die Probleme am Grafiktreiber liegt. Wenn auch eine Plausible.
Und da man sich eh drum kümmern muss, kann man es ja auch machen und dann gucken, ob es das Problem fixt.

Nicht zwingend. Aber dann bist Du bestenfalls in irgendeinem VESA-Mode und viele Möglichkeiten der Grafikkarte liegen brach.
Es gibt dann zwar noch die Xorg-eigenen Grafiktreiber, aber zumindest für neuere Grafik-Hardware werden die ja nicht mehr gepflegt.

Doch die Konsole geht über das drm , wenn dieses geladen ist.

Ihr seid da auf dem richtigen Weg, behaupte ich mal einfach so und entgegen meiner Behauptung von oben.

Was meinen Sinneswandel eingeleitet hat, ist ganz einfach mein eigener Lenovo, den ich letztens ja noch auf 14.2 upgedatet hatte und keine Probleme sehen konnte. Weil ich halt auch nicht wirklich genau hingesehen hatte.
Ich sehe dem Gerät für gewöhnlich nicht beim Booten zu und nach dem Booten startet auf einer Konsole der XDM, ich logge mich ein und fahre fort in X. Mir sind da keine Probleme aufgefallen.
Als ich aber nun das Gerät wieder gestartet habe, ist mir das gleiche Verhalten aufgefallen, wie vom TE beschrieben. Nur, dass ich gar nicht auf eine Konsole komme und deshalb auch nichts eingeben kann. Irgendwann, während des Bootprozesses (mit Umschalten auf EFI-Konsole), wird die Konsole unbrauchbar, zunächst mal nur schwarz. Dass aber die Konsole nicht mehr so einfach aus X heraus erreichbar ist, kennen wir als Problem seit Jahren und deshalb ignoriere ich das hier. Mit XDM lande ich aber im X und kann mich anmelden und komme in vollen Genuss des X-Servers, ohne mich allerdings von dort auf die Konsole schalten zu können.
Soweit so gut.
Aber nun wollte ich den drm abschalten (wie oben in einem meiner Posts mal vorgeschlagen) und nahm deshalb den i915kms aus meiner rc.conf heraus. Das wirkte nur mäßig. Ich konnte die Änderungen beim Booten in der Konsole verfolgen, es gab keinen schwarzen Screen und die Schrift änderte sich auch nicht, wie bei der "EFI-Konsole" gewohnt, aber am Ende stand trotzdem wieder der XDM und die Konsolen waren nicht erreichbar.
Ein Blick auf die "trotzdem" geladenen Module zeigt mir:
i915kms.ko (/boot/modules/i915kms.ko)
drm.ko (/boot/modules/drm.ko)
Was mir zumindest sagt, dass diese Module geladen sind wenn X aktiv ist. X wird sie wohl gefunden haben und dann auch geladen, aber wahrscheinlich (so deute ich das) ein klein wenig später, als die Konsole sie benutzt hätte und deshalb konnte ich zumindest dem Bootvorgang ohne Abtauchen in einen schwarzen Bildschirm folgen.

Wirres Geschwätz. Aber besser kann ich es halt nicht und ich wollte es los werden, bevor ich mich nun meinem Lenovo weiter widme.
Dieser Lenovo hat keine PORTS!
Bisher jedenfalls.
Zuletzt hatte ich die gebrauchten Module auf einem anderen PC kompiliert und dann auf diesen PC kopiert.
Nun sind mit Sicherheit diese Module durch den UPGRADE überschrieben worden und das bedeutet, zurück gesetzt auf 14.1 (siehe oben).
Am einfachsten wird sein, wenn ich die Ports aus-checke und es mal auf diesem PC direkt mit Bauen versuche. Wollte ich zwar vermeiden, aber es ist dann einfach und klar.

PS: es gab mehrere Beiträge zuvor, die ich nicht berücksichtigt habe.

 

[cabriofahrer]

Wenn ich das richtig verstanden habe, erledigt sich das Problem von selber, wenn Du mit dem freebsd-update bis zum EOL von FreeBSD 14.1
wartest (31.03.2025). Also irgendwann im April 2025 das freebsd-update auf 14.2 durchführen. Ich mache das auf jeden Fall so.

Ja, genau. Hier steht ja auch, dass das Kernelmodul für 14.1 kompiliert ist:

FreshPorts -- graphics/drm-61-kmod: DRM drivers modules

amdgpu, i915, and radeon DRM drivers modules. Currently corresponding to Linux 6.1 DRM. This version is for FreeBSD 14-STABLE 1400508 and above.

www.freshports.org

Also bei 14.1 bleiben oder selbst kompilieren. Dazu braucht man aber nicht nur die Ports, sondern auch die Sourcen auf dem aktuellen Stand, die in /usr/src/ liegen. Wir hatten das alles in meinem Thread:

C

Thema 'Fragen zu guter Upgradepraxis bei GPUs von AMD und Intel'

15 September 2024

Das Problem ist allgemein bekannt und taucht hier im Forum an mehreren Stellen auf: Nutzer mit AMD und Intel GPUs bekommen manchmal bei einem Upgrade von einer Minor-Version zur nächsten nach einem Neustart einen Kernel Panic, man kommt dann wohl nicht herum, drm-kmod aus den Ports zu komplilieren, was wiederum voraussetzt, dass man die Sources braucht, die man in den meisten Fällen bei einer Frischinstallation auch nicht installiert hat. Ich möchte gerne hier meine Erfahrungen auf Maschinen schildern, die keine Nvidia GPU haben und Eure Meinungen / Vorschläge hören, wie man denn bei...

• cabriofahrer
• Antworten: 23
• Forum: FreeBSD - Allgemein

Weitere Beobachtung von mir auf einem alten Notebook mit Radeon-Chip: Die Grafik funktionierte auch nicht richtig nach einem Upgrade von 14.1 auf 14.2. Zum einen wird automatisch drm-61-kmod anstatt von wie vorher drm-515-kmod installiert. Doch das Kompilieren vom drm-61-kmod für 14.2 brachte auch nicht viel, immernoch schwarzer Bildschirm im Konsolenmodus, zwar startete X, aber ich hatte keine Beschleunigung mehr (glxinfo | grep Accel : No). Erst das Deinstallieren und anschließende Kompilieren von drm-515-kmod ließ dann wieder alles richtig funktionieren.

 

[Tatzahn]

Danke ALLE, die sich hier Gedanken gemacht haben und geholfen haben. Ich muss hier mal für mich einen break machen, weil ich mir schon vorkomme wie ein "Konsoleneingabenpapagei", der ohne zu begreifen umsetzt, was andere an Lösungsvorschlägen geben. Das kann eine Weile ok sein, aber ich muss da wohl noch etwas Wissen ansammeln.

Ich werde erst mal ein

#freebsd-update rollback

laufen lassen. Wenn das Scherereien macht... Maybe neuinstallieren. Die BSD's sind für mich was Neues und ich finds interessant, mich da reinzufuchsen und bleibe dran

 

[Andy_m4]

sondern auch die Sourcen auf dem aktuellen Stand, die in /usr/src/ liegen

Da sagst Du natürlich was. Unter der Voraussetzung das /usr/src leer ist, kann man dafür folgenden git-Befehl absetzen:
git clone -b releng/14.2 --depth 1 https://git.freebsd.org/src.git /usr/src

Die Richtung könnte auch mein Problem lösen. Ich hatte nämlich mit der Vorversion was getestet und da sitzt noch ein Symlink falsch.
Danke @cabriofahrer für den Input !

Zum einen wird automatisch drm-61-kmod anstatt von wie vorher drm-515-kmod installiert.

Ja. So was kann manchmal helfen.

.... vorkomme wie ein "Konsoleneingabenpapagei", der ohne zu begreifen umsetzt ...

Das verstehe ich. Du darfst auch gerne Fragen stellen, wenn irgendwo was unklar ist.

 

[turrican]

Da sagst Du natürlich was. Unter der Voraussetzung das /usr/src leer ist,

wenn /usr/src leer wäre, dann bricht drm-61-kmod beim bauen mit einer Fehlermeldung ab (war zumindest bei mir so), die Kernel Sourcen müssen zum bauen da sein

 

[Andy_m4]

beim bauen mit einer Fehlermeldung ab (war zumindest bei mir so)

Ja. Darüber haben wir leider keine detaillierten Informationen.
Auf jeden Fall würde ich sicherheitshalber /usr/src leeren und es mit einer frischen Kopie der FreeBSD-Quellen versuchen.

 

[pit234a]

Trotz der vorhergehenden Einwände, möchte ich ein Feedback aus meiner Ecke geben.
Kurz nur überlegte ich, was ich denn tun soll und entschloss mich dann, auch auf diesem Lenovo-PC die Ports und Sources zu installieren. Die Erfahrung zeigt ja, dass doch immer mal wieder etwas von Hand gebaut werden muss und das ist doch auf dem eigentlichen PC am einfachsten.
Somit baute ich denn also den drm-61-kmod aus den aktuellen! Ports neu.
Der bringt sodann ein neues drm.ko und ein neues i915kms.ko, die ja auch unbedingt zueinander passen müssen.

Der Einfachheit halber neu gebootet: ist alles, wie ich es erwarte!
Die Konsole wird nicht schwarz, sie ändert wie üblich die Auflösung irgendwann, danach startet X mit dem XDM, ich kann mich einloggen und unter X arbeiten. Ich sehe derzeit keine Fehler im ff. Auch auf die Konsolen kann ich wechseln und wieder zurück.
VLC startet nicht und ein Film mit MPV spielt zwar schön, schaltet aber die Tastatur vollkommen weg und bleibt im Fullscreen im Vorgergrund, wobei automatisch GPU und VDPAU als vo geladen werden. Ändere ich die Automatik auf vo=xv, ist alles gut, doch ist dies natürlich nur ein erster und schneller Test.

Nochmal deutlich: /usr/ports und /usr/src waren zuvor leer, durch den git Aufruf habe ich die befüllt (siehe Beiträge oben von @Andy_m4) und weil das Gestern schon passiert war, heute vor dem Bau nochmals jeweils einen git pull ausgeführt. Ich halte dies für sehr wichtig, weil es keinen Automatismus gibt und der Bau aus den Ports mitunter deshalb nicht die aktuelle Version bringt, die man sich eigentlich erhofft.

Wieso das, was bei mir klappte, beim TE nicht funktionierte, sollte recht einfach zu ermitteln sein.

 

[Andy_m4]

heute vor dem Bau nochmals jeweils einen git pull ausgeführt. Ich halte dies für sehr wichtig, weil es keinen Automatismus gibt und der Bau aus den Ports mitunter deshalb nicht die aktuelle Version bringt

Ja. Einen direkten Automatismus gibt es nicht. Ich für mich hab mir ein Skript geschrieben was den aktuellsten Kram zieht und kompiliert.

Für das FreeBSD-compile gibts einen kleinen Automatismus. In der make.conf gibts die Option PORTS_MODULES, wo man Ports eintragen kann, die neu kompiliert werden sollen, wenn der Kernel kompiliert wird. Da kann man theoretisch solche Geschichten wie den Grafiktreiber eintragen. Wenn man dann sein FreeBSD aus den Quellen aktualisiert, dann hat man so was wie den Grafiktreiber gleich mitgezogen.