Ufs dead-locks on freebsd 6.2

[Andrew Edwards]

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 at freebsd.org [mailto:owner-freebsd-fs at freebsd.org]
On Behalf Of Eric Anderson
Sent: Friday, May 18, 2007 3:09 PM
To: Kris Kennaway
Cc: freebsd-fs at 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() 
>>> returned 0, but vnode was not really locked.
>>>
>>> Although claiming that kernel code cannot have such bug is too 
>>> 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. 
>>  Only one of the filesystems would cause it, but it was the same one 
>> each time, not necessarily under any kind of load.  Things like 
>> mountd would get wedged in state 'ufs', and other things would get 
>> stuck in one of the lock states (I can't recall).
> 
> ...so you cannot conclude that it looks "precisely like" this case.
> 
> Please, don't confuse bug reports by this kind of claim unless you 
> have made a detailed comparison of the debugging traces to yours.


Understood - my mistake.

Eric


_______________________________________________
freebsd-fs at freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "freebsd-fs-unsubscribe at freebsd.org"