Date: Sat, 18 Sep 1999 05:49:06 +0200 From: Tor.Egge@fast.no To: sraja@cinenet.net Cc: freebsd-smp@FreeBSD.ORG Subject: Re: SMP problems continue on 3.3-RC Message-ID: <199909180349.FAA19076@midten.fast.no> In-Reply-To: Your message of "Fri, 17 Sep 1999 15:39:01 -0700 (PDT)" References: <Pine.GSO.3.96.990917153637.18769E-100000@hermosa.cinenet.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> > :panic (c0241d25,0,cc848cb0,1,c01769d4) at panic 0xa4 > > :bsl1 (cc848c40, 2, cbbe6860, cbe3043f, cc848d00) at bs1 > > :nfs_lookup (cbf3de30, cbafce00, cbf3dedc, cbf3deb80) at nfs_lookup 0x22f > > :lookup(cbf3deb8,cbbe6860,cbbe6860,cbf3df94,cbf3de74) at lookup 0x2c1 > > :namei(cbf3deb8,cbbe6860,c0292740,0,8162ce4) at namei 0x133 > > :stat(cbbe6860,cbf3df94,13,5,bfbfdd50) at stat 0x44 > > :syscall(27,bfbf0027,bfbfdd50,5,bfbfdb28) at syscall 0x107 > > :Xint0x80_syscall() at Xint)x80_syscall + 0x4c nfs_lookup called vget, but the trace is incomplete due to s_lock being a frameless function. One of the simple_lock calls in vget failed due to the vnode interlock already being held by the same CPU. If it was held by any other CPU then you would get a hang instead of a panic. I suggest testing a UP kernel with the SIMPLELOCK_DEBUG kernel option defined and mi_switch modified to panic instead of just printing a warning when a process attempts to sleep with a simple lock held. - Tor Egge To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199909180349.FAA19076>