| After about daily panics (softdep_write: lock held) I have disabled 
| soft dependencies for all my file systems again. This is on i386, running
| kernel and userland supped yesterday, nothing special, no strange filesystems:
|
| Any ideas how to debug this? I can't believe this is just me, I've never
| seen NetBSD crash on a regular basis since several years - it's shocking!

I see this when I have a large buffer cache in front of slow disks,
and perform lots of file creations.  The fastest way to trigger this
is to do a "cvs checkout pkgsrc" from a (topology-wise) nearby 
anonymous CVS server.

I can dramatically reduce the chances of panic on my systems in three ways:

	1/ increase tickdelay value in gnu/sys/ufs/ffs/ffs_softdep.c
	   line 416, and the values in line 4285 used to bound the tickdelay-
	   derived timeout.   I use 32 in a system with (mostly quick) SCSI
	   disks, and 128 on my laptop which has a relatively slow EIDE drive

           the higher the value, the less liklihood of a panic

	2/ in ffs_softdep.c on line 880 adjust the multiplier downwards;
           the lower the multiplier the less liklihood of a panic.
           adjusting desiredvnodes downwards (config option NVNODE)
	   also decreases the liklihood of a panic.

	3/ increase the virtual memory space, mostly by increasing
	   option NKMEMCLUSTERS

The most effective of these so far is (1), however I have done all three.

Interestingly, doing a SIGTSTP/SIGSTOP on a tar/cvs/whatever creates
lots of entries in a directory tree, calling sync(2), and then sending
SIGCONT to the process, also dramatically reduces the chance of a panic.

Doing lots of file creations out of a big, full bufcache shows an
increase in the total allocated kvm (last line of vmstat -m), but
I have not spotted where the allocated memory goes, or why, however
there is an increase in ffsinopl, vnodepl and sigapl pages.

	Sean.