Date: Fri, 13 Nov 1998 14:53:07 -0800 From: Mike Smith <mike@smith.net.au> To: Andrew Gallatin <gallatin@cs.duke.edu> Cc: freebsd-current@FreeBSD.ORG Subject: Re: nfs_rename() panic Message-ID: <199811132253.OAA00889@dingo.cdrom.com> In-Reply-To: Your message of "Fri, 13 Nov 1998 15:16:25 EST." <13900.36889.417269.577335@grasshopper.cs.duke.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
> > I'm getting a 100% reproducible panic in nfs_rename. This is on a > system with sources cvsupped this morning about 10am EST. NFS is > compiled in statically, not an LKM. The new access caching stuff is > off. This panic does not happen in a kernel built from 1 week old > sources. > > The panic happens when trn renames .newsrc in a filesystem mounted via > NFSv3/tcp from a Solaris 2.5 server. > > I've appended a partial stack trace. The problem seems to be that > fvp->v_data is somehow becoming NULL. Weird. I can't work out why the nfsnode would have been revoked at that point, but it looks like it must have. There are some other bugs in the code though, as tvp may be NULL if it was open and has been sillyrenamed. I'll add some sanity checking, but it would be useful if you could check that it's definitely fvp->v_data that's NULL. Thanks for the report. > Cheers, > > Drew > ------------------------------------------------------------------------------ > Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin > Duke University Email: gallatin@cs.duke.edu > Department of Computer Science Phone: (919) 660-6590 > > > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x7c > fault code = supervisor read, page not present > instruction pointer = 0x8:0xf01b0384 > stack pointer = 0x10:0xf65f6e78 > frame pointer = 0x10:0xf65f6e90 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 366 (trn) > interrupt mask = > > syncing disks... 8 8 3 done > <...> > #8 0xf01f021c in trap_pfault (frame=0xf65f6e3c, usermode=0) > at ../../i386/i386/trap.c:772 > #9 0xf01efe6f in trap (frame={tf_es = 16, tf_ds = 16, tf_edi = -161754304, > tf_esi = 0, tf_ebp = -161517936, tf_isp = -161517980, tf_ebx = 0, > tf_edx = -161475840, tf_ecx = -260659200, tf_eax = -161452960, > tf_trapno = 12, tf_err = 0, tf_eip = -266665084, tf_cs = 8, > tf_eflags = 66199, tf_esp = -161754304, tf_ss = -161517836}) > at ../../i386/i386/trap.c:396 > #10 0xf01b0384 in nfs_rename (ap=0xf65f6eb0) at ../../nfs/nfs_vnops.c:1676 > #11 0xf016b436 in rename (p=0xf657b340, uap=0xf65f6f94) at vnode_if.h:583 > > (kgdb) frame 10 > #10 0xf01b0384 in nfs_rename (ap=0xf65f6eb0) at ../../nfs/nfs_vnops.c:1676 > 1676 VTONFS(fvp)->n_modestamp = 0; > (kgdb) p fvp->v_data > $1 = (void *) 0x0 > (kgdb) p fvp > $2 = (struct vnode *) 0xf6601300 > (kgdb) p &fvp->v_data > $3 = (void **) 0xf660137c > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199811132253.OAA00889>