Re: UFS Witness LoR + 5 other LoRs

Am Sun, 08 Feb 2009 11:44:47 +0100
schrieb Kris Kennaway <kris_at_FreeBSD.org>:

> Several of these are widely reported, and harmless (not sure about
> the filedesc ones though).  Which one do you think is causing your
> problem?
> 
> Kris

Hi Kris.

I found out it has something to do with the softlink to an NFS share
that I have on my desktop (nautilus). I've made some settings yesterday
to fix it and will report, if this was the problem. Of course, the amd
mounts and unmounts my NFS share and the mentioned LORs appear typically
while mounting and unmounting, I noticed. So it is perhaps misleading.

Btw... it would be very nice if someone finally implements timeouts and
a detection strategy for NFS packets that don't arrive at their
destination because of fragmentation and wrong rsize/wsize settings.
But this is a totally different topic. There is not much in the docs
about it.


You mean this LOR "with filedesc"?

lock order reversal:
 1st 0xffffff001ada0ba8 zfs (zfs) _at_ /usr/src/sys/kern/vfs_subr.c:2071
 2nd 0xffffff0008a92848 filedesc structure (filedesc structure)
_at_ /usr/src/sys/kern/vfs_syscalls.c:1720 KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
_witness_debugger() at _witness_debugger+0x2e
witness_checkorder() at witness_checkorder+0x81e
_sx_slock() at _sx_slock+0x55
kern_symlinkat() at kern_symlinkat+0x1f8
syscall() at syscall+0x1bf
Xfast_syscall() at Xfast_syscall+0xab
--- syscall (57, FreeBSD ELF64, symlink), rip = 0x8049cc13c, rsp =
0x7fffffffd6f8, rbp = 0x7fffffffdd10 ---

It still occurs on:
FreeBSD zelda.local 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Mon Feb  2
19:20:24 CET 2009     root_at_zelda.local:/usr/obj/usr/src/sys/ZELDA  amd64

It appears a bit later when Gnome is already running, I think. I
can only tell by looking at the time stamp that is 3 minutes after
booting the machine. I'll to try to figure out what is running when
exactly this LOR appears.

--
Martin