On Mon, Jul 16, 2007 at 07:31:52PM +0100, Patrick Welche wrote:
> Finally a panic while I'm not in X... Today's CVS on i386:
> 
> simple_lock: uninitialized lock
> lock: 0xce707ef8, currently at: ../../../../kern/kern_synch.c:184
> uvm_fault(0xc05c3da0, 0xdeadb000, 1) -> 0xe
> kernel: supervisor trap page fault, code=0
> Stopped in pid 0.17 (system) at netbsd:strlen+0x8:    cmpb  $0,0(%eax)
>  
> strlen+0x8
> vsnprintf+0x42
> lock_printf(c0531a16,deadbeef,ffffbeef,b8,c) lock_printf+0x5f
> _simple_lock+0x8c
> ltsleep+0x18f
> acquire_0xb0
> _lockmgr+0x507
> ufs_lock+0x4f
> VOP_LOCK+0x25
> vn_lock+0x9f
> vrele+0x130
> vget_0x90
> ffs_sync_0xde
> sync_fsync+0xaa
> VOP_FSYNC+0x49 
> sched_sync+0xf5
> db> show lock  
> Sorry, no record of a lock with address 0xc0492fd0 found.
> db> sync
> 
> Mutex error: lockdebug_wantlock: locking against myself
> ...
> Turnstile chain at 0xc05e3960
> => No active turnstile for this lock.
> 
> (I can only guess that the other box with a kernel built today is
> freezing for similar reasons but I'm always in X when it happens.)


I am able to reproduce this trap.

With rev. 1.289 of vfs_subr.c the lock type in function vclean()
was changed from LK_DRAIN to LK_EXCLUSIVE.  This seems wrong.

I managed to get this trace:

lwp_0	sys_munmap -> uvm_unmap_detach -> vrele ->
	    vn_lock -> VOP_LOCK -> ufs_lock -> SUCCESS

ioflush	sched_sync -> VOP_FSYNC -> sync_fsync -> ffs_sync -> vget ->
	    vn_lock -> VOP_LOCK -> ufs_lock -> EBUSY
	...
	    vrele -> vn_lock -> VOP_LOCK -> ufs_lock -> SLEEP

lwp_0	sys_munmap -> uvm_unmap_detach -> vrele ->
	    VOP_INACTIVE -> ufs_inactive -> VOP_UNLOCK -> ufs_unlock
	    VOP_INACTIVE -> ufs_inactive -> vrecycle -> vgonel -> vclean ->
		VOP_LOCK (*) -> ufs_lock -> SUCCESS
	    VOP_INACTIVE -> ufs_inactive -> vrecycle -> vgonel -> pool_put

(*) This is the lock that changed.
-- 
Juergen Hannken-Illjes - hannken@eis.cs.tu-bs.de - TU Braunschweig (Germany)