Date: Fri, 18 May 2007 18:43:35 -0400 From: "Andrew Edwards" <aedwards@sandvine.com> To: <freebsd-fs@freebsd.org>, <freebsd-performance@freebsd.org> Subject: RE: Ufs dead-locks on freebsd 6.2 Message-ID: <5230D3C40B842D4F9FB3CD368021BEF72F0926@exchange-2.sandvine.com> In-Reply-To: <464DF9CA.9090900@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Okay, I let memtest run for a full day and there has been no memory errors. What do I do next? Just to be on the safe side I'll fsck all of my fs's and try to reproduce the problem again. I also don't know what zonelimit is, I see this on similarily configured machines but running 5.4. I know it's related to network as I periodically get network connections to work i.e. ssh, ftp (both server and client side) but eventually the box will deadlock. Should I start a different thread on this? Happens about once every 30 days on two server although I havn't checked the exact timing. -----Original Message----- From: owner-freebsd-fs@freebsd.org [mailto:owner-freebsd-fs@freebsd.org] On Behalf Of Eric Anderson Sent: Friday, May 18, 2007 3:09 PM To: Kris Kennaway Cc: freebsd-fs@freebsd.org Subject: Re: Ufs dead-locks on freebsd 6.2 On 05/18/07 14:00, Kris Kennaway wrote: > On Thu, May 17, 2007 at 11:38:20PM -0500, Eric Anderson wrote: >> On 05/17/07 12:47, Kostik Belousov wrote: >>> On Thu, May 17, 2007 at 01:03:37PM -0400, Andrew Edwards wrote: >>>> Here it is. >>>> >>>> db> show vnode 0xccd47984 >>>> vnode 0xccd47984: tag ufs, type VDIR >>>> usecount 5135, writecount 0, refcount 5137 mountedhere 0 >>>> flags (VV_ROOT) >>>> v_object 0xcd02518c ref 0 pages 1 >>>> #0 0xc0593f0d at lockmgr+0x4ed >>>> #1 0xc06b8e0e at ffs_lock+0x76 >>>> #2 0xc0739787 at VOP_LOCK_APV+0x87 >>>> #3 0xc0601c28 at vn_lock+0xac >>>> #4 0xc05ee832 at lookup+0xde >>>> #5 0xc05ee4b2 at namei+0x39a >>>> #6 0xc05e2ab0 at unp_connect+0xf0 >>>> #7 0xc05e1a6a at uipc_connect+0x66 >>>> #8 0xc05d9992 at soconnect+0x4e >>>> #9 0xc05dec60 at kern_connect+0x74 >>>> #10 0xc05debdf at connect+0x2f >>>> #11 0xc0723e2b at syscall+0x25b >>>> #12 0xc070ee0f at Xint0x80_syscall+0x1f >>>> >>>> ino 2, on dev amrd0s1a >>> It seems to be the sort of things that cannot happen. VOP_LOCK()=20 >>> returned 0, but vnode was not really locked. >>> >>> Although claiming that kernel code cannot have such bug is too=20 >>> optimistic, I would first make sure that: >>> 1. You checked the memory of the machine. >>> 2. Your kernel is built from pristine sources. >> >> This looks precisely like a lock I was seeing on one of my NFS servers.=20 >> Only one of the filesystems would cause it, but it was the same one=20 >> each time, not necessarily under any kind of load. Things like=20 >> mountd would get wedged in state 'ufs', and other things would get=20 >> stuck in one of the lock states (I can't recall). >=20 > ...so you cannot conclude that it looks "precisely like" this case. >=20 > Please, don't confuse bug reports by this kind of claim unless you=20 > have made a detailed comparison of the debugging traces to yours. Understood - my mistake. Eric _______________________________________________ freebsd-fs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-fs To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5230D3C40B842D4F9FB3CD368021BEF72F0926>