RE: Ufs dead-locks on freebsd 6.2

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@xxxxxxxxxxx [mailto:owner-freebsd-fs@xxxxxxxxxxx]
On Behalf Of Eric Anderson
Sent: Friday, May 18, 2007 3:09 PM
To: Kris Kennaway
Cc: freebsd-fs@xxxxxxxxxxx
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@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "freebsd-fs-unsubscribe@xxxxxxxxxxx"
_______________________________________________
freebsd-performance@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "freebsd-performance-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: tuning hints for PAE
    ... This does not appear to consume a lot of memory anyway, ... As far as I understand it, a vnode is a kernel data-structure ... Marijuana esit gaula. ...
    (freebsd-current)
  • ZFS and UFS on the same box. Cache memory allocation issue.
    ... ZFS and UFS independently allocates memory for its cache. ...
    (freebsd-current)
  • Re: [PATCH] Make udf(4) MPSAFE and use shared lookups
    ... other threads to find the vnode on the mount list. ... !MPSAFE fs, and it seems corresponding call was not marked XXX for udf. ... It does the same as ufs. ... The race happens for!MPSAFE code too, ...
    (freebsd-current)
  • Re: [PATCH] Make udf(4) MPSAFE and use shared lookups
    ... other threads to find the vnode on the mount list. ... !MPSAFE fs, and it seems corresponding call was not marked XXX for udf. ... It does the same as ufs. ...
    (freebsd-current)
  • Re: x86 vs Sparc
    ... > 10k rpm disks. ... It seems like UFS is very ... OS receives more demands for memory from processes, so eventually, the FS ... Not so on Solaris, where FS throughput is pretty much constant. ...
    (comp.unix.solaris)