Solved Lost hardware graphics acceleration (prior to 15.0 upgrading)

Perceval · Dec 18, 2025

EDIT 20 jan. 2026 : partially solved, xorg-server regression. Check my #32 post.

Hello !
My setup is always the same : MSI Leopard GL65 with NVIDIAI RTX 2070 (CometLake-H GT2 [UHD Graphics] + TU106M [GeForce RTX 2070 Mobile / Max-Q Refresh]), running FreeBSD 15.0-RELEASE. Running drm-61-kmod-6.1.128.1500068_8, nvidia-drm-61-kmod-580.105.08.1500068 and nvidia-kmod-580.105.08.1500068. MESA are the following : mesa-dri-24.1.7_9 and mesa-libs-24.1.7_1. (EDIT : switched to drm-66, same issue).

I play Luanti (using OpenGL 4.5 as stated by the game itself) with kids, and in september (14.3-RELEASE p? I always upgrade to the current version, so probably P4 or P5) it did work fine -smooth, no problem at all.
Since late october (still on 14.3), probably after a classic pkg upgrade, I noticed a big performance loss and fans running high but I didn't care more when it happened. Since then (and still on 15.0), the performance is VERY poor (15/20 fps max) and I suspected a bad setup into my Luanti, but using a fully clean setup + stock settings just do the same. I haven't noticed yet, but several other apps are slower than before (QGIS or Inkscape). Freecad and Blender are painful to use too. Looks definitely that the CPU handles graphics, this explaining with I have full spinning fans, and my NVIDIAI card NOT heating (steady 50/54°C). But something's getting hot in the laptop anyway.

