From owner-freebsd-current Thu Mar 6 11:22:48 2003 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1A0DD37B401; Thu, 6 Mar 2003 11:22:47 -0800 (PST) Received: from mail.flugsvamp.com (ts46-01-qdr3643.mdfrd.or.charter.com [68.118.36.71]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0DAE043FAF; Thu, 6 Mar 2003 11:22:46 -0800 (PST) (envelope-from jlemon@flugsvamp.com) Received: (from jlemon@localhost) by mail.flugsvamp.com (8.12.6/8.12.6) id h26JMLnd041477; Thu, 6 Mar 2003 13:22:21 -0600 (CST) (envelope-from jlemon) Date: Thu, 6 Mar 2003 13:22:20 -0600 From: Jonathan Lemon To: John Baldwin Cc: current@FreeBSD.org Subject: Re: witness: nfs & buf queue Message-ID: <20030306132220.T61787@flugsvamp.com> Mail-Followup-To: John Baldwin , current@FreeBSD.org References: <20030305201016.S61787@flugsvamp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from jhb@FreeBSD.org on Thu, Mar 06, 2003 at 01:01:49PM -0500 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, Mar 06, 2003 at 01:01:49PM -0500, John Baldwin wrote: > > On 06-Mar-2003 Jonathan Lemon wrote: > > Doing a kernel build over NFS on today's -current gives a pile of > > following error messages during the final link phase: > > > > Acquiring lockmgr lock "nfs" with the following non-sleepablelocks held: > > exclusive sleep mutex buf queue lock r = 0 (0xc0427b60) locked @ ../../../kern/vfs_bio.c:2107 > > Acquiring lockmgr lock "nfs" with the following non-sleepablelocks held: > > exclusive sleep mutex buf queue lock r = 0 (0xc0427b60) locked @ ../../../kern/vfs_bio.c:2107 > > Acquiring lockmgr lock "nfs" with the following non-sleepablelocks held: > > exclusive sleep mutex buf queue lock r = 0 (0xc0427b60) locked @ ../../../kern/vfs_bio.c:2107 > > ... > > Witness didn't used to complain about these until my recent commits, > so these could be old bugs that we are just now seeing. It does look > like all the lock functions in inmem() use LK_NOWAIT which is exempted > from the witness check: > > if ((flags & (LK_NOWAIT|LK_RELEASE)) == 0) > WITNESS_WARN(WARN_GIANTOK | WARN_SLEEPOK, > &lkp->lk_interlock->mtx_object, > "Acquiring lockmgr lock \"%s\"", lkp->lk_wmesg); > > A stack trace from one of these would be helpful. Here you go. This is from -current as of roughly an hour ago, I managed to break into ddb in the middle of witness_warn: kvprintf(c03918eb,c0210c20,e4050bfc,a,e4050c48) at kvprintf+0x8d vprintf(c03918eb,e4050c48,0,c0428620,10001) at vprintf+0x57 witness_warn(5,c0400da8,c03918eb,c039fff9,c6a752d0) at witness_warn+0xbe lockmgr(ca438304,10001,ca438248,c6a752d0,12) at lockmgr+0xc8 vop_sharedlock(e4050c98,0,c039a8b0,35c,c01eb1f2) at vop_sharedlock+0x7d vn_lock(ca438248,12,c6a752d0,83b,c04285e0) at vn_lock+0xeb flushbufqueues(c04285e0,0,c0398a32,104,64) at flushbufqueues+0x100 buf_daemon(0,e4050d48,c0390fdb,35f,0) at buf_daemon+0xd5 fork_exit(c0239920,0,e4050d48) at fork_exit+0xc4 fork_trampoline() at fork_trampoline+0x1a --- trap 0x1, eip = 0, esp = 0xe4050d7c, ebp = 0 --- No gdb stack trace, my dump device is too small. :-( -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message