On Apr 9, 2025, at 07:38, Mark Millard <mark...@yahoo.com> wrote: > On Apr 9, 2025, at 06:41, Mark Millard <mark...@yahoo.com> wrote: > >> On Apr 9, 2025, at 05:05, Mark Millard <mark...@yahoo.com> wrote: >> >>> On Apr 6, 2025, at 19:29, Mark Millard <mark...@yahoo.com> wrote: >>> >>>> [Somewhat hand corrected "OCR" conversion of some console image content.] >>>> >>>> VNASSERT failed: vp->v_holdcnt > 0 not true at >>>> /home/pkgbuild/worktrees/main/sys/kern/vfs_subr.c:3391 (vget_finish_ref) >>>> 0xffffa006e11e6a50: type VDIR state VSTATE_CONSTRUCTED op >>>> 0xffff0001a2cb40f0 >>>> usecount 1, writecount 0, refcount 1 seqc users 0 mountedhere 0 >>>> hold count flags () >>>> flags () >>>> lock type ufs: SHARED (count 1) >>>> vp=0xffffa006e11e6a50, lowervp=0xffffa004b074adc0 >>>> panic: condition vp->v_holdcnt > 0 not met at >>>> /home/pkgbuild/worktrees/main/sys/kern/vfs_subr.c:3391 (vget_finish_ref) >>>> cpuid = 8 >>>> time = 1743988125 >>>> KDB: stack backtrace: >>>> db_trace_self() at db_trace_self >>>> db_trace_self_wrapper() at db_trace_self_wrapper+0x38 >>>> vpanic() at vpanic+0x1a0 >>>> panic() at panic+0x48 >>>> vget_finish_ref() at vget_finish_ref+0x1a4 >>>> null_hashget() at null_hashget+0xe4 >>>> null_nodeget() at null_nodeget+0x34 >>>> null_lookup() at null_lookup+0x118 >>>> vfs_lookup() at vfs_lookup+0x3e0 >>>> namei() at namei+0x298 >>>> vn_open_cred() at vn_open_cred+0x450 >>>> openatfp() at openatfp+0x238 >>>> do_el0_sync() at do_el0_sync+0x608 >>>> handle_el0_sync() at handle_el0_sync+0x4c >>>> --- exception, esr 0x56000000 >>>> KDB: enter: panic >>>> [ thread pid 8113 tid 163110 ] >>>> stopped at >>>> kdb_enter+0x48: str xzr, [x19, #2048] >>>> db> >>>> >>>> An issue may be that I'd not yet updated the world yet after >>>> updating and booting the kernel (but no ipfw usage involved): >>>> >>>> # uname -apKU >>>> FreeBSD aarch64-main-pbase 15.0-CURRENT FreeBSD 15.0-CURRENT >>>> main-n276258-c5773d366ecc GENERIC arm64 aarch64 1500035 1500034 >>>> >>>> (That kernel is from installing an official PkgBase set of >>>> kernels, not a personal build.) >>>> >>>> # poudriere jail -l >>>> JAILNAME VERSION OSVERSION ARCH METHOD TIMESTAMP >>>> PATH >>>> release-aarch64 14.2-RELEASE-p1 aarch64 pkgbase >>>> 2025-03-12 21:11:39 /usr/local/poudriere/jails/release-aarch64 >>>> . . . >>>> >>>> The FreeBSD context is Apple Silicon M4 MAX under Parallels >>>> on macOS. FreeBSD had been doing a poudriere-devel based bulk >>>> build. >>>> >>>> >>>> I've no known way to reproduce the panic on demand. >>>> >>>> >>>> Core dumps under Parallels always seem to have backtraces >>>> that are like: >>>> >>>> #0 0xffff0000004b9e48 in doadump (textdump=0) >>>> at /home/pkgbuild/worktrees/main/sys/kern/kern_shutdown.c:404 >>>> #1 0x6fa60000000e9d98 in ?? () >>>> Backtrace stopped: previous frame identical to this frame (corrupt stack?) >>>> >>>> and the rest of the cores are like: >>>> >>>> #0 0xffff0000008703b0 in ipi_stop (dummy=<optimized out>) >>>> at /home/pkgbuild/worktrees/main/sys/arm64/arm64/mp_machdep.c:342 >>>> #1 0xd2e9000000866b68 in ?? () >>>> Backtrace stopped: previous frame identical to this frame (corrupt stack?) >>> >>> Again during a poudriere bulk run: >>> >>> VNASSERT failed: vp->v_holdcnt > 0 not true at >>> /home/pkgbuild/worktrees/main/sys/kern/vfs_subr.c:3391 (vget_finish_ref) >>> 0xffffa001e559fa50: type VDIR state VSTATE_CONSTRUCTED op 0xffff0001a2cd80f0 >>> usecount 3, writecount 0, refcount 1 seqc users 0 mountedhere 0 >>> hold count flags () >>> flags () >>> v_object 0xffffa00875bbe210 ref 0 pages 1 cleanbuf 0 dirtybuf 0 >>> lock type ufs: SHARED (count 2) >>> vp=0xffffa001e559fa50, lowervp=0xffffa0031f0b2a50 >>> panic: condition vp->v_holdcnt > 0 not met at >>> /home/pkgbuild/worktrees/main/sys/kern/vfs_subr.c:3391 (vget_finish_ref) >>> cpuid = 2 >>> time = 1744180482 >>> KDB: stack backtrace: >>> db_trace_self() at db_trace_self >>> db_trace_self_wrapper() at db_trace_self_wrapper+0x38 >>> vpanic() at vpanic+0x1a0 >>> panic() at panic+0x48 >>> vget_finish_ref() at vget_finish_ref+0x1a4 >>> null_hashget() at null_hashget+0xe4 >>> null_nodeget() at null_nodeget+0x34 >>> null_lookup() at null_lookup+0x118 >>> vfs_lookup() at vfs_lookup+0x3e0 >>> namei() at namei+0x298 >>> sys___realpathat() at sys___realpathat+0xb0 >>> do_el0_sync() at do_el0_sync+0x608 >>> handle_el0_sync() at handle_el0_sync+0x4c >>> --- exception, esr 0x56000000 >>> KDB: enter: panic >>> >>> Here: >>> namei() at namei+0x298 >>> sys___realpathat() at sys___realpathat+0xb0 >>> do_el0_sync() at do_el0_sync+0x608 >>> >>> Previously: >>> namei() at namei+0x298 >>> vn_open_cred() at vn_open_cred+0x450 >>> openatfp() at openatfp+0x238 >>> do_el0_sync() at do_el0_sync+0x608 >>> >>> So it looks like what is common is: namei()..vget_finish_ref() >>> >>> vget_finish_ref() at vget_finish_ref+0x1a4 >>> null_hashget() at null_hashget+0xe4 >>> null_nodeget() at null_nodeget+0x34 >>> null_lookup() at null_lookup+0x118 >>> vfs_lookup() at vfs_lookup+0x3e0 >>> namei() at namei+0x298 >>> >>> This one had a v_object output line, the prior one did not. >>> Some counts vary. >> >> VNASSERT failed: vp->v_holdcnt > 0 not true at >> /home/pkgbuild/worktrees/main/sys/kern/vfs_subr.c:3391 (vget_finish_ref) >> 0xffffa00a2a17ec08: type VDIR state VSTATE_CONSTRUCTED op 0xffff0001a2cb40f0 >> usecount 1, writecount 0, refcount 1 seqc users 0 mountedhere 0 >> hold count flags () >> flags () >> v_object 0xffffa00a40b73000 ref 0 pages 0 cleanbuf 0 dirtybuf 0 >> lock type ufs: SHARED (count 2) >> vp=0xffffa00a2a17ec08, lowervp=0xffffa00a2a21f6e0 >> panic: condition vp->v_holdcnt > 0 not met at >> /home/pkgbuild/worktrees/main/sys/kern/vfs_subr.c:3391 (vget_finish_ref) >> cpuid = 7 >> time = 1744203937 >> KDB: stack backtrace: >> db_trace_self() at db_trace_self >> db_trace_self_wrapper() at db_trace_self_wrapper+0x38 >> vpanic() at vpanic+0x1a0 >> panic() at panic+0x48 >> vget_finish_ref() at vget_finish_ref+0x1a4 >> null_hashget() at null_hashget+0xe4 >> null_nodeget() at null_nodeget+0x34 >> null_lookup() at null_lookup+0x118 >> vfs_lookup() at vfs_lookup+0x3e0 >> namei() at namei+0x298 >> kern_statat() at kern_statat+0xf4 >> sys_fstatat() at sys_fstatat+0x2c >> do_el0_sync() at do_el0_sync+0x608 >> handle_el0_sync() at handle_el0_sync+0x4c >> --- exception, esr 0x56000000 >> KDB: enter: panic >> >> Here: >> namei() at namei+0x298 >> kern_statat() at kern_statat+0xf4 >> sys_fstatat() at sys_fstatat+0x2c >> do_el0_sync() at do_el0_sync+0x608 >> >> The *statat() are distinct from the prior examples. >> >> Again the common part is: >> >> vget_finish_ref() at vget_finish_ref+0x1a4 >> null_hashget() at null_hashget+0xe4 >> null_nodeget() at null_nodeget+0x34 >> null_lookup() at null_lookup+0x118 >> vfs_lookup() at vfs_lookup+0x3e0 >> namei() at namei+0x298 > > > The 4th one is another one with: > > Here: > namei() at namei+0x298 > kern_statat() at kern_statat+0xf4 > sys_fstatat() at sys_fstatat+0x2c > do_el0_sync() at do_el0_sync+0x608 > > like the prior one.
I mostly stopped using the debug kernel in contexts were I'd also be doing non-trivial poudriere-devel bulk builds. However, when I did try such I eventually ran into the panic again. I've not bothered with adding more dumps. I've no known way to, on demand, reproduce such quickly in a simple context. === Mark Millard marklmi at yahoo.com
