malloc(M_WAITOK) of "Mbuf", forcing M_NOWAIT with the following non-sleepable locks held

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_at_opteron> uname -a
FreeBSD opteron.digiware.nl 5.2-CURRENT FreeBSD 5.2-CURRENT #48: Fri Jul 2
00:55:22 CEST 2004 root_at_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 _at_ /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 ---