On 20 Jul 1999 12:48:34 +0200 
 joda@pdc.kth.se (Johan Danielsson) wrote:

 > Sometimes processes blocks in vnlock. I've seen this when compiling in
 > emacs (when it's about to start the process), and when running su.
 > 
 > The blocked process looks like this:
 > 
 >     0  5422  5421   0  -2 -2    64  392 vnlock D<s+ p4    0:00.02 /usr/bin/su 
 > 
 > Typing a few characters in some other terminal usually unblocks the
 > process.
 > 
 > I assume this is because of some subtle bug in the recent vnode
 > locking changes. 
 > 
 > This is what I have mounted:
 > 
 > /dev/wd0a on / type ffs (local)
 > /dev/wd0e on /usr type ffs (local)
 > /dev/wd0f on /usr/misc type ffs (local)
 > /dev/wd0g on /usr/misc/src/netbsd type ffs (local)
 > mfs:307 on /tmp type mfs (asynchronous, local)
 > procfs on /proc type procfs (local)
 > kernfs on /kern type kernfs (local)
 > fdesc on /dev type fdesc (local, union)

Yes, it was a bug in the fdesc file system.  I committed a fix from Bill
Studenmund yesterday:

	$NetBSD: fdesc_vnops.c,v 1.49 1999/07/19 23:00:47 thorpej Exp $

It was a bug in handling the "/dev/tty" node.  The bug actually existed
forever, but wasn't noticed until now because fdescfs didn't actually
lock its vnodes at all (it used a noop vnode lock vector).

 > Hard to tell. It doesn't always happen, but I think it might happen
 > when I have forground processes running in some other terminal (but
 > this is just speculation).

It's actually very easy to reproduce.  Using two xterm windows:

	a% cd /usr/src/bin/cat
	b% cd /usr/src/bin/ls
	a% more cat.c
	b% more ls.c

Watch in amazement as the more(1) in window b doesn't scroll until you
press a key in window a.

        -- Jason R. Thorpe <thorpej@nas.nasa.gov>