In message <CAM5tNy5yTAYpvrcLFPJHODZdFJcr_aY1E5Hn3sueovmVYEc=BQ@mail.gmail.c om> , Rick Macklem writes: > --000000000000c0ae7f0635d67be9 > Content-Type: text/plain; charset="UTF-8" > Content-Transfer-Encoding: quoted-printable > > On Thu, May 22, 2025 at 10:48=E2=80=AFPM Cy Schubert <Cy.Schubert@cschubert= > .com> wrote: > > > > Hi, > > > > A couple of my machines have had the following panic. > > > > panic: refcount 0xfffff8008dbdabf4 wraparound^M > > cpuid =3D 3^M > > time =3D 1747977394^M > > KDB: stack backtrace:^M > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > > 0xfffffe008d1474d0^M > > vpanic() at vpanic+0x136/frame 0xfffffe008d147600^M > > panic() at panic+0x43/frame 0xfffffe008d147660^M > > vput() at vput+0x67/frame 0xfffffe008d147680^M > > nfs_lookup() at nfs_lookup+0x3bf/frame 0xfffffe008d1479f0^M > > vop_sigdefer() at vop_sigdefer+0x30/frame 0xfffffe008d147a20^M > > vfs_lookup() at vfs_lookup+0x467/frame 0xfffffe008d147aa0^M > > namei() at namei+0x2ed/frame 0xfffffe008d147b00^M > > vn_open_cred() at vn_open_cred+0x537/frame 0xfffffe008d147c80^M > > openatfp() at openatfp+0x281/frame 0xfffffe008d147dd0^M > > sys_openat() at sys_openat+0x3d/frame 0xfffffe008d147e00^M > > amd64_syscall() at amd64_syscall+0x15a/frame 0xfffffe008d147f30^M > > fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe008d147f3= > 0^M > > --- syscall (499, FreeBSD ELF64, openat), rip =3D 0x82213d96a, rsp =3D > > 0x8209c3518, > > rbp =3D 0x8209c3550 ---^M > > Uptime: 22h48m25s^M > > Dumping 3196 out of 7994 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%.= > .91 > > %^M > > Dump complete^M > > Automatic reboot in 15 seconds - press a key on the console to abort^M > > Rebooting...^M > > > > The panicking machine was the NFS client. The machine was at 30fd79b0c0a3= > . > > The NFS mount was handled by the automounter to mount my home dir from > > another machine. I was rsyncing a copy of src (mistakenly) to the machine= > . > > Some of the files were written to the share before it panicked. The > > underlying filesystem is on ZFS. > I think the attached patch should fix it. When I did the named attribute pa= > tch, > I somehow deleted an initialization of newvp. > > If you can try the patch, let me know if it fixes the problem. > > Thanks for reporting it, rick >
The patch fixes the panic. Thanks for the fix. -- Cheers, Cy Schubert <cy.schub...@cschubert.com> FreeBSD UNIX: <c...@freebsd.org> Web: https://FreeBSD.org NTP: <c...@nwtime.org> Web: https://nwtime.org e^(i*pi)+1=0