From owner-freebsd-current@FreeBSD.ORG Mon Jul 5 14:33:49 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 F1D1E16A4CE for ; Mon, 5 Jul 2004 14:33:49 +0000 (GMT) Received: from freebee.digiware.nl (dsl390.iae.nl [212.61.63.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id EA9E343D69 for ; Mon, 5 Jul 2004 14:33:48 +0000 (GMT) (envelope-from wjw@withagen.nl) Received: from dual (dual [212.61.27.71]) by freebee.digiware.nl (8.12.10/8.12.10) with SMTP id i65EQmvZ065416 for ; Mon, 5 Jul 2004 16:26:49 +0200 (CEST) (envelope-from wjw@withagen.nl) Message-ID: <1cf201c4629c$15f16ba0$471b3dd4@digiware.nl> From: "Willem Jan Withagen" To: Date: Mon, 5 Jul 2004 16:26:39 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Subject: 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 14:33:50 -0000 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???) >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 ---