daily periodic supplies backtrace. Debuggable?

+Expensive timeout(9) function: 0xb55a7b40(0xbe877000) 0.030583914 s

+Expensive timeout(9) function: 0xb5609ad0(0xbe55b000) 0.479816638 s

+SMP: AP CPU #3 Launched!
+SMP: AP CPU #4 Launched!
+SMP: AP CPU #2 Launched!
+   init_TSC_tc(0)... Timecounter "TSC-low" frequency 1600033566 Hz quality 1000

+ 1st 0xddc1a538 bufwait (bufwait) _at_ /usr/src/sys/kern/vfs_bio.c:3500
+ 2nd 0xbf76f200 dirhash (dirhash) _at_ /usr/src/sys/ufs/ufs/ufs_dirhash.c:281
+GEOM_SCHED: Loading: mp = 0xc01f0084, g_sched_class = 0xc01f0084.
+acquiring duplicate lock of same type: "os.lock_mtx"
+ 1st os.lock_mtx _at_ nvidia_os.c:824
+ 2nd os.lock_mtx _at_ nvidia_os.c:824

+stack backtrace:

+#0 0xb5c22421 at witness_debugger+0x81
+#1 0xb5c22342 at witness_checkorder+0xd12
+#2 0xb5ba4e85 at __mtx_lock_flags+0x95
+#3 0xb752b1dc at os_acquire_spinlock+0x2c
+#4 0xb7262374 at _nv011973rm+0x190

+nvidia-modeset: Allocated GPU:0 (GPU-7838b48e-55e4-f04d-8659-f0d638eef7aa) _at_ PCI:0000:01:00.0
+nvidia-modeset: WARNING: GPU:0: Unable to read EDID for display device VGA-0

+ 1st 0xc2b584a4 ufs (ufs) _at_ /usr/src/sys/kern/vfs_syscalls.c:3364
+ 2nd 0xddd15de8 bufwait (bufwait) _at_ /usr/src/sys/ufs/ffs/ffs_vnops.c:280
+ 3rd 0xc2d3b6dc ufs (ufs) _at_ /usr/src/sys/kern/vfs_subr.c:2600
+#9 0xb5eafc55 at softdep_sync_buf+0xb55
+#11 0xb5ebe4b4 at ffs_fdatasync+0x24
+#12 0xb6192057 at VOP_FDATASYNC_APV+0xd7
+#13 0xb5c9868d at kern_fsync+0x21d
+#14 0xb5c98762 at sys_fdatasync+0x22
+#15 0xb6155fa5 at syscall+0x3b5
+#16 0xb6140ede at Xint0x80_syscall+0x2e

Sometimes is up 24hours.  Often, though, with certain browsers/web pages/ multiple
tabs, complete freeze, in X, or with the 3am periodic scripts, or with an rsync in
an xterm --bwlimit=700 using resources. 

No time to learn GDB vs someday upgrade to amd64... or 12.0-RELEASE or both. I've
small non-RSI exercises which make the reboots not unwelcome... but lose time 
otherwise. 

12.0-CURRENT
r313487
Feb 13 2017 
i386
1200020