Created attachment 262576 [details] coredump.txt I am using a Thinkpad X1, with a nvidia RTX 3080 and an integrated Intel Gpu. nvidia-drm has stopped working on 15-current. Kernel module loads with errors and then crashes on windowmanager start (hyprland) I have attached kldload output and crashdump. If you need more info, i am glad to provide it.
Created attachment 262577 [details] kldload output
main (aka 15-Current) gets offensive change at commit 4dd828c80828637452a8a4e07a64e294c82e5d8b. https://cgit.freebsd.org/src/commit/?id=4dd828c80828637452a8a4e07a64e294c82e5d8b And x11/nvidia-driver, which is required by graphics/nvidia-drm-61-kmod (also by -66-kmod, too) is fixed by commit 9302fb05a0c6599bbe8963ff5201fd3b99994535 on main branch (aka latest) of ports tree. https://cgit.freebsd.org/ports/commit/?id=9302fb05a0c6599bbe8963ff5201fd3b99994535 This is merged to quarterly 2025Q3 by commit 786efa1020bf0f0044da006c7312795aa397a474. https://cgit.freebsd.org/ports/commit/?id=786efa1020bf0f0044da006c7312795aa397a474 According to the coredump.txt, your kernel should have the commit,so my assumption is that your ports tree is NOT up-to-date, at least behind the above mentioned commit, right? If so, update ports tree or revert back your src to any point BEFORE 65ed1a035ceb8f7c323c0bc0c7344a7fa7cadc9f would fix this. Note that no bump was done at the time 4dd828c80828637452a8a4e07a64e294c82e5d8b nor commit next to it, I needed to use previous bump, so around 10 days of broken timespan persists.
i did not use the ports-tree at all, i installed everything via package, nvidia-drm comes from Freebsd-kmods and is -latest: https://pkg.FreeBSD.org/FreeBSD:15:amd64/kmods_latest that should match?
(In reply to Daniel from comment #3) Unfortunately, none of x11/nvidia-driver* nor graphics/nvidia-drm-*-kmod* are provided by kmod repo now. You need to build yourself via ports, not pkg, unless the approach I proposed on Bug 288314 is accepted by admins of kmod builder and the patch is fixed up / landed. Currently no reaction from them, so the only way is building from ports, or wait for pkgs on official (main) repo is rebuilt (not 100% sure but possibly for 15-Current).
thanks, this can be closed then. i assumed these came from kmods: nvidia-driver-570.169.1500051 nvidia-drm-61-kmod-570.169.1500051_2 but in fact, they are coming from pkg:latest. I'll install the ports-tree and build nvidia-driver and nvidia-drm from there. Thank you for help
i tried building nvidia-driver and drm-61 and drm-66 from ports, i just pulled from git, but with no luck. nvidia-drm-66 - is buildable but not loadable nvidia-drm-61 is coredumping I'm on pkgbase flavour of FreeBSD-main, i'll attach the kldload and coredump.
Created attachment 262590 [details] kldload nvidia-drm from graphics/nvidia-drm-66-kmod
Created attachment 262591 [details] coredump from graphics/nvidia-drm-61-kmod
In your kldload output, > linker_load_file: /boot/modules/nvidia-drm.ko - unsupported file type This typically happens when version mis-matches occurs between kernel and modules. I assumed (as you're using 15-Current) you're building src locally, so also assumed your src tree and running kernel 100% matches. But this alone usually doesn't cause coredumps. Simply fails to load. So make 100% sure your src tree (required to build kernel modules regardless from src or ports). If you've installed via snapshot image and didn't installed src distribution, then, pulled src repo later (git or gitup, usually), there can be mis-matches. If you're pulling src using git, you can checkout exact the same commit using `git checkout` from the same or newer state. And for crashes, if you want nvidia-drm.ko to work, all of the 3 below needs to be in sync. 1. x11/nvidia-driver[-devel] 2. exactly one of graphics/drm-[61|66]-kmod for 15-Current 3. exactly one of graphics/nvidia-drm-[61|66]-kmod[-devel] nvidia-drm.kmod depends on nvidia-modeset.ko and nvidia-modeset.ko depends on nvidia-ko. This is because nvidia.ko is the module actually controlling supported nvidia GPU, nvidia-modeset.ko is a wrapper to provide basic modesetting interface using nvidia.ko and nvidia-drm.ko is a wrapper to provide DRM interface using nvidia-modeset.ko. So these must be in exactly the same version (currently, 570.172.08). And nvidia-drm.ko also requires modules provided by graphics/drm-[61|66]-kmod of the version it used for building, as nvidia doesn't provide sources common to Intel and AMD GPUs, and we do not build kmods provided by graphics/drm-*-kmod (buiding twice is just a silly mess). If any of them are out of sync, crashes can be happen, especially you (accidentally or intentionally) mangled 61 and 66, or master ports and -devel variant. x11/nvidia-driver-devel and graphics/nvidia-drm-*-kmod-devel is basically for New Feature Branch (NFB] of driver set, currently at 575.64.05. https://www.nvidia.com/en-us/drivers/unix/ Another reason of crash would be GPU-related kmods are loaded via /boot/loader.conf. This could cause undefined behavior (as loaded huge kmode could be truncated). If you're customising kernel configuration, there could be risks for breakage, too.
> So make 100% sure your src tree (required to build kernel modules regardless > from src or ports). If you've installed via snapshot image and didn't installed > src distribution, then, pulled src repo later (git or gitup, usually), there can > be mis-matches. If you're pulling src using git, you can checkout exact the same > commit using `git checkout` from the same or newer state. I assumed, that with pkgbase will take care of that, but that does not seem to be the case: root@hyprx1:~ # pkg info FreeBSD-src* FreeBSD-src-15.snap20250721134219 FreeBSD-src-sys-15.snap20250721123655 root@hyprx1:~ # pkg info FreeBSD-kern* FreeBSD-kernel-generic-15.snap20250721091450 FreeBSD-kernel-generic-dbg-15.snap20250721091450 so that's more of a pkgbase than an nvidia bug, i guess. I had the hope to not recompile the whole kernel and base myself. I just quickly checked that the "FreeBSD_version" matches: root@hyprx1:~ # uname -KU 1500053 1500053 root@hyprx1:~ # grep FreeBSD_version /usr/src/sys/sys/param.h #undef __FreeBSD_version #define __FreeBSD_version 1500053
I'm not using PkgBase, nor installer but src upgrades. So don't know how PkgBase handles src tree. *The last time I used installer as installer (means, not for use as live system), it was NOT current bsdinstall, but old sysinstall. So, to be sure, managing src tree with devel/git would be recommended. IIUC, net/gitup is to keep working tree of git repo simply up-to-date and doesn't use .git diretory (it even disallows the existence!). So not fits to going commits back and force, or make work tree the state of specific commit. Note that to start managing src (and/or ports) tree with git, the directory must be empty before cloning. So would be net/gitup. Differences between devel/git and net/gitup is well summerised here. https://github.com/johnmehr/gitup
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=03b214a35db1ebdc7575cad8d695c65daf2817bf commit 03b214a35db1ebdc7575cad8d695c65daf2817bf Author: Austin Shafer <ashafer@FreeBSD.org> AuthorDate: 2025-10-28 18:08:01 +0000 Commit: Austin Shafer <ashafer@FreeBSD.org> CommitDate: 2025-10-29 20:58:41 +0000 linuxkpi: gracefully handle page lookup failure in lkpi_vmf_insert_pfn_prot_locked Currently lkpi_vmf_insert_pfn_prot_locked will check the page iter to find a usage of the page. If no page was found, it continues on to try using PHYS_TO_VM_PAGE() to get a page. Currently it does not check if a valid page was found before passing it to vm_page_busy_acquire, which can cause a kernel page fault as vm_page_busy_acquire expects a valid page pointer. This can easily be triggered while starting KDE6 in wayland mode, which many users have been reporting. With this change plasma6 starts properly in wayland mode. Sponsored by: NVIDIA PR: 288565 Reviewed by: markj, kbowling (mentor) Differential Revision: https://reviews.freebsd.org/D53412 sys/compat/linuxkpi/common/src/linux_page.c | 4 ++++ 1 file changed, 4 insertions(+)
A commit in branch stable/15 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=452b92fadae16e30f815203863bb9dd92ddff762 commit 452b92fadae16e30f815203863bb9dd92ddff762 Author: Austin Shafer <ashafer@FreeBSD.org> AuthorDate: 2025-10-28 18:08:01 +0000 Commit: Austin Shafer <ashafer@FreeBSD.org> CommitDate: 2025-12-08 18:08:32 +0000 linuxkpi: gracefully handle page lookup failure in lkpi_vmf_insert_pfn_prot_locked Currently lkpi_vmf_insert_pfn_prot_locked will check the page iter to find a usage of the page. If no page was found, it continues on to try using PHYS_TO_VM_PAGE() to get a page. Currently it does not check if a valid page was found before passing it to vm_page_busy_acquire, which can cause a kernel page fault as vm_page_busy_acquire expects a valid page pointer. This can easily be triggered while starting KDE6 in wayland mode, which many users have been reporting. With this change plasma6 starts properly in wayland mode. Sponsored by: NVIDIA PR: 288565 Reviewed by: markj, kbowling (mentor) Differential Revision: https://reviews.freebsd.org/D53412 (cherry picked from commit 03b214a35db1ebdc7575cad8d695c65daf2817bf) sys/compat/linuxkpi/common/src/linux_page.c | 4 ++++ 1 file changed, 4 insertions(+)
A commit in branch stable/14 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=5f9b7cde517ecd0d821b9730f37ebbdc25dbd349 commit 5f9b7cde517ecd0d821b9730f37ebbdc25dbd349 Author: Austin Shafer <ashafer@FreeBSD.org> AuthorDate: 2025-10-28 18:08:01 +0000 Commit: Austin Shafer <ashafer@FreeBSD.org> CommitDate: 2025-12-08 22:26:39 +0000 linuxkpi: gracefully handle page lookup failure in lkpi_vmf_insert_pfn_prot_locked Currently lkpi_vmf_insert_pfn_prot_locked will check the page iter to find a usage of the page. If no page was found, it continues on to try using PHYS_TO_VM_PAGE() to get a page. Currently it does not check if a valid page was found before passing it to vm_page_busy_acquire, which can cause a kernel page fault as vm_page_busy_acquire expects a valid page pointer. This can easily be triggered while starting KDE6 in wayland mode, which many users have been reporting. With this change plasma6 starts properly in wayland mode. Sponsored by: NVIDIA PR: 288565 Reviewed by: markj, kbowling (mentor) Differential Revision: https://reviews.freebsd.org/D53412 Fixed conflicts during MFC, re-reviewed by kbowling (cherry picked from commit 03b214a35db1ebdc7575cad8d695c65daf2817bf) sys/compat/linuxkpi/common/src/linux_page.c | 2 ++ 1 file changed, 2 insertions(+)
It is fixed for me now, thanks!