Re: Panic: cache_vop_rename: lingering negative entry
- In reply to: Minsoo Choo : "Re: Panic: cache_vop_rename: lingering negative entry"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Tue, 07 Apr 2026 18:21:55 UTC
On 7 Apr 2026, at 17:25, Minsoo Choo <minsoochoo0122@proton.me> wrote: > > On Wednesday, April 8th, 2026 at 12:03 AM, Jan Martin Mikkelsen <janm@transactionware.com> wrote: > >> Hi, >> >> I am consistently getting the panic below while building lang/perl5.42. This is the command from the perl build that triggers the panic: >> >> /usr/bin/strip /ports-work/usr/ports/lang/perl5.42/work/stage/usr/local/bin/perl5.42.0 >> >> CURRENT on aarch64, with a kernel from last week, also with a later one from the weekend. A kernel from mid-January worked fine. >> >> I can reproduce on demand, no parallelism in the build required. >> >> Does this look familiar to anyone? >> >> panic: cache_vop_rename: lingering negative entry >> cpuid = 4 >> time = 1775410763 >> 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 >> cache_vop_rename() at cache_vop_rename+0xb0 >> zfs_do_rename() at zfs_do_rename+0xafc >> zfs_freebsd_rename() at zfs_freebsd_rename+0x5c >> VOP_RENAME_APV() at VOP_RENAME_APV+0x44 >> kern_renameat () at kern_renameat+0x574 >> do_el0_sync() at do_el0_sync+0x5f8 >> handle_el0_sync() at handle_el0_sync+0x4c >> --- exception, esr 0x56000000 >> KDB: enter: panic >> [ thread pid 81230 tid 101738 ] >> Stopped at kdb_enter+0x48: str xzr, [x19, #3072] >> >> Regards, >> >> Jan M. >> >> >> > > The panic message says the kernel panic is triggered by zfs. KASSERT at https://github.com/freebsd/freebsd-src/blob/cff675e83cdb6c9027e94df9d010439e42e27dee/sys/kern/vfs_cache.c#L3093 triggered the panic, but HOW (not WHERE) the panic occurred can only be determined by observing the crash dump. > > I assume race conditions happened during the I/O heavy workload, but at the same time you said no parallelism in build required. To make sure, could you run zfs scrub on the file system? The filesystems were scrubbed multiple times while I was investigating this problem. I just re-ran the test after a scrub, and yes, it panics. I don’t think there is a lot of I/O involved. Reboot, run “make build” on lang/perl5.42, then run “make install” and observe the panic. That’s on ZFS, tmpfs/UFS are different. (see other email.) Regards, Jan M.