freebsd-5.4-stable panics

[Rob Watt]

On 9/27/05, Robert Watson <rwatson at freebsd.org> wrote:
>
> On Tue, 27 Sep 2005, Rob Watt wrote:
>
>
> Is this an SMP box?  If so, could you try compiling options KDB_STOP_NMI
> into your kernel -- you'll also need to set debug.kdb.stop_cpus_with_nmi=1
> in either loader.conf or at runtime with sysctls.

This is a dual-core dual 275 processor box. I have compiled the nmi
options into the kernel and we are now using that to test.

>
> The trap information you've provided indicates that it is likely a data
> NULL pointer dereference in the kernel (faulting address is a small
> increment above NULL).  The instruction pointer looks valid -- if you have
> a debugging copy of the kernel, could you load it into gdb and show me
> what line number / piece of code it's in?  you can use "l
> *ffffffff803b88ca" to generate that, even without a live debugger session
>

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.


>
> 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.

Thanks!

-
Rob Watt