kern/38273: "lockdebug_barrier: spin lock held" from ld_ataraid_start_raid0()

["Greg A. Woods" <woods%planix.com@localhost>]

>Number:         38273
>Category:       kern
>Synopsis:       panic: LOCKDEBUG, "lockdebug_barrier: spin lock held", from 
>ld_ataraid_start_raid0()
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Mar 21 21:00:00 +0000 2008
>Originator:     Greg A. Woods
>Release:        NetBSD 4.99.55 2008/03/20
>Organization:
Planix, Inc.; Toronto, Ontario; Canada
>Environment:
System: NetBSD 4.99.55 GENERIC (with LOCKDEBUG)
Architecture: i386
Machine: i386
>Description:

        In hopes of debugging the ataraid problem on my Asus
        PSCH-SR/SATA based server I built and booted a -current kernel
        with LOCKDEBUG, and immediatly on the first attempt to access
        the logical drive (ld0a with newfs), the following panic
        occured:

Mutex error: lockdebug_barrier: spin lock held

lock address : 0x00000000c381a6e0 type     :               spin
shared holds :                  0 exclusive:                  1
shares wanted:                  0 exclusive:                  0
current cpu  :                  0 last held:                  0
current lwp  : 0x00000000cdf1ac20 last held: 0x00000000cdf1ac20
last locked  : 0x00000000c01f05cd unlocked : 0x00000000c01f0734
initialized  : 0x00000000c01eef81
owner field  : 0x0000000000010500 wait/spin:                0/1

panic: LOCKDEBUG
Stopped in pid 871.1 (newfs) at netbsd:breakpoint+0x4:  popl    %ebp
db{0}> trace
breakpoint(cdefe818,5,cdefe84c,c0583c8b,c0a2de0f) at netbsd:breakpoint+0x4
cpu_Debugger(c0a2de0f,cdefe858,c0c9b5c0,c0584b3b,5) at netbsd:cpu_Debugger+0xb
panic(c0a2cfd0,c0584ada,c0a2cdee,c0a2ce00,0) at netbsd:panic+0x164
lockdebug_abort1(cda38700,c0d63720,c0a2cdee,c0a2ce00,1) at netbsd:lockdebug_abod
lockdebug_barrier(c0d56b80,1,0,c0c9b5c0,5) at netbsd:lockdebug_barrier+0x103
mutex_vector_enter(cc875b88,c3188750,1,1749efff,0) at netbsd:mutex_vector_enter1
ld_ataraid_start_raid0(c381a600,c3188750,cdefea0c,c01ef350,cdefea05) at netbsd:a
ldstart(c381a600,c3188750,0,c054e4ee,0) at netbsd:ldstart+0x98
ldstrategy(c3188750,0,200,1,cdefea7c) at netbsd:ldstrategy+0x256
physio(c01f0335,0,4500,0,c01f0f58) at netbsd:physio+0x3c2
ldwrite(4500,cdefec4c,10,c054e4ee,0) at netbsd:ldwrite+0x38
cdev_write(4500,cdefec4c,10,c054e25d,2) at netbsd:cdev_write+0x63
spec_write(cdefebe0,0,c0d636e0,cdf1ac20,cdef6500) at netbsd:spec_write+0xd0
ufsspec_write(cdefebe0,1864c00,cdefebfc,c05da286,cdc0d5ec) at netbsd:ufsspec_wr2
VOP_WRITE(cdc0d5ec,cdefec4c,10,cc864c00,cdc0d5ec) at netbsd:VOP_WRITE+0x70
vn_write(cde906c0,cdefecb4,cdefec4c,cc864c00,0) at netbsd:vn_write+0x131
dofilewrite(4,cde906c0,bbbb5000,200,cdefecb4) at netbsd:dofilewrite+0x8c
sys_pwrite(cdf1ac20,cdefed04,cdefecfc,c082eda1,cdefed07) at netbsd:sys_pwrite+0c
syscall(cdefed48,b3,ab,1f,1f) at netbsd:syscall+0x182
db{0}> 

        This system now has a serial console connection so more
        debugging is easy to do and access can be made available if
        necessary to anyone who can help fix the problem.

>How-To-Repeat:

>Fix: