Bill Studenmund wrote:
> 
> I just committed a large number of changes to modify how we do vnode
> locking, as was discussed over the past few months on tech-kern.
...
> Part of this involved changing how we do vnode locking. As most fs's were
> using the lock manager, I put a struct lock in struct vnode. Layered fs's
> (nullfs, umapfs, etc - NOT unionfs) set their vnodes to use the struct
> lock in the underlying vnode. That way the root and all overstacked vnodes
> lock and unlock at the same time. This should prevent race conditions.
...
> I think I got everything in. An i386 GENERIC kernel compiled fine before I
> committed, so I _think_ all is well.
...
> Let me know how it works!

I think this is related :( In a bid to work out what's up with my panic
ridden computer, I tried building (a few times) an INSTALL disk - fdset -
and I invariably get stuck at

...
SPECIAL /bin/rm etc/pwd.db
COPY    ${CURDIR}/../../../../etc/etc.i386/MAKEDEV      dev/MAKEDEV
SPECIAL cd dev; sh MAKEDEV ramdisk

in:

    0  9032  8802  29  -2  0    64  464 vnlock D+   p1    0:00.01 chown uucp tty01 dty01 

vnlock :(

chowning in /dev/vnd0a on /mnt type ffs (local)

Oh dear, just tried ls /mnt/dev, and:

    0  9114  9074   0  -2  0   212  116 vnlock D+   p9    0:00.00 ls /mnt/dev 

I guess it's time for another shutdown -r on the machine with the invisible
console :(

Cheers,

Patrick