Date: Tue, 07 Apr 2026 15:25:27 +0000 From: Minsoo Choo <minsoochoo0122@proton.me> To: Jan Martin Mikkelsen <janm@transactionware.com> Cc: current@freebsd.org Subject: Re: Panic: cache_vop_rename: lingering negative entry Message-ID: <9c-3l5dvbjve6vGZbCL2k2grqQoncLsoUv3HI55UrDfP0MPUyMqrdFP6eUe8TFA-lkzDqZqE13HtwfhvLml6OP9fl3CIaptORG-SjYWrusU=@proton.me> In-Reply-To: <2016260A-5C07-45EE-87CA-73918BA16E83@transactionware.com>
index | next in thread | previous in thread | raw e-mail
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? -- Minsoo Choohome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9c-3l5dvbjve6vGZbCL2k2grqQoncLsoUv3HI55UrDfP0MPUyMqrdFP6eUe8TFA-lkzDqZqE13HtwfhvLml6OP9fl3CIaptORG-SjYWrusU=>