nvidia-drm kaputt auf 15.1?

h^2

hat ne Keule +1
Ich habe eben auf 15.1 aktualisiert nach https://www.freebsd.org/releases/15.1R/upgrading/#upgrade-pkg

Leider hat pkg upgrade -r FreeBSD-ports-kmods nicht die Nvidia-Pakete aktualisiert. Leider gibt es auch keine aktuellen Pakete auf dem Mirror, schonmal mäßige Upgrade-Experience. Egal, also aus den Ports aktualisiert, das geht bei den Treibern ja fix.

Nun sind die entsprechenden Pakete auf den neuen Versionen:
Code:
drm-66-kmod-6.6.25.1501000_9   Direct Rendering Manager GPU drivers
drm_info-2.10.0                Dump info about DRM devices
libdrm-2.4.133,1               Direct Rendering Manager library and headers
libva-nvidia-driver-0.0.17     NVDEC-based backend for VAAPI
linux-nvidia-libs-devel-610.43.02 NVIDIA graphics libraries and programs (Linux)
linux-rl9-libdrm-2.4.123       Rocky Linux Direct Rendering Manager runtime
nvidia-driver-devel-610.43.02  NVIDIA graphics driver userland
nvidia-drm-66-kmod-devel-610.43.02.1501000 NVIDIA DRM Kernel Module
nvidia-drm-kmod-devel-610.43.02 NVIDIA DRM kernel module
nvidia-kmod-devel-610.43.02.1501000 NVIDIA graphics driver kernel module

Laden der Treiber bei Systemstart klappt auch. Aber sobald ich Wayland oder Xorg starte, gibt es eine page fault while in kernel mode.

Wenn ich statt nvidia-drm beim Systemstart nvidia-modeset lade, dann kann ich zumindest Xorg noch starten. Aber das ist ja schon wieder Mist, wenn Wayland nicht geht. Ich verstehe nicht genau, warum das soo frickelig ist. Wayland ist nun wirklich schon Standard. Selbst KDE droppt jetzt Xorg.
Und NVIDIA wird seit dem Urknall als die beste Hardware für FreeBSD beworben... bei den aktuellen Preisen werde ich mir sicher keine neue Grafikkarte holen :grumble:

Wie macht ihr das denn? Weiter auf 15.0 fahren, ist doch auch keine Option.
 
erinnert mich an dies:

dort berichtet der TE, dass es mit quarterly Paketen noch geht, falls das für dich eine (vorübergehende) Alternative sein könnte.

In der Vergangenheit half schon mal, nicht den aktuellen drm-66 sondern vielleicht drm-61 zu benutzen (falls das noch gibt).

Bei mir läuft nvidia noch mit 14.4 auf latest und Wayland. Auch keine dauerhafte Sache, klar. Aber mein letzter Versuch auf 15 zu gehen ist verheerend misslungen (was nichts mit dieser Thematic zu tun hat, nur erklärten soll).
Im Vergleich ist meine nvidia echt zickig, während die alte Intel im Laptop vollkommen problemlos erscheint. Linus (der Linux Linus) hat ja nvidia mal den Stinkefinger gezeigt und obwohl ich mich dafür nicht begeistere, kann ich inzwischen so ein wenig das Gefühl teilen. Nvidia ist ganz offenbar zur Zeit keine gute Wahl für OSS.
 
Ich habe eben auf 15.1 aktualisiert nach https://www.freebsd.org/releases/15.1R/upgrading/#upgrade-pkg

Leider hat pkg upgrade -r FreeBSD-ports-kmods nicht die Nvidia-Pakete aktualisiert. Leider gibt es auch keine aktuellen Pakete auf dem Mirror, schonmal mäßige Upgrade-Experience. Egal, also aus den Ports aktualisiert, das geht bei den Treibern ja fix.

Nun sind die entsprechenden Pakete auf den neuen Versionen:
Code:
drm-66-kmod-6.6.25.1501000_9   Direct Rendering Manager GPU drivers
drm_info-2.10.0                Dump info about DRM devices
libdrm-2.4.133,1               Direct Rendering Manager library and headers
libva-nvidia-driver-0.0.17     NVDEC-based backend for VAAPI
linux-nvidia-libs-devel-610.43.02 NVIDIA graphics libraries and programs (Linux)
linux-rl9-libdrm-2.4.123       Rocky Linux Direct Rendering Manager runtime
nvidia-driver-devel-610.43.02  NVIDIA graphics driver userland
nvidia-drm-66-kmod-devel-610.43.02.1501000 NVIDIA DRM Kernel Module
nvidia-drm-kmod-devel-610.43.02 NVIDIA DRM kernel module
nvidia-kmod-devel-610.43.02.1501000 NVIDIA graphics driver kernel module

Laden der Treiber bei Systemstart klappt auch. Aber sobald ich Wayland oder Xorg starte, gibt es eine page fault while in kernel mode.