I searched a bit, but no real clue. Here is the result of glxinfo -B (I can't compare with how it was before) :

Code:

name of display: :0.0
MESA-LOADER: failed to open nouveau: Cannot open "/usr/local/lib/dri/nouveau_dri.so" (search paths /usr/local/lib/dri, suffix _dri)
failed to load driver: nouveau
MESA-LOADER: failed to open nouveau: Cannot open "/usr/local/lib/dri/nouveau_dri.so" (search paths /usr/local/lib/dri, suffix _dri)
failed to load driver: nouveau
'-avx512er' is not a recognized feature for this target (ignoring feature)
'-avx512pf' is not a recognized feature for this target (ignoring feature)
'-avx512er' is not a recognized feature for this target (ignoring feature)
'-avx512pf' is not a recognized feature for this target (ignoring feature)
'-avx512er' is not a recognized feature for this target (ignoring feature)
'-avx512pf' is not a recognized feature for this target (ignoring feature)
'-avx512er' is not a recognized feature for this target (ignoring feature)
'-avx512pf' is not a recognized feature for this target (ignoring feature)
'-avx512er' is not a recognized feature for this target (ignoring feature)
'-avx512pf' is not a recognized feature for this target (ignoring feature)
'-avx512er' is not a recognized feature for this target (ignoring feature)
'-avx512pf' is not a recognized feature for this target (ignoring feature)
'-avx512er' is not a recognized feature for this target (ignoring feature)
'-avx512pf' is not a recognized feature for this target (ignoring feature)
'-avx512er' is not a recognized feature for this target (ignoring feature)
'-avx512pf' is not a recognized feature for this target (ignoring feature)
'-avx512er' is not a recognized feature for this target (ignoring feature)
'-avx512pf' is not a recognized feature for this target (ignoring feature)
display: :0  screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
    Vendor: Mesa (0xffffffff)
    Device: llvmpipe (LLVM 19.1.7, 256 bits) (0xffffffff)
    Version: 24.1.7
    Accelerated: no
    Video memory: 40959MB
    Unified memory: yes
    Preferred profile: core (0x1)
    Max core profile version: 4.5
    Max compat profile version: 4.5
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.2
Memory info (GL_ATI_meminfo):
    VBO free memory - total: 0 MB, largest block: 0 MB
    VBO free aux. memory - total: 32768 MB, largest block: 32768 MB
    Texture free memory - total: 0 MB, largest block: 0 MB
    Texture free aux. memory - total: 32768 MB, largest block: 32768 MB
    Renderbuffer free memory - total: 0 MB, largest block: 0 MB
    Renderbuffer free aux. memory - total: 32768 MB, largest block: 32768 MB
Memory info (GL_NVX_gpu_memory_info):
    Dedicated video memory: 599115 MB
    Total available memory: 640074 MB
    Currently available dedicated video memory: 0 MB
OpenGL vendor string: Mesa
OpenGL renderer string: llvmpipe (LLVM 19.1.7, 256 bits)
OpenGL core profile version string: 4.5 (Core Profile) Mesa 24.1.7
OpenGL core profile shading language version string: 4.50
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
'-avx512er' is not a recognized feature for this target (ignoring feature)
'-avx512pf' is not a recognized feature for this target (ignoring feature)
'-avx512er' is not a recognized feature for this target (ignoring feature)
'-avx512pf' is not a recognized feature for this target (ignoring feature)
'-avx512er' is not a recognized feature for this target (ignoring feature)
'-avx512pf' is not a recognized feature for this target (ignoring feature)
'-avx512er' is not a recognized feature for this target (ignoring feature)
'-avx512pf' is not a recognized feature for this target (ignoring feature)
'-avx512er' is not a recognized feature for this target (ignoring feature)
'-avx512pf' is not a recognized feature for this target (ignoring feature)
'-avx512er' is not a recognized feature for this target (ignoring feature)
'-avx512pf' is not a recognized feature for this target (ignoring feature)
'-avx512er' is not a recognized feature for this target (ignoring feature)
'-avx512pf' is not a recognized feature for this target (ignoring feature)
'-avx512er' is not a recognized feature for this target (ignoring feature)
'-avx512pf' is not a recognized feature for this target (ignoring feature)
'-avx512er' is not a recognized feature for this target (ignoring feature)
'-avx512pf' is not a recognized feature for this target (ignoring feature)

OpenGL version string: 4.5 (Compatibility Profile) Mesa 24.1.7
OpenGL shading language version string: 4.50
OpenGL context flags: (none)
OpenGL profile mask: compatibility profile
'-avx512er' is not a recognized feature for this target (ignoring feature)
'-avx512pf' is not a recognized feature for this target (ignoring feature)
'-avx512er' is not a recognized feature for this target (ignoring feature)
'-avx512pf' is not a recognized feature for this target (ignoring feature)
'-avx512er' is not a recognized feature for this target (ignoring feature)
'-avx512pf' is not a recognized feature for this target (ignoring feature)
'-avx512er' is not a recognized feature for this target (ignoring feature)
'-avx512pf' is not a recognized feature for this target (ignoring feature)
'-avx512er' is not a recognized feature for this target (ignoring feature)
'-avx512pf' is not a recognized feature for this target (ignoring feature)
'-avx512er' is not a recognized feature for this target (ignoring feature)
'-avx512pf' is not a recognized feature for this target (ignoring feature)
'-avx512er' is not a recognized feature for this target (ignoring feature)
'-avx512pf' is not a recognized feature for this target (ignoring feature)
'-avx512er' is not a recognized feature for this target (ignoring feature)
'-avx512pf' is not a recognized feature for this target (ignoring feature)
'-avx512er' is not a recognized feature for this target (ignoring feature)
'-avx512pf' is not a recognized feature for this target (ignoring feature)

OpenGL ES profile version string: OpenGL ES 3.2 Mesa 24.1.7
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20

kldstat is normal (I have i915kms.ko, nvidia-modeset.ko and nvidia.ko) and the lines in dmesg are :

Code:

acpi_video1: <ACPI video extension> on vgapci1
[drm] Got Intel graphics stolen memory base 0x0, size 0x0
drmn1: <drmn> on vgapci1
vgapci1: child drmn1 requested pci_enable_io
vgapci1: child drmn1 requested pci_enable_io
i915/kbl_dmc_ver1_04.bin: could not load binary firmware /boot/firmware/i915/kbl_dmc_ver1_04.bin either
kbl_dmc_ver1_04.bin: could not load binary firmware /boot/firmware/kbl_dmc_ver1_04.bin either
i915_kbl_dmc_ver1_04.bin: could not load binary firmware /boot/firmware/i915_kbl_dmc_ver1_04.bin either
drmn1: successfully loaded firmware image 'i915/kbl_dmc_ver1_04.bin'
drmn1: [drm] Finished loading DMC firmware i915/kbl_dmc_ver1_04.bin (v1.4)
sysctl_add_oid: can't re-use a leaf (hw.dri.debug)!
[drm] Initialized i915 1.6.0 20201103 for drmn1 on minor 0
VT: Replacing driver "efifb" with new "drmfb".
start FB_INFO:
height=1080 width=1920 depth=32
pbase=0xa0040000 vbase=0xfffff800a0040000
name=drmn1 id=i915drmfb flags=0x0 stride=7680
end FB_INFO
nvidia0: <NVIDIA GeForce RTX 2070> on vgapci0
vgapci0: child nvidia0 requested pci_enable_io
vgapci0: child nvidia0 requested pci_enable_io
nvidia-modeset: Loading NVIDIA Kernel Mode Setting Driver for UNIX platforms  580.105.08  Wed Oct 29 22:04:36 UTC 2025
[drm] [nvidia-drm] [GPU ID 0x00000100] Loading driver
sysctl_add_oid: can't re-use a leaf (hw.dri.debug)!
sysctl_add_oid: can't re-use a leaf (hw.dri.vblank_offdelay)!
sysctl_add_oid: can't re-use a leaf (hw.dri.timestamp_precision)!
[drm] Initialized nvidia-drm 0.0.0 20160202 for nvidia0 on minor 1

I have no real idea where to start from to solve this issue. My Thinkpad runs Luanti with no problem, so do my kids' computers which are much less powerful and running Windows.

Thank you very much for any help

blackbird9 · Dec 18, 2025

Have a look through /var/log/Xorg.0.log and check which driver has been loaded. I don't have an nvidia graphics machine to compare it with but if you go through the trace you will see which driver it has ended up loading.
It looks like like mesa is trying to load the nouveau driver from this line of output:-

Failed to open nouveau: Cannot open "/usr/local/lib/dri/nouveau_dri.so"

- but not finding the nouveau shared object file. Nouveau is the standard xorg nvidia chip driver.

If xorg.0.log shows it's loaded the vesa driver instead, which is the unaccelerated default, that would explain why you've got poor performance.

To check what you currently have say
$ xdriinfo
screen 0: crocus

Where 'crocus' is the intel open source driver, so for nvidia it probably should say 'nouveau' or maybe 'nv', at a guess. Someone familiar with nvidia graphics on freebsd may correct me though!

To check if you have GL acceleration
$ glxinfo | grep -i accel
Accelerated: yes

It may just be that you need to install the xorg nouveau driver, but I'm guessing.

blackbird9 · Dec 18, 2025

I just spotted

nvidia-modeset: Loading NVIDIA Kernel Mode Setting Driver for UNIX platforms 580.105.08 Wed Oct 29 22:04:36 UTC 2025
[drm] [nvidia-drm] [GPU ID 0x00000100] Loading driver
sysctl_add_oid: can't re-use a leaf (hw.dri.debug>!
sysctl_add_oid: can't re-use a leaf (hw.dri.vblank_offdelay)!
sysctl_add_oid: can't re-use a leaf (hw.dri.timestamp_precision)!
[drm] Initialized nvidia-drm 0.0.0 20160202 for nvidia0 on minor 1

So is it throwing errors trying to load the nvidia driver? Although it says it's initialised it at the end.
Need to compare it to the trace from a box where it works.

I wonder if this thread is related

G

Thread 'Can't kldload nvidia-drm'

Aug 1, 2025

I'm trying to fix an ongoing issue with not being able to run Wayland. In reading up on the issue it appears that you need to compile the nvidia-drm driver from the port because the version in the package repository doesn't match up to the current kernel. So I did a git pull and built it from source. I had to manually move the existing /boot/modules/nvidia-drm.ko in order to get make to recognize that it needed to actually build.

I now get the following error:

# sudo kldload nvidia-drm.ko
kldload: can't load nvidia-drm.ko: module already loaded or in kernel
# kldstat -v | grep nvidia...

blackbird9 · Dec 18, 2025

Someone said in this thread

S

Solved Thread 'Still can't get Wayland working with NVidia.'

Jul 10, 2024

I had Wayland working with NVidia for while, then it stopped. I've pretty much followed the handbook.

Installed wayland and seatd. Then I installed labwc and dwl. They pulled in other things like wl-roots, I don't remember exactly.
pciconf -lv shows


GP108 [GeForce GT 1030]

XDG_RUNTIME_DIR is /run/user/$(id -u) set in my .bashrc.

I start the seatd service.

But when I try to start say dwl, I get the message


00:00:00.007 [ERROR] [backend/backend.c:210] Found 0 GPUs, cannot create backend
00:00:00.007 [ERROR] [backend/backend.c:376] Failed to open any DRM device
couldn't create backend...

You may need to set
hw.nvidiadrm.modeset=1
in loader.conf

It sounds like a few people have been round that loop...

Better wait till someone who knows what they're talking about answers!

Perceval · Dec 18, 2025

blackbird9 :
Indeed, i didn't look into Xorg.0.log, here are some lines :

Code:

...
[    25.950] (II) LoadModule: "nv"
[    25.951] (WW) Warning, couldn't open module nv
[    25.951] (EE) Failed to load module "nv" (module does not exist, 0)
[    25.951] (II) LoadModule: "intel"
[    25.951] (WW) Warning, couldn't open module intel
[    25.951] (EE) Failed to load module "intel" (module does not exist, 0)
...

I don't use the module intel in this context, because the nvidia driver handles everything. It's a very messy Optimus setup and I have to play with the drivers. I just don't understand, because nothing in the setup changed, but updates. I also don't understand why it's looking for nouveau, afaik there's nothing like this on FreeBSD.
I've been trying to remove i915kms from rc.conf, but I have output on my external monitor - but the OpenGL driver DOES work ! It's well stated that's NVIDIA driver, accelerated, no error. I then tried to install drm-kmod metaport to test but no change here.

xdriinfo does want me to open nouveau :

Code:

MESA-LOADER: failed to open nouveau: Cannot open "/usr/local/lib/dri/nouveau_dri.so" (search paths /usr/local/lib/dri, suffix _dri)
failed to load driver: nouveau
MESA-LOADER: failed to open nouveau: Cannot open "/usr/local/lib/dri/nouveau_dri.so" (search paths /usr/local/lib/dri, suffix _dri)
failed to load driver: nouveau
Screen 0: swrast

hw.nvidiadrm.modeset=1 is of course since a loong time ago (my setup did work fine and became like this for no real reason as I haven't changed anything)

I'm going to think that i915kms is the problem, but it wasn't up to two months ago. I keep searching

Perceval · Dec 18, 2025

By th way, I forgot to add : the Intel firmware seems fine.

Code:

gpu-firmware-intel-kmod-kabylake-20250109.1500068

Perceval · Dec 19, 2025

As of today, absolutely nothing I've tried did it. Without any driver installed, I switch back to my laptop screen with llvmpipe ; drm-kmod alone does not startx, reverted everything to 6.1 (using ports from nvidia-drm-61-kmod and nvidia-driver because of version mismatch), nothing but llvm. Since nothing works, I went back to 6.6.
I found some Xorg logs from (WORKING setup) july and august, telling only nv and intel can't be found, so I think I should not care about intel module not found.
The old logs archives from october (messages.X.bz2) do not stat anything different from now (including errors). I do not understand at all what's wrong here.

Erichans · Dec 19, 2025

Perceval said:
(EE) Failed to load module "nv" (module does not exist, 0)

If you are using Xorg exclusively (and not Wayland), is there a particular reason that you don't (want to) run a fully proprietary Nvidia graphics stack?
That is, like mentioned here at the end of the message.

Perceval · Dec 19, 2025

Erichans said:
If you are using Xorg exclusively (and not Wayland), is there a particular reason that you don't (want to) run a fully proprietary Nvidia graphics stack?
That is, like mentioned here at the end of the message.

Well, no problem for me to get it, since it has the best support (otherwise I won't probably use it but an open source alternative).
I'm a dinosaur so I'll keep running X11 and I have no plan yet to use Wayland.
All pkgs are running the same latest version, without any mismatch (that's why I used ports to correct the mismatched ones). I even tried to use latest libdrm from ports, no change.

I don't know if it can be helpful, but several tests inside rc.conf showed :
using nvidia-drm (with i915kms) is the only way to start X. Using nvidia-modeset alone does crash.
Using i915kms fails back to my laptop screen only, without any driver (and using drm-kmod makes it not to startx, crazy).
Using nvidia-drm alone makes my external monitor working only, WITH hardware acceleration working.

I'm concerned, because Luanti is just casual fun, but I'll have soon to use Qgis and some heavy 3D graphics, and I'll just can't do it in FreeBSD...

Erichans · Dec 19, 2025

Perceval said:
Using nvidia-modeset alone does crash.

If you have any interest in getting more clarity about using the fully proprietary Nvidia graphics stack, I suggest you open a new thread with an appropriate "Nvidia-crash" subject title. This is the first time I heard this (that necessarily isn't all that indicative though), when the corrrect versions are used using a pure Nvidia setup crashes. I'm not an Nvidia expert, there are others, but if this type of solution crashes (what where when? I can't get a clear picture), you need to provide more info like a full dmesg listing and/or Xorg log output, you can use cat /var/log/Xorg.0.log | nc termbin.com 9999 and post the URL in the new thread.

blackbird9 · Dec 19, 2025

I haven't owned an nvidia graphics box for many years. But from memory of running with nvidia on linux years ago, you would need to load the 'nv' driver in Xorg.0.log and you do need DRI to load the noveau_dri.so. So it looks like something is misconfigured. UNLESS the system is now using the new open source nvidia driver written in Rust(!), which I know nothing about.

I would investigate why it's failing to load 'nv' in the modesetting driver and why it can't find nouveau_dri.so.
Can you find a working machine with nvidia graphics and compare the logs to see what should be happening?

I just spotted you said above logs from older working case also said 'nv' not found. Interesting.

There must be someone else out there successfully using nvidia graphics with freebsd and X11.

blackbird9 · Dec 19, 2025

using nvidia-drm (with i915kms) is the only way to start X. Using nvidia-modeset alone does crash.
Using i915kms fails back to my laptop screen only, without any driver (and using drm-kmod makes it not to startx, crazy).
Using nvidia-drm alone makes my external monitor working only, WITH hardware acceleration working.

Are there any BIOS setup options that let you select which graphics card is used for specific screens? It does seem a bit crazy.

blackbird9 · Dec 19, 2025

https://www.msi.com/Laptop/GL65-Leopard-10SX/Specification

Perceval · Dec 20, 2025

Thanks everybody for helping !

blackbird9 No, no option to disable anything in the bios.

This MSI has very strange Optimus setup because the Intel handles the laptop screen and the Nvidia controls HDMI/DisplayPort and offloads on the Intel controlled laptop screen ; I spent lots of time to get the Optimus setup to work. I try to maintain my main topic here when I update :

Solved Thread 'Optimus nVidia/Intel (MSI GL65) : unable to get dual screen to work'

Dec 14, 2023

Hello ! I've been trying to get my dual screen setup to work on X (using XFCE) but no luck.
First, my setup : it's an MSI laptop Leopard GL65, with Intel Graphics (UHD630) and a nVidia GeForce RTX 2070 SUPER, running 14.0 RELEASE.

$ pciconf -lv|grep -B4 VGA

Code:

vgapci1@pci0:0:2:0:    class=0x030000 rev=0x05 hdr=0x00 vendor=0x8086 device=0x9bc4 subvendor=0x1462 subdevice=0x12b8
    vendor     = 'Intel Corporation'
    device     = 'CometLake-H GT2 [UHD Graphics]'
    class      = display
    subclass   = VGA
--
vgapci0@pci0:1:0:0:    class=0x030000 rev=0xa1 hdr=0x00 vendor=0x10de...

Erichans The thing I don't understand is everything was working fine using the full proprietary Nvidia stack (I need to because the way my laptop does handles the mess needs it !), and didn't notice when it stopped working (pretty bad coincidence, I was using QGis days before it probably happened,and didn't have to use any 3D accelerated software since then, except Luanti which I didn't care much). It started maybe after drm-61-kmod 580.82.07_5 (1 oct 2025) or 580.95.05 (10 oct 2025) [drm-61-kmod 6.1.128_6 (1 oct 2025)]. On September I had a heavy use of Luanti and it was working perfectly.
In fact, everything works fine, but there's no hardware acceleration. I guess the prime offloading became buggy, but I can't find any clue nor when it happened. I might suspect something very simple, such as a pkg not updated correctly.

So, let me resume the current state :

Code:

libdrm-2.4.131,1 (port)
gpu-firmware-intel-kmod-kabylake-20250109.1500068 (repo)

drm-66-kmod-6.6.25.1500068_8 (FreeBSD-ports-kmods)
nvidia-driver-580.105.08 (port)
nvidia-drm-66-kmod-580.105.08.1500068_2 (port)
nvidia-kmod-580.105.08.1500068 (FreeBSD-ports-kmods)

dmesg (current state) is here : https://termbin.com/74i2
Xorg.0.log (current state) is here : https://termbin.com/z6cm
Legacy Xorg.1.log from july 24 2025, I don't know if it can be helpful : https://termbin.com/7k6x

What I have noted so far from differences between current state and the july log (these lines DO NO exist in the july log) :

Code:

(Current Xorg.log, L403-404)
[    36.496] (II) IGLX: Loaded and initialized swrast
[    36.496] (II) GLX: Initialized DRISWRAST GL provider for screen 0

Strange thing I noticed in the july log that it crashed while loading glx module :

Code:

[   128.457] (II) LoadModule: "glx"
[   128.457] (II) Loading /usr/local/lib/xorg/modules/extensions/libglx.so
[   128.457] (EE) Failed to load /usr/local/lib/xorg/modules/extensions/libglx.so: /usr/local/lib/xorg/modules/extensions/libglx.so: invalid file format
[   128.457] (EE) Failed to load module "glx" (loader failed, 0)

Does this mean the GLX module couldn't start, allowing the NVIDIA driver to take the control on it and make it work unexpectedly... ? (EDIT : nope - tested by renaming /usr/local/lib/xorg/modules/extensions/libglx.ko, no change).

Stupid me, I cleaned my previous ZFS snapshots few days ago, so I don't have any relevant log from my working setup. BUT I have an old ZFS snapshot copy on my other laptop, maybe there's something in it.

Thanks again, I do my best on my own, but this one beats me !

Erichans · Dec 20, 2025

Perceval said:
What I have noted so far from differences between current state and the july log (these lines DO NO exist in the july log) :

It would seem that you are experiencing problems before starting Xorg:

Perceval said:
dmesg (current state) is here : https://termbin.com/74i2

Excerpt from that dmesg output:

Rich (BB code):

nvidia0: <NVIDIA GeForce RTX 2070> on vgapci0
vgapci0: child nvidia0 requested pci_enable_io
vgapci0: child nvidia0 requested pci_enable_io
nvidia-modeset: Loading NVIDIA Kernel Mode Setting Driver for UNIX platforms  580.105.08  Wed Oct 29 22:04:36 UTC 2025
[drm] [nvidia-drm] [GPU ID 0x00000100] Loading driver
hdacc2: Unexpected unsolicited response with tag 63: ffffffff
sysctl_add_oid: can't re-use a leaf (hw.dri.debug)!
sysctl_add_oid: can't re-use a leaf (hw.dri.vblank_offdelay)!
sysctl_add_oid: can't re-use a leaf (hw.dri.timestamp_precision)!
[drm] Initialized nvidia-drm 0.0.0 20160202 for nvidia0 on minor 1

This is referring to the non-proprietary Nvidia DRM/KMS driver nvidia-drm.ko, that is /boot/modules/nvidia-drm.ko; the messages immediately following seem to relate to nvidia-drm, however, as just before the Nvidia proprietary nvidia-modeset is being loaded, I'm not sure if that one isn't related to these messages. Based on this output, I'm guessing that you have in your rc.conf something like kld_list="nvidia-modeset nvidia-drm".

On a 14.3-RELEASE (latest packages) (might be your previous OS before upgrading to 15.0-RELEASE), that means:

Code:

[1-0] # pkg which /boot/modules/nvidia-drm.ko
/boot/modules/nvidia-drm.ko was installed by package nvidia-drm-61-kmod-580.105.08.1403000_1

On a 15.0-RELEASE (latest packages), that means:

Code:

[10-0] # pkg which /boot/modules/nvidia-drm.ko
/boot/modules/nvidia-drm.ko was installed by package nvidia-drm-66-kmod-580.105.08.1500068_2

With upgrading to 15.0-RELEASE you (related to & affecting graphics) are running a new kernel which has a new Linux-KPI shim layer and you are using drm-66-kmod instead of drm-61-kmod. These all affect the working, most specifically the non-proprietary Nvidia modules; these are known to be sensitive; a possible mixed set-up of proprietary and non-proprietary Nvidia-drivers does add to the complexity:
nvidia-modeset: Loading NVIDIA Kernel Mode Setting Driver for UNIX platforms 580.105.08 Wed Oct 29 22:04:36 UTC 2025
indicates that you are loading the Nvidia proprietary DRM/KMS driver nvidia-modeset, that is /boot/modules/nvidia-modeset.ko, that is normally referenced by kld_list="nvidia-modeset" in your /etc/rc.conf.

When using a complex setup, such as yours, relevant and important settings are in /etc/rc.conf; and definitively for non-proprietary Nvidia DRM/KMS driver also in /boot/loader.conf. In addition to that your user Xorg conf settings that should be located in /usr/local/share/X11/xorg.conf.d/.

With reference to you mentioning of snapshots: if you are running ZFS-on-root, you most likely have a BE of your previous major OS version (14.3-RELEASE) that works. That contains the configs wrt rc.conf, loader.conf and your Xorg .conf files. This BE should also be able to return to a working graphics set up, albeit not on a 15.0-RELEASE.

The only thing that I have seen come flying by, IIRC wrt Nvidia proprietary graphics stack is:

T-Aoki said:
If so, try adding hw.nvidia.registry.EnableGpuFirmware=1 line in your /boot/loader.conf. RTX50* series are known not working properly without GSP firmware loaded.

However, I don't know if that is applicable to your GeForce RTX 2070.
Besides that referened thread, Xorg won't start with officially supported NVIDIA 5070 GPU? might be helpful.

When comparing:

Perceval said:
Xorg.0.log (current state) is here : https://termbin.com/z6cm
Legacy Xorg.1.log from july 24 2025, I don't know if it can be helpful : https://termbin.com/7k6x

Where the "Legacy" log does not seem to have a problem, the "current state" has this:

Rich (BB code):

[    36.208] (II) NVIDIA: Reserving 24576.00 MB of virtual memory for indirect memory
[    36.209] (II) NVIDIA:     access.
[    36.295] (II) NVIDIA(0): Setting mode "DFP-0:nvidia-auto-select"
[    36.345] (WW) NVIDIA(0): Failed to request fliplock.
[    36.368] (==) NVIDIA(0): Disabling shared memory pixmaps
[    36.368] (==) NVIDIA(0): Backing store enabled
[    36.368] (==) NVIDIA(0): Silken mouse enabled
[    36.369] (==) NVIDIA(0): DPMS enabled
[    36.369] (WW) NVIDIA(0): Option "PrimaryGPU" is not used

If I haven't missed anything here, that is the first indication of troubles, in the Xorg log. As mentioned before, problems seem to have started before that, given your dmesg output.

In my personal view I'd seperate the use of a full proprietary Nvidia graphics stack versus any use of non-proprietary use of either DRM/KMS drivers (such as kld_list="nvidia-drm") including, on the Xorg part, the use of the modesetting(4) driver, instead of using the Nvidia proprietary driver for Xorg referenced by:

Code:

Section "Device"
   Identifier "Card0"
   Driver "nvidia"
EndSection

Of course, how you want to persue these problems is your decision.

T-Aoki · Dec 20, 2025

Erichans said:
This is referring to the non-proprietary Nvidia DRM/KMS driver nvidia-drm.ko, that is /boot/modules/nvidia-drm.ko; the messages immediately following seem to relate to nvidia-drm, however, as just before the Nvidia proprietary nvidia-modeset is being loaded, I'm not sure if that one isn't related to these message.

nvidia-drm.ko runs on top of nvidia-modeset.ko, and nvidia-modeset.ko runs on top of nvidia.ko. Yes, nvidia.ko is the driver that actually manages GPUs.

For this reason, nvidia-drm.ko depends on nvidia-modeset.ko (and actually, part of corresponding kmods from graphics/drm-*-kmod) and nvidia-modeset.ko depends on nvidia.kmod, thus, these dependency is defined in each kmods. So kernel module loader pulls in the dependencies as defined.

And nvidia.ko is too large to safely loaded via /boot/loader.conf as of loader's limited staging area to load kernel and kmods BEFORE kernel starts running. Don't attempt to load GPU related kmods via /boot/loader.conf!

On the other hand, loading via /etc/rc.conf[.local] is handled by kernel.

One thing that can affect would be the version mis-matched between nvidia-drm.ko and kmods from graphics/drm-*-kmod matches or not.
Means, for example, graphics/nvidia-drm-61-kmod to be used with graphics/drm-61-kmod, and both are built using exactly same version of upstream drm-61-kmod source tarball.

Erichans · Dec 20, 2025

T-Aoki said:
nvidia-drm.ko runs on top of nvidia-modeset.ko, and nvidia-modeset.ko runs on top of nvidia.ko. Yes, nvidia.ko is the driver that actually manages GPUs.
[...]

Thank you for that explanation.

T-Aoki said:
One thing that can affect would be the version mis-matched between nvidia-drm.ko and kmods from graphics/drm-*-kmod matches or not.
Means, for example, graphics/nvidia-drm-61-kmod to be used with graphics/drm-61-kmod, and both are built using exactly same version of upstream drm-61-kmod source tarball.

Perceval said:
All pkgs are running the same latest version, without any mismatch (that's why I used ports to correct the mismatched ones). I even tried to use latest libdrm from ports, no change.

Although not very extensively stated, it seems OP ("that's why I used ports to correct the mismatched ones") does not* have "the version-mismatch" problem.

Edit: corrected: "does not* have"

Erichans · Dec 20, 2025

T-Aoki said:
If so, try adding hw.nvidia.registry.EnableGpuFirmware=1 line in your /boot/loader.conf. RTX50* series are known not working properly without GSP firmware loaded.

T-Aoki , do you happen to know if the above loader setting is relevant (or not) to the OP's NVIDIA GeForce RTX 2070 ?

Perceval · Dec 20, 2025

Thanks to you for these !
Erichans : You're right, my current rc.conf is the following :

Code:

kld_list="acpi_video i915kms nvidia-modeset nvidia-drm cuse fusefs coretemp cpuctl"

I can remove it, it does not change anything (I tested several times with and without).

pkg which /boot/modules/nvidia-drm.ko does as you expected :

Code:

/boot/modules/nvidia-drm.ko was installed by package nvidia-drm-66-kmod-580.105.08.1500068_2

About snapshots, as I said, I cleaned everything few days ago (I keep the last only) because everything was looking fine and I didn't notice this problem. So I don't have any log anymore...

And yes, I'm of course into the mismatched pkg problem ; I had it first in june or july, I had to port some stuff since, but I remember I didn't have anymore to do this until 15.0-RELEASE. Which can be problematic, because I'm running ports (so latest) where pkgs, dependencies, etc, rely on quartely.

I forgot to tell, indeed, that I tried hw.nvidia.registry.EnableGpuFirmware=1 but it had no effect, as I supposed because it seems that it only affects RTX 50x.

Just as a sidenote, the problem seems to start "by itself" with drm-kmod-61. I'm here using 66 but I switched only since I ran this topic.

Erichans · Dec 20, 2025

Erichans said:

Excerpt from that dmesg output:

Rich (BB code):

nvidia0: <NVIDIA GeForce RTX 2070> on vgapci0
vgapci0: child nvidia0 requested pci_enable_io
vgapci0: child nvidia0 requested pci_enable_io
nvidia-modeset: Loading NVIDIA Kernel Mode Setting Driver for UNIX platforms  580.105.08  Wed Oct 29 22:04:36 UTC 2025
[drm] [nvidia-drm] [GPU ID 0x00000100] Loading driver
hdacc2: Unexpected unsolicited response with tag 63: ffffffff
sysctl_add_oid: can't re-use a leaf (hw.dri.debug)!
sysctl_add_oid: can't re-use a leaf (hw.dri.vblank_offdelay)!
sysctl_add_oid: can't re-use a leaf (hw.dri.timestamp_precision)!
[drm] Initialized nvidia-drm 0.0.0 20160202 for nvidia0 on minor 1

Perceval said:
Thanks to you for these !
Erichans : You're right, my current rc.conf is the following :

Code:

kld_list="acpi_video i915kms nvidia-modeset nvidia-drm cuse fusefs coretemp cpuctl"

If you "shrink" this to something like, at its minimum, kld_list="nvidia-modeset" (excluding nvidia-drm) and see if the quoted dmesg output does now not show the highlighted message lines (not starting Xorg of course), then, I think, it is safe to say that the highlighted message lines are clearly not linked to the Nvidia-proprietary nvidia-modeset DRM/KMS driver.

Perceval · Dec 20, 2025

Erichans said:
If you "shrink" this to something like, at its minimum, kld_list="nvidia-modeset" (excluding nvidia-drm) and see if the quoted dmesg output does now not show the highlighted message lines (not starting Xorg of course), then, I think, it is safe to say that the highlighted message lines are clearly not linked to the Nvidia-proprietary nvidia-modeset DRM/KMS driver.

Well, it's very simple : if I run with only kld_list="nvidia-modeset", X does not start. That's something I wasn't expecting to be honest, as "the good old method" was this one if I'm correct. As I said, running only i915kms starts X on the laptop screen (without acceleration, it goes to llvmpipe just like it currently does ; no screen on the external monitor), running only nvidia-drm starts X on the external monitor WITH hardware acceleration (no screen on the laptop), running only nvidia-modeset makes X not to start. Both running (i915kms and nvidia-drm) makes X to start on my two screens, works fine except llvmpipe.

Here is Xorg.0.log when I run without i915kms in the kld_list (so, it starts X on my external monitor only, WITH hardware acceleration working) : https://termbin.com/77m3

Thanks again

T-Aoki · Dec 20, 2025

Erichans said:
T-Aoki , do you happen to know if the above loader setting is relevant (or not) to the OP's NVIDIA GeForce RTX 2070 ?

Unlikely.
As far as I know, this is applicable to RTX 5xxxx (Blackwell generation of architecture). But the reports are mostly something like "RTX 1xxx was OK, but doesn't start once replacing it to RTX 5xxx" and "fixed by setting the tunable".

T-Aoki · Dec 20, 2025

Perceval said:
Well, it's very simple : if I run with only kld_list="nvidia-modeset", X does not start. That's something I wasn't expecting to be honest, as "the good old method" was this one if I'm correct. As I said, running only i915kms starts X on the laptop screen (without acceleration, it goes to llvmpipe just like it currently does ; no screen on the external monitor), running only nvidia-drm starts X on the external monitor WITH hardware acceleration (no screen on the laptop), running only nvidia-modeset makes X not to start. Both running (i915kms and nvidia-drm) makes X to start on my two screens, works fine except llvmpipe.

Here is Xorg.0.log when I run without i915kms in the kld_list (so, it starts X on my external monitor only, WITH hardware acceleration working) : https://termbin.com/77m3

Thanks again

I'm confused about your log on termbin.
Is it of "using nvidia-drm.ko but dropping i915.ko"? Or "using nvidia-modeset.ko (automatically pulling in nvidia.ko, though) alone"?

For the latter (doesn't match the log, though), X would try to load nv driver and does NOT find nvidia driver and does NOT work, as X does NOT know about nvidia proprietary driver unless proper configuration in monolithic /etc/X11/xorg.conf (or finegrained ones in /usr/local/etc/X11/xorg.conf.d.

Here, x11/nvidia-xconfig would help generating monolithic one, if you DON'T have iGPU enabled (mean, non-Optimus or disabled iGPU via legacy BIOS / UEFI firmware). But wouldn't work if you have iGPU enabled.

Perceval · Dec 20, 2025

T-Aoki said:
I'm confused about your log on termbin.
Is it of "using nvidia-drm.ko but dropping i915.ko"? Or "using nvidia-modeset.ko (automatically pulling in nvidia.ko, though) alone"?

For the latter (doesn't match the log, though), X would try to load nv driver and does NOT find nvidia driver and does NOT work, as X does NOT know about nvidia proprietary driver unless proper configuration in monolithic /etc/X11/xorg.conf (or finegrained ones in /usr/local/etc/X11/xorg.conf.d.

Here, x11/nvidia-xconfig would help generating monolithic one, if you DON'T have iGPU enabled (mean, non-Optimus or disabled iGPU via legacy BIOS / UEFI firmware). But wouldn't work if you have iGPU enabled

Well, as of today, I think that there might be a problem on drm-kmod or maybe nvidia-kmod side.
As stated, when running *only* nvidia part, everything goes fine.
The i915kms, which I need in my setup because it manages my laptop screen, seems to be problematic. There's no way for X to start if I run only from it (I mean, testing without taking care of nvidia stuff, kldlist with i915kms only) : it will start on llvmpipe (removing drm-kmod) or it will crash (drm-kmod is installed, or if I try to force modesetting on it with a custom drivers.conf file) : connection refused / cannot run in framebuffer mode.

Back in 2023-2024 when the dual screen wasn't working at all, I used to use only the main screen (i915kms) and i had no performance issue ; I was running in accelerated mode, using drm-kmod. Now, drm-kmod can't run the laptop screen, even by removing anything that's related to Nvidia (that was my 2023-2024 setup).
Does anyone know if something changed here...?

I'm keeping hope to find

Sadly, on my setup, no way to disable the iGPU.

Edit : the problem might appear during october, maybe with p5 ? The nvidia-driver was 580.82.07_1, which, if I'm not wrong, was working fine.

Perceval · Jan 6, 2026

Hi, happy new year !
Some (not really) news : from your previous messages, I noted that doing git checkout on my /usr/src, I was up-to-date against origin/releng/14.3, which is NOT GOOD.
I've cleaned the whole folder, updated everything to origin/releng/15.0, fully wiped and reconstructed /usr/ports, rebuilt x11/nvidia-driver, graphics/nvidia-drm-66-kmod and x11/nvidia-kmod, sadly it's still stuck, no acceleration.