Date: Tue, 27 Sep 2005 17:22:47 -0400 From: Rob Watt <rob.watt@gmail.com> To: Robert Watson <rwatson@freebsd.org> Cc: Rob Watt <rob@hudson-trading.com>, mikep@hudson-trading.com, freebsd-amd64@freebsd.org, freebsd-hackers@freebsd.org, Jason Carroll <jason@hudson-trading.com> Subject: Re: freebsd-5.4-stable panics Message-ID: <cf6c78405092714227722d534@mail.gmail.com> In-Reply-To: <20050927203128.S61419@fledge.watson.org> References: <da4a53d805092310237d732554@mail.gmail.com> <20050925115912.H11229@fledge.watson.org> <20050927140535.G50334@daemon.mistermishap.net> <20050927203128.S61419@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 9/27/05, Robert Watson <rwatson@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= =3D1 > 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 hav= e > 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:67= 0). 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?cf6c78405092714227722d534>