`vainfo` is enough to trigger a panic. Same with drm-66 and drm-61. % pkg info -a | grep nvidia linux-nvidia-libs-580-580.173.02 NVIDIA graphics libraries and programs (Linux) nvidia-driver-580-580.173.02 NVIDIA graphics driver userland nvidia-drm-latest-kmod-580-580.173.02.1600019_1 NVIDIA DRM Kernel Module nvidia-kmod-580-580.173.02.1600019 NVIDIA graphics driver kernel module % uname -aK FreeBSD 16.0-CURRENT main-n287941-d3a0bf0a79ef GENERIC-NODEBUG amd64 1600019 kgdb (see attachment for detail): (kgdb) bt #0 __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:57 #1 doadump (textdump=textdump@entry=0) at /usr/src/sys/kern/kern_shutdown.c:399 #2 0xffffffff804bfd8a in db_dump (dummy=<optimized out>, dummy2=<optimized out>, dummy3=<optimized out>, dummy4=<optimized out>) at /usr/src/sys/ddb/db_command.c:596 #3 0xffffffff804bfc3a in db_command (last_cmdp=<optimized out>, cmd_table=<optimized out>, dopager=true) at /usr/src/sys/ddb/db_command.c:508 #4 0xffffffff804bf85d in db_command_loop () at /usr/src/sys/ddb/db_command.c:555 #5 0xffffffff804c33c0 in db_trap (type=<optimized out>, code=<optimized out>) at /usr/src/sys/ddb/db_main.c:267 #6 0xffffffff80c5f0f5 in kdb_trap (type=type@entry=3, code=code@entry=0, tf=tf@entry=0xfffffe03a8cf1570) at /usr/src/sys/kern/subr_kdb.c:790 #7 0xffffffff8115cdf1 in trap (frame=<optimized out>) at /usr/src/sys/amd64/amd64/trap.c:702 #8 <signal handler called> #9 kdb_enter (why=<optimized out>, msg=<optimized out>) at /usr/src/sys/kern/subr_kdb.c:556 #10 0xffffffff80c0ae89 in vpanic (fmt=<optimized out>, ap=ap@entry=0xfffffe03a8cf17a0) at /usr/src/sys/kern/kern_shutdown.c:962 #11 0xffffffff80c0ad03 in panic (fmt=0xffffffff81aa6be0 <vt_conswindow+16> "\350\0312\201\377\377\377\377") at /usr/src/sys/kern/kern_shutdown.c:887 #12 0xffffffff8115d4d8 in trap_fatal (frame=<optimized out>, eva=<optimized out>) at /usr/src/sys/amd64/amd64/trap.c:1031 #13 0xffffffff8115d4d8 in trap_pfault (frame=0xfffffe03a8cf1830, usermode=false, signo=<optimized out>, ucode=<optimized out>) #14 <signal handler called> #15 0xffffffff8399ef86 in drm_open_helper () from /boot/modules/drm.ko #16 0xffffffff8399f185 in drm_open () from /boot/modules/drm.ko #17 0xffffffff839937fd in drm_stub_open () from /boot/modules/drm.ko #18 0xffffffff80eabe21 in linux_dev_fdopen (dev=<optimized out>, fflags=<optimized out>, td=0xfffff81bffc46d80, file=0xfffff805563ac780) at /usr/src/sys/compat/linuxkpi/common/src/linux_compat.c:774 #19 0xffffffff80a710b4 in devfs_open (ap=0xfffffe03a8cf1a70) at /usr/src/sys/fs/devfs/devfs_vnops.c:1322 #20 0xffffffff81231869 in VOP_OPEN_APV (vop=0xffffffff81aab5a0 <devfs_specops>, a=a@entry=0xfffffe03a8cf1a70) at vnode_if.c:411 #21 0xffffffff80d29220 in VOP_OPEN (vp=0xfffff81ac28de1b8, mode=3, cred=0xfffff81a631d3900, td=<optimized out>, fp=<optimized out>) at ./vnode_if.h:256 #22 vn_open_vnode (vp=0xfffff81ac28de1b8, fmode=fmode@entry=3, cred=cred@entry=0xfffff81a631d3900, td=td@entry=0xfffff805563ac780, fp=<optimized out>) at /usr/src/sys/kern/vfs_vnops.c:495 #23 0xffffffff80d28b05 in vn_open_cred (ndp=ndp@entry=0xfffffe03a8cf1cc8, flagp=flagp@entry=0xfffffe03a8cf1ca4, cmode=cmode@entry=0, vn_open_flags=vn_open_flags@entry=16, cred=0xfffff81a631d3900, fp=0xfffff8155448de60) at /usr/src/sys/kern/vfs_vnops.c:378 #24 0xffffffff80d1d549 in openatfp (td=0xfffff805563ac780, dirfd=<optimized out>, path=<optimized out>, pathseg=pathseg@entry=UIO_USERSPACE, flags=3, mode=<optimized out>, fpp=0x0) at /usr/src/sys/kern/vfs_syscalls.c:1266 #25 0xffffffff80d1d24d in kern_openat (dirfd=0, path=0x0, pathseg=UIO_USERSPACE, flags=0, mode=-373463024, td=<optimized out>) at /usr/src/sys/kern/vfs_syscalls.c:1354 #26 sys_openat (td=<optimized out>, uap=<optimized out>) at /usr/src/sys/kern/vfs_syscalls.c:1158 #27 0xffffffff8115e01e in syscallenter (td=0xfffff805563ac780) at /usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:165 #28 amd64_syscall (td=0xfffff805563ac780, traced=0) at /usr/src/sys/amd64/amd64/trap.c:1278 #29 <signal handler called> #30 0x000000082bc5f42a in ?? () Backtrace stopped: Cannot access memory at address 0x820ccdb08 % kldstat | grep -E 'drm|nvi' 12 1 0xffffffff8395e000 15a10 nvidia-drm.ko 13 1 0xffffffff83974000 9e420 drm.ko 18 2 0xffffffff83c00000 6075420 nvidia.ko 20 1 0xffffffff83a5e000 1662f8 nvidia-modeset.ko
Created attachment 273439 [details] registers and linux_dev_fdopen args+local output
First of all, assuming you're building at least all kmods using ports as you're on main branch of base, are you sure: *Your running kernel and source tree 100% in sync. *You've rebuilt all kmod ports [at least graphics/nvidia-drm-*-kmod-580 (you've stated 61, 66 and latest) and corresponding graphics/drm-*-kmod] using current src tree as described above. And looking into your backtrace, panic seem to happen in drm.ko, not in nvidia-drm.ko, nvidia-modeset.ko nor nvidia.ko. So I've not asked your GPU is supported by 580 series or not.
(In reply to Tomoaki AOKI from comment #2) 1. They're in sync. 2. drm-latest-kmod-6.12.1600019 was built using the same commit hash. > And looking into your backtrace, panic seem to happen in drm.ko, not in nvidia-drm.ko, nvidia-modeset.ko nor nvidia.ko. So I've not asked your GPU is supported by 580 series or not. I'm trying to provide as much information as I can to help others see the problem. My graphics card is only supported up to 580, and after 595.84 the driver ignores it. I'll rebuild the graphics/nvidia-drm-latest-kmod-580 and x11/nvidia-kmod-580 packages myself to see what happens. Thank you
(In reply to Pouria Mousavizadeh Tehrani from comment #3) x11/nvidia-kmod* are relatively robust with kernel changes (in some cases, KBIs are changed even if KPI is unchanged, but it's relatively rare), as these do NOT depend on LinuxKPI. OTOH, graphics/drm-*-kmod and graphics/nvidia-drm-*-kmod*, which depend on LinuxKPI, are quite keen to LinuxKPI changes and basically require rebuilds if there are any commit to LinuxKPI after previous builds. So rebuilding everytime base is updated is strongly recommended to be safe.