From owner-freebsd-current@FreeBSD.ORG Mon Jul 5 16:22:29 2004 Return-Path: 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 E582A16A4CE for ; Mon, 5 Jul 2004 16:22:29 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7B59543D64 for ; Mon, 5 Jul 2004 16:22:29 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.11/8.12.11) with ESMTP id i65GLu1w032163; Mon, 5 Jul 2004 12:21:56 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i65GLuiY032160; Mon, 5 Jul 2004 12:21:56 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Mon, 5 Jul 2004 12:21:56 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Willem Jan Withagen In-Reply-To: <1cf201c4629c$15f16ba0$471b3dd4@digiware.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org Subject: Re: malloc(M_WAITOK) of "Mbuf", forcing M_NOWAIT with the following non-sleepable locks held X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jul 2004 16:22:30 -0000 On Mon, 5 Jul 2004, Willem Jan Withagen wrote: > It's not a LOR, but almost looks like one.... it could also be > harmless, since it only delays the server (because it is logging to a > serial console???) Do you have a stack trace available for this? I've cleaned up a few, but not all, of the known M_WAITOK with a mutex held cases, but there may well be more. I know Bruce Simpson has also been working on at least one. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research > > >From what I find in the archives, has this to do with MBUMA??? > Although no one has something with uipc_socket > > I'm trying to tar something from an NFS mounted file, into that same NFS mounted > directory... Copying the source first to /tmp, and then untar works flawless. So > I guess it has to do with the way tar reads the inputfile. > > [~/src/ports/net-snmp] wjw@opteron> uname -a > FreeBSD opteron.digiware.nl 5.2-CURRENT FreeBSD 5.2-CURRENT #48: Fri Jul 2 > 00:55:22 CEST 2004 root@opteron.digiware.nl:/usr/obj/home2/src/sys/OPTERON.amd64 > amd64 > > Mount options: > rw,-Tbis3,nodev,intr,-r=1638,-w=163844 > > Which could be the reason, sinc I now see they are rather strange. :( > So perhaps a don't do that is appropriate...., but none the less > here's the traceback. (it's on amd64, hence no parameters) > > --WjW > > ---------------- > malloc(M_WAITOK) of "Mbuf", forcing M_NOWAIT with the following non-sleepable > locks held: > exclusive sleep mutex so_rcv r = 0 (0xffffff006174a6f8) locked @ /home2/src/sys/ > kern/uipc_socket.c:917 > Stack backtrace: > backtrace() at backtrace+0x17 > witness_warn() at witness_warn+0x297 > uma_zalloc_arg() at uma_zalloc_arg+0x59 > m_copym() at m_copym+0x118 > soreceive() at soreceive+0x9a4 > nfs_receive() at nfs_receive+0x29f > nfs_reply() at nfs_reply+0x46 > nfs_request() at nfs_request+0x374 > nfs_writerpc() at nfs_writerpc+0x22b > nfs_doio() at nfs_doio+0x4a0 > nfssvc_iod() at nfssvc_iod+0x1c4 > fork_exit() at fork_exit+0xd1 > fork_trampoline() at fork_trampoline+0xe > --- trap 0, rip = 0, rsp = 0xffffffffb4019d00, rbp = 0 --- > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >