Date: Fri, 11 Jun 2004 11:20:36 -0400 (EDT) From: Robert Watson <rwatson@freebsd.org> To: othermark <atkin901@yahoo.com> Cc: freebsd-current@freebsd.org Subject: Re: Today's -current panics Message-ID: <Pine.NEB.3.96L.1040611105034.66561A-100000@fledge.watson.org> In-Reply-To: <cacg79$hmh$1@sea.gmane.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 11 Jun 2004, othermark wrote: > Robert Watson wrote: > > It would be extremely helpful if you could figure out where in the kernel > > 0xc04cbf38 is. You should be able to do this using a kernel on disk; > > debugging, etc, is not necessary. If possible, DDB stack traces or the > > results of gdb on a dump would also be extremely helpful. > > I get a very similar stack track traversing through sossend(), under > heavy NFS load on a 1GB machine. Note the panic message here, and the > peculiarity that previous incarnations of -current did not panic under > similar load. It is highly reproduceable via a 'make installworld' via > NFS with /usr/src and /usr/obj mounted. The NFS serving machine will > always panic using vanilla GENERIC: Hrmm. It's certainly similar, but it's not clear to me that it's necessarily related (although I wouldn't preclude that). Could you tell me what date you cvsup'd this tree? Also, since you have a dump (yay!), could you try running vmstat -m, vmstat -z, and netstat -mb against the dump? It could be that a bug was introduced in nfsd that leaks mbufs or the like, or it could be a nit in mbuma. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Senior Research Scientist, McAfee Research
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1040611105034.66561A-100000>