rob.watt at gmail.com
Tue Sep 27 14:22:49 PDT 2005
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).
666 mtx_lock(&Giant); /* VFS */
667 if (dirp)
669 NDFREE(&nd, NDF_ONLY_PNBUF);
670 if (ndp->ni_startdir)
672 if (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.
More information about the freebsd-hackers