Lennart Augustsson wrote:

> Module Name:	syssrc
> Committed By:	augustss
> Date:		Thu Mar 30 09:32:26 UTC 2000
> 
> Modified Files:
> 
> 	syssrc/sys/kern: vfs_subr.c
> 
> Log Message:
> 
> Add a special option, DEBUG_HALT_BUSY, that allows you to debug when the
> system doesn't want to halt cleanly.  The code was there before, but only
> with the DEBUG option.

I'm wondering if the new behaviour shouldn't be controlled by two
checks.  I do want to see the busy vnodes (and have had a private patch
to always show them), but I don't want to drop into ddb if there are
any.


Back to the root cause of the problem - I usually see this when
something has a busy buffer on an mfs /tmp.  Could this be something
to do with the userland program not being scheduled so that I/O's can
complete?  Perhaps we could ignore busy buffer on an mfs - it's not as
if we gain anything by making sure data is flushed out.  Or do things
back up against the busy buffer we are ignoring?

I had a poke around in vfs_shutdown, but even though I get a report that
says:

	Printing vnodes for busy buffers
	tag 3 type VBLK, usecount 3, writecount 0, refcount 4, flags (VBWAIT)
		tag VT_MFS, pid 131, base 0x80a8000, size 33554432
	tag 3 type VBLK, usecount 3, writecount 0, refcount 4, flags (VBWAIT)
		tag VT_MFS, pid 131, base 0x80a8000, size 33554432
	tag 3 type VBLK, usecount 3, writecount 0, refcount 4, flags (VBWAIT)
		tag VT_MFS, pid 131, base 0x80a8000, size 33554432
	tag 3 type VBLK, usecount 3, writecount 0, refcount 4, flags (VBWAIT)
		tag VT_MFS, pid 131, base 0x80a8000, size 33554432
	rebooting...

I'm not sure how to tell which busy buffers are for the MFS inside the
loop that checks and increments nbusy - bp->b_vp->v_mount is a null
pointer.  v_tag confirms that these are on an MFS, but there's a big
warning at the top of <sys/vnode.h> saying that it should never be
inspected by the kernel!  Is there any other way to check what FS a
buffer is related to?

Simon.