Wenn ich statt nvidia-drm beim Systemstart nvidia-modeset lade, dann kann ich zumindest Xorg noch starten. Aber das ist ja schon wieder Mist, wenn Wayland nicht geht. Ich verstehe nicht genau, warum das soo frickelig ist. Wayland ist nun wirklich schon Standard. Selbst KDE droppt jetzt Xorg.
Und NVIDIA wird seit dem Urknall als die beste Hardware für FreeBSD beworben... bei den aktuellen Preisen werde ich mir sicher keine neue Grafikkarte holen :grumble:

Wie macht ihr das denn? Weiter auf 15.0 fahren, ist doch auch keine Option.
Ja diese Erfahrung habe ich auf meinem Desktop-PC + NVIDIA RTX 2080 SUPER unter 15.1 auch machen muessen und bin daher erstmal wieder bei Xorg gelandet. Hatte mich schon an Sway gewoehnt. Momentan fehlt mir noch die Zeit und Lust, mich darum zu kuemmern.
 
Das einzige was ich beitragen kann, weil mir die Fehlermeldung bekannt vor kam: https://forums.freebsd.org/threads/page-fault-during-15-1-update.103010/ Ich schätze aber, dass dich das nicht weiterbringt.

Hast du hw.nvidiadrm.modeset="1" in deiner /boot/loader.conf stehen? Wenn ich das Handbuch richtig verstehe, solltest du mit deiner Version mit nvidia-drm ohnehin richtig sein. nvidia-modeset benötigen wohl nur ältere Treiber, die kein "Direct Rendering" unterstützen. Gibt es einen Grund, weshalb du die -devel Variante nutzt?
 
habe gerade auch so was erlebt, wie
Das einzige was ich beitragen kann, weil mir die Fehlermeldung bekannt vor kam: https://forums.freebsd.org/threads/page-fault-during-15-1-update.103010/ Ich schätze aber, dass dich das nicht weiterbringt.
Das Modul i915kms.ko verursachte bei mir die Kernel-Panik, nach Upgrade von 15.0 auf 15.1.
i915.kms.ko wird geliefert von drm-66-kmod und ich habe nicht erst versucht, Versionen zu vergleichen und gleich aus den Ports gebaut und hatte damit Erfolg.
Zum Upgrade benutzte ich freebsd-rustdate, was ja nicht offiziell ist. Insofern...
Mein Gefühl zeigt aber in Richtung mismatch zwischen Kernel-Modulen beim System-Upgrade zu 15.1.
 
dass es jetzt drm-612 gibt
Als Hinweis/Ergänzung dazu:
Es gibt ja den Metaport nvidia-drm-kmod, der dann quasi nach FreeBSD-Version die entsprechende Treiberversion installiert.

Die interne Versionsnummer für FreeBSD 15.1 ist 1501000
Und für Version >= 1500509 würde dieser Meta-Port ohnehin nvidia-drm-612-kmod nehmen.

Sprich: Für FreeBSD 15.1 wäre nvidia-drm-612-kmod ohnehin die empfohlene Variante.
Ist ohnehin sinnvoll, dann immer den Metaport zu installieren statt direkt die Version, weils dann automatisch mit hochgezogen wird und man nicht irgendwann mal bei einem FreeBSD-Upgrade dumm da steht.
 
Nvidia ist ganz offenbar zur Zeit keine gute Wahl für OSS.

NVIDIA ist doch inzwischen eingeknickt und unterstützt GBM (und nicht mehr nur ihr Eigengewächs EGLStreams) unter Wayland. Zumindest unter Linux läuft es auch einwandfrei. Wie es bei X11 aussieht, keine Ahnung - das ist eh tot.

GPUs sind inzwischen auch nur noch ein Nebengeschäft für NVIDIA - die Kohle wird mit KI-Beschleunigern verdient.

Ob man nicht sowieso lieber AMD oder Intel aufgrund der OSS-Treiber nimmt, steht auf einem anderen Blatt.

Und NVIDIA wird seit dem Urknall als die beste Hardware für FreeBSD beworben...

Der Urknall ist eine Weile her - inzwischen ist man mit AMD und Intel besser bedient.

... bei den aktuellen Preisen werde ich mir sicher keine neue Grafikkarte holen :grumble:

Das ist aktuell echt kein Spaß. Vielleicht kannst du aber deine NVIDIA-GPU gegen eine vergleichbare AMD-GPU tauschen und musst nicht mal was draufzahlen.

Wie macht ihr das denn? Weiter auf 15.0 fahren, ist doch auch keine Option.

Aussitzen. FreeBSD 15.0 wird noch bis Ende September unterstützt. Die Kinderkrankheiten eines neuen Releases - gerade auf dem doch eher stiefmütterlich unterstützten Desktop bei FreeBSD - lasse ich persönlich lieber andere lösen. :o
 
