The following might be helpful: first, get the exact quote of the
panic. I found in the code base "softdep_lock: lock held by %d" and a
similar string starting "softdep_lock_interlocked". So it the exact
quote, including the pid that it is claiming holds the lock.

	Then at the ddb debugger type "ps" to find the name of the process
referred to by the pid, and note down the last column which tells you
where the process is blocked. Finally, get the backtrace ("trace"? or
"bt"? I can't remember).

	This will tell me who owned the lock and why they're blocked, and it'll
tell me what code the current process is running that wants to get the
lock. Also, when you type "ps" I think it displays the current process
with a "*" at the beginning of the line, so then you can find out the
name of the process trying to grab the lock.

	If you can get me that, it might help. Thanks!
	-- Ethan

Martin Husemann wrote:
> 
> 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:
> 
> /dev/wd0a on / type ffs (local)
> /dev/wd0e on /usr type ffs (local)
> 
> 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!
> 
> Martin