From: "Robert Watson" <rwatson_at_freebsd.org> > 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. Other than what is included below, nothing further was on the console. But it is relatively simple to reproduce.... compiling on an NFS mount does the trick. So if you want me to do other things, let me know.. Currently running with INVARIANTS, WITNESS, WITNESS_SKIPSPIN, DIAGNOSTIC, DDB, DDB_TRACE ...... --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 ---Received on Mon Jul 05 2004 - 16:26:16 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:00 UTC