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



Reply via email to