On Tue, 27 Sep 2005, Rob Watt wrote:
this is the piece of code that was referenced by the ip:
(gdb) l *0xffffffff803b88ca
0xffffffff803b88ca is in nfsrv_lookup (/usr/src/sys/nfsserver/nfs_serv.c:670).
665 NFSD_UNLOCK();
666 mtx_lock(&Giant); /* VFS */
667 if (dirp)
668 vrele(dirp);
669 NDFREE(&nd, NDF_ONLY_PNBUF);
670 if (ndp->ni_startdir)
671 vrele(ndp->ni_startdir);
672 if (ndp->ni_vp)
673 vput(ndp->ni_vp);
674 mtx_unlock(&Giant); /* VFS */
we are not running nfsd (although we do use nfs and nfsiod), and none of
our processes should have been accessing nfs. Our processes are run from
an nfs mount but do not access any nfs mounted files.
That code is in the NFS server lookup code, so should be called as a
result of a lookup by a remote client. If the NFS server is not in use on
the machine, this is most likely this is a quirk of gdb and instruction
pointers, a run-time kernel/compile-time kernel mismatch, or something
really nasty. ndp should really never be NULL there, as it's used
frequently prior to that point. Let's hope for one of the former few
options.
Do you have a testbed or set of test hosts set up so you can
non-disruptively test change sets, btw?
yes we have 3 dual dual-core machines and 1 dual single-core machine
that we can use to test with.
Great. As mentioned I'll be offline for about the next 48 hours, but back
after then. If we can get a nice clean crash out of this, would really be
best. If it's top panicking, it could well be due to a bug in the process
monitoring code, in kern_proc. We've run into bugs a few times there in
the past, generally associated with threading or races in process
creation/teardown, in which partially initialized (or torn down) processes
are accessed by another thread and are in an unexpected state.
Thanks,
Robert N M Watson
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