Ich würde vor dem nächsten Versuch noch einmal prüfen, ob wirklich keine alte Modul-Kombi liegen bleibt: also die direkt installierten nvidia-drm-66/nvidia-kmod-devel Pakete raus bzw. durch die Metaports ersetzen, danach pkg info -x "nvidia|drm" und kldstat gegenchecken. Gerade bei so einem 15.0 → 15.1 Sprung klingt das sonst schnell nach Kernel/Modul-Mismatch. Und falls du drm-612 testest: am besten in einem eigenen BE, damit du nicht wieder zurückfrickeln musst.
 
Und falls du drm-612 testest: am besten in einem eigenen BE, damit du nicht wieder zurückfrickeln musst.
Ergänzung:
Zum Module testen sollte man ja generell die nicht irgendwo in die /etc/loader.conf oder /etc/rc.conf (Stichwort: kld_list)eintragen, da sie sonst ja beim Boot-Up jedes mal crashen.
Sondern stattdessen ganz normal auf der Kommandozeile mit kldload testen.

Passiert einem das doch mal, das man es in der /etc/rc.conf vergisst rauszunehmen, kann man immer noch im Single-User-Modus booten.
Dann kann man im Prinzip die Dateien entsprechend editieren. Aber dran denken, das das Root-Verzeichnis dann als read-only gemountet ist und ggf. auch der Rest der Dateisysteme nicht da ist.
Kriegt man aber mit einem
mount -o rw /
nebst mount -a hin (bzw. bei ZFS: zfs set readonly=off zroot/ROOT/default und zfs mount -a).

Falls man dabei Probleme mit der Tastatur hat (im Single-User-Mode wird etwaiges Keymapping nicht geladen), hilft das interaktive Kommando kbdmap weiter.
 
Ergänzung:
Zum Module testen sollte man ja generell die nicht irgendwo in die /etc/loader.conf oder /etc/rc.conf (Stichwort: kld_list)eintragen, da sie sonst ja beim Boot-Up jedes mal crashen.
weil das mir genau so passiert ist, als ich von 15 nach 15.1 gegangen bin...

Nur, das war ja kein Test, zumindest kein gewollter. Eigentlich habe ich nur einen Update gemacht und anschließend neu gestartet. Ich finde nicht, dass es da normal sein sollte, erst mal die gewünschten Module nicht zu laden, also kldlist aus zu kommentieren und evtl auch was aus der loader.conf oder sysctl.conf zu nehmen.
Gottlob funktionierte bei mir der alte Kernel noch (was bei Update mit freebsd-rustdate angelegt wird) und auf Grund der Aufnahme (Film mit Handy) konnte ich auch sehen, wobei der Crash so ungefähr erfolgte.
Weil der alte Kernel noch funktionierte, konnte ich mir den Single-User-Modus oder das Booten eines externen Systems ersparen.
Mir selbst ist das Booten von extern lieber, allerdings muss ich dafür sorgen, dass nicht der interne bootfs-Zpool automatisch gestartet wird (:> .../etc/zfs/zpool.cache auf dem externen Pool). Hört sich vielleicht komplizierter an, ist mir aber lieber, weil ich sogar in eine gewohnte Umgebung starten kann (Desktop mit Netzwerk etc) und mir damit wesentlich leichter tue. Weil man so etwas immer wieder mal braucht, klone ich mir hin und wieder meine aktuellen Desktop-Systeme nach extern.
 
Eigentlich habe ich nur einen Update gemacht und anschließend neu gestartet. Ich finde nicht, dass es da normal sein sollte, erst mal die gewünschten Module nicht zu laden, also kldlist aus zu kommentieren und evtl auch was aus der loader.conf oder sysctl.conf zu nehmen.
Ja. Idealerweise sollte das nicht passieren. Nicht zuletzt deshalb gibts ja auch das kmod-Repository. Damit zumindest ABI/API-Breaks kein Problem an der Stelle provozieren.

Wenn man FreeBSD aus den Quelltexten baut gibt es auch die Option PORTS_MODULES in der /etc/make.conf
Für ein Binary-Update (so vergleichbar mit Linux/DKMS) gibts da meines Wissens leider nichts.

Da sollte man ohnehin nur Module laden die da unbedingt sein müssen und den Rest über /etc/rc.conf (und kld_list) regeln. Weil bei letztem es einfacher zu beheben und zu debuggen ist, wenn mal was schief geht.
 
Ja. Idealerweise sollte das nicht passieren. Nicht zuletzt deshalb gibts ja auch das kmod-Repository. Damit zumindest ABI/API-Breaks kein Problem an der Stelle provozieren.
genau das scheiterte aber und zwar i915.kms, auf den ja während des Bootens schon geschaltet wird (also nicht erst mit Grafik). i915.kms kommt vom drm-kmod und Neubau aus den Ports hat geholfen.
Das war zum ersten Mal, dass ich das bei der Intel-Grafik hatte.
Bei nvidia, worum es ja hier geht, habe ich das schon mehrfach ähnlich erlebt, also kein Crash, aber Neubau aus Ports notwendig, um zu funktionieren.
 
Zurück
Oben