From nobody Tue Apr 7 15:25:27 2026 X-Original-To: current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4fqqlN4WzTz6YRTZ for ; Tue, 07 Apr 2026 15:25:36 +0000 (UTC) (envelope-from minsoochoo0122@proton.me) Received: from mail-10628.protonmail.ch (mail-10628.protonmail.ch [79.135.106.28]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "protonmail.com", Issuer "R13" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4fqqlN0fMxz3mRY for ; Tue, 07 Apr 2026 15:25:36 +0000 (UTC) (envelope-from minsoochoo0122@proton.me) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me; s=protonmail; t=1775575533; x=1775834733; bh=2UfQYPSmPNRpI1A60cmi3s4e4MP0vAWY5oJzb6qlAkM=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=cHJAOEbdq3lN83bnJ0q5EWL6fcRk/ZmaJw28Q15E4BlvV+Jp/+9BFCiiyX0vF4h/z CjsvA2SoAdQIKGkHPrMvvH+4D7E8YbZvTDTShtfDpuKdiOfzEijxULgSuDpyN1VYax 7uqo6uUYm/DKAO+OtDvNo0IXA63pKYCi9XrW0dqXeHImwx1HG4Y55eXTHa7bgNzDlO pusjVSANsrU4D3pQFLtMtrvxSVeUU8hgwMp3/otIQDVmVnyR8pNGYOLnCS5d8dN560 oQJBLx1fOGRAGPohQXeXXg5iu6t6Ziw1ozKTf6Sovp9DkaNtAciBqTEVc1WVDd0ZfH yDGQFaZj6/thA== Date: Tue, 07 Apr 2026 15:25:27 +0000 To: Jan Martin Mikkelsen From: Minsoo Choo 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> References: <2016260A-5C07-45EE-87CA-73918BA16E83@transactionware.com> Feedback-ID: 45891198:user:proton X-Pm-Message-ID: 021d5b4503d5f12e5b7f5c08488d88fcf94b60d0 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:62371, ipnet:79.135.106.0/24, country:CH] X-Rspamd-Queue-Id: 4fqqlN0fMxz3mRY X-Spamd-Bar: ---- On Wednesday, April 8th, 2026 at 12:03 AM, Jan Martin Mikkelsen wrote: > Hi, >=20 > I am consistently getting the panic below while building lang/perl5.42. T= his is the command from the perl build that triggers the panic: >=20 > /usr/bin/strip /ports-work/usr/ports/lang/perl5.42/work/stage/usr/local/b= in/perl5.42.0 >=20 > CURRENT on aarch64, with a kernel from last week, also with a later one f= rom the weekend. A kernel from mid-January worked fine. >=20 > I can reproduce on demand, no parallelism in the build required. >=20 > Does this look familiar to anyone? >=20 > panic: cache_vop_rename: lingering negative entry > cpuid =3D 4 > time =3D 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] >=20 > Regards, >=20 > Jan M. >=20 >=20 >=20 The panic message says the kernel panic is triggered by zfs. KASSERT at htt= ps://github.com/freebsd/freebsd-src/blob/cff675e83cdb6c9027e94df9d010439e42= e27dee/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 y= ou run zfs scrub on the file system? -- Minsoo Choo