Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 8 Feb 2009 18:29:40 +0100
From:      Martin <nakal@web.de>
To:        Martin <nakal@web.de>
Cc:        sean.bruno@dsl-only.net, Kris Kennaway <kris@FreeBSD.org>, freebsd-current@freebsd.org, sbruno@freebsd.org
Subject:   Re: UFS Witness LoR + 5 other LoRs
Message-ID:  <20090208182940.43d6c929@zelda.local>
In-Reply-To: <20090208130506.267a838d@zelda.local>
References:  <1233007263.9302.2.camel@localhost.localdomain> <20090129233220.1ed64e6d@zelda.local> <498EB79F.4010905@FreeBSD.org> <20090208130506.267a838d@zelda.local>

next in thread | previous in thread | raw e-mail | index | archive | help
Am Sun, 8 Feb 2009 13:05:06 +0100
schrieb Martin <nakal@web.de>:

> 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.

Hi.

I have further information on this. My desktop stopped working again,
because of NFS. Now I am sure. I have a LOR before this happened:

Feb  8 18:06:47 zelda kernel: lock order reversal:
Feb  8 18:06:47 zelda kernel: 1st 0xffffff001a1cca48 filedesc structure
(filedes c structure) @ /usr/src/sys/kern/kern_descrip.c:1076
Feb  8 18:06:47 zelda kernel: 2nd 0xffffff0002ed4098 pseudofs
(pseudofs) @ /usr/src/sys/kern/vfs_subr.c:4057 Feb  8 18:06:47 zelda
kernel: KDB: stack backtrace: Feb  8 18:06:47 zelda kernel:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2a Feb  8 18:06:47
zelda kernel: _witness_debugger() at _witness_debugger+0x2e Feb  8
18:06:47 zelda kernel: witness_checkorder() at witness_checkorder+0x81e
Feb  8 18:06:47 zelda kernel: __lockmgr_args() at __lockmgr_args+0xc2a
Feb  8 18:06:47 zelda kernel: vop_stdlock() at vop_stdlock+0x39 Feb  8
18:06:47 zelda kernel: VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b Feb  8
18:06:47 zelda kernel: _vn_lock() at _vn_lock+0x47 Feb  8 18:06:47
zelda kernel: knlist_remove_kq() at knlist_remove_kq+0x73 Feb  8
18:06:47 zelda kernel: knote_fdclose() at knote_fdclose+0x177 Feb  8
18:06:47 zelda kernel: kern_close() at kern_close+0xe6 Feb  8 18:06:47
zelda kernel: syscall() at syscall+0x1bf Feb  8 18:06:47 zelda kernel:
Xfast_syscall() at Xfast_syscall+0xab Feb  8 18:06:47 zelda kernel: ---
syscall (6, FreeBSD ELF64, close), rip = 0x800e35e8c, rsp =
0x7fffffffe4f8, rbp = 0x801063100 ---


And 5 minutes later I tried to access my amd-mounted share:

Feb  8 18:11:09 zelda amd[1063]: ignoring request from 127.0.0.1:21215,
port not reserved Feb  8 18:11:10 zelda last message repeated 7 times
Feb  8 18:11:11 zelda amd[1063]: ignoring request from 127.0.0.1:32008,
port not reserved

amd is suddenly flooding my syslog with these messages.

On 7.1R NFS client I did not have this effect at all. This is new on
8-CURRENT.

I hope this helps.

--
Martin



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090208182940.43d6c929>