My son's computer deadlocked last night. "show lockedvnods" in
DDB showed:
Locked vnodes
0xc1669840: tag ufs, type VDIR, usecount 8, writecount 0, refcount 2, flags
(VV_ROOT|VV_OBJBUF), lock type ufs: EXCL (count 1) by thread 0xc18ed000 (pid
9666) with 7 pending
ino 2, on dev ad0s1g (4, 25)
0xc1682000: tag ufs, type VDIR, usecount 5, writecount 0, refcount 2, flags
(VV_OBJBUF), lock type ufs: EXCL (count 1) by thread 0xc16fd000 (pid 15686) with
1 pending
ino 23552, on dev ad0s1g (4, 25)
0xc1b30d68: tag ufs, type VDIR, usecount 2, writecount 0, refcount 1, flags
(VV_OBJBUF), lock type ufs: EXCL (count 1) by thread 0xc268f000 (pid 9075) with
1 pending
ino 122986, on dev ad0s1g (4, 25)
0xc1c3c210: tag ufs, type VDIR, usecount 3, writecount 0, refcount 1, flags
(VV_OBJBUF), lock type ufs: EXCL (count 1) by thread 0xc16fe4b0 (pid 9067) with
1 pending
ino 142022, on dev ad0s1g (4, 25)
0xc1e2ce70: tag ufs, type VREG, usecount 6, writecount 0, refcount 0, flags
(VV_OBJBUF), lock type ufs: SHARED (count 1) with 1 pending
ino 142169, on dev ad0s1g (4, 25)
After poking around in the crashdump for a while, I've worked out that
the process holding each of the above exclusive locks is waiting on
the next lock in the list. Unfortunately, there doesn't appear to be
any way to work out which process is holding the shared lock unless
DEBUG_LOCKS is set (and even this doesn't work if the lock was implicitly
downgraded by a process calling lockmgr(LK_SHARED) when it holds an
exclusive lock).
FWIW, the affected inodes are:
2 /usr
23552 /usr/local
122986 /usr/local/OpenOffice.org1.1.4
142022 /usr/local/OpenOffice.org1.1.4/program
142169 /usr/local/OpenOffice.org1.1.4/program/libpsp645fi.so
Does anyone have any ideas on how to track this further (or so I just
write it off as a glitch).
--
Peter Jeremy
CC'ing to jeffr On Sat, Apr 16, 2005 at 07:21:29AM +1000, Peter Jeremy wrote:> My son's computer deadlocked last night. "show lockedvnods" in DDB showed: > > Locked vnodes > 0xc1669840: tag ufs, type VDIR, usecount 8, writecount 0, refcount 2, flags (VV_ROOT|VV_OBJBUF), lock type ufs: EXCL (count 1) by thread 0xc18ed000 (pid 9666) with 7 pending > ino 2, on dev ad0s1g (4, 25) > 0xc1682000: tag ufs, type VDIR, usecount 5, writecount 0, refcount 2, flags (VV_OBJBUF), lock type ufs: EXCL (count 1) by thread 0xc16fd000 (pid 15686) with 1 pending > ino 23552, on dev ad0s1g (4, 25) > 0xc1b30d68: tag ufs, type VDIR, usecount 2, writecount 0, refcount 1, flags (VV_OBJBUF), lock type ufs: EXCL (count 1) by thread 0xc268f000 (pid 9075) with 1 pending > ino 122986, on dev ad0s1g (4, 25) > 0xc1c3c210: tag ufs, type VDIR, usecount 3, writecount 0, refcount 1, flags (VV_OBJBUF), lock type ufs: EXCL (count 1) by thread 0xc16fe4b0 (pid 9067) with 1 pending > ino 142022, on dev ad0s1g (4, 25) > 0xc1e2ce70: tag ufs, type VREG, usecount 6, writecount 0, refcount 0, flags (VV_OBJBUF), lock type ufs: SHARED (count 1) with 1 pending > ino 142169, on dev ad0s1g (4, 25) > > After poking around in the crashdump for a while, I've worked out that > the process holding each of the above exclusive locks is waiting on > the next lock in the list. Unfortunately, there doesn't appear to be > any way to work out which process is holding the shared lock unless > DEBUG_LOCKS is set (and even this doesn't work if the lock was implicitly > downgraded by a process calling lockmgr(LK_SHARED) when it holds an > exclusive lock). > > FWIW, the affected inodes are: > 2 /usr > 23552 /usr/local > 122986 /usr/local/OpenOffice.org1.1.4 > 142022 /usr/local/OpenOffice.org1.1.4/program > 142169 /usr/local/OpenOffice.org1.1.4/program/libpsp645fi.so > > Does anyone have any ideas on how to track this further (or so I just > write it off as a glitch). > > -- > Peter Jeremy > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20050416/c546d8cd/attachment.bin
On Sat, 16 Apr 2005, Peter Jeremy wrote:> My son's computer deadlocked last night. "show lockedvnods" in DDB showed: > > Locked vnodes > 0xc1669840: tag ufs, type VDIR, usecount 8, writecount 0, refcount 2, flags (VV_ROOT|VV_OBJBUF), lock type ufs: EXCL (count 1) by thread 0xc18ed000 (pid 9666) with 7 pending > ino 2, on dev ad0s1g (4, 25) > 0xc1682000: tag ufs, type VDIR, usecount 5, writecount 0, refcount 2, flags (VV_OBJBUF), lock type ufs: EXCL (count 1) by thread 0xc16fd000 (pid 15686) with 1 pending > ino 23552, on dev ad0s1g (4, 25) > 0xc1b30d68: tag ufs, type VDIR, usecount 2, writecount 0, refcount 1, flags (VV_OBJBUF), lock type ufs: EXCL (count 1) by thread 0xc268f000 (pid 9075) with 1 pending > ino 122986, on dev ad0s1g (4, 25) > 0xc1c3c210: tag ufs, type VDIR, usecount 3, writecount 0, refcount 1, flags (VV_OBJBUF), lock type ufs: EXCL (count 1) by thread 0xc16fe4b0 (pid 9067) with 1 pending > ino 142022, on dev ad0s1g (4, 25) > 0xc1e2ce70: tag ufs, type VREG, usecount 6, writecount 0, refcount 0, flags (VV_OBJBUF), lock type ufs: SHARED (count 1) with 1 pending > ino 142169, on dev ad0s1g (4, 25) > > After poking around in the crashdump for a while, I've worked out that > the process holding each of the above exclusive locks is waiting on > the next lock in the list. Unfortunately, there doesn't appear to be > any way to work out which process is holding the shared lock unless > DEBUG_LOCKS is set (and even this doesn't work if the lock was implicitly > downgraded by a process calling lockmgr(LK_SHARED) when it holds an > exclusive lock). > > FWIW, the affected inodes are: > 2 /usr > 23552 /usr/local > 122986 /usr/local/OpenOffice.org1.1.4 > 142022 /usr/local/OpenOffice.org1.1.4/program > 142169 /usr/local/OpenOffice.org1.1.4/program/libpsp645fi.so > > Does anyone have any ideas on how to track this further (or so I just > write it off as a glitch).This is the old "race to root" that happens at the end of the death spiral. You need to know why the guy holding tte library lock isn't letting go of it. -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org