Re: memcpy of struct buf, or similar?

[Chris Gilbert <chris%dokein.co.uk@localhost>]

Simon Burge wrote:
> Andrew Doran wrote:
> 
>> Are you running with LOCKDEBUG? It's probably failure to release a spin
>> mutex.
> 
> No anymore - I used to run with it all the time, but not since enabling
> it took a large performance hit some time post netbsd-4.  I'll try
> LOCKDEBUG (tomorrow).

I just had the same assert trigger:
kernel diagnostic assertion "cv_has_waiters(&bp->b_done)" failed: file
"../../../../kern/vfs_bio.c", line 1535

bt indicates the buf is:
biodone2(c4afd86c)

A matching biowait lwp also exists:
biowait(c4afd86c)
cv_wait(c4afd8fc, d007ac3c)

running cv_has_waiters on the buffer b_done cv shows:
db{0}> call cv_has_waiters(c4afd8fc)
0x1
which doesn't match the panic that occured!

Checking the cv memory shows:
d0e25d80
d0e25e40
c0a2a161
80000200 <- matches the b_flags in the buf

whatis on d0e25d80 shows it in lwppl, and a trace/a on it shows that
it's the biowaiting thread (which you'd expect it to be)

Checking that the mutex is owned correctly:
db{0}> call mutex_dump(d007ac3c)
owner field: 0x00000000cfd27ce0 wait/spin: 0/0
0x40

whatis cfd27ce0 shows it's from the lwppl, and so trace/a cfd27ce0 shows
it to be the panic'd biodone.

Basically the KASSERT failed, yet ddb shows that the cv does have waiters.

Without knowing any better I'd say this is some wierd kind of cache/lock
coherency issue, and well beyond my knowledge of x86 :)

Thanks,
Chris