tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: memcpy of struct buf, or similar?

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:

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

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

Checking the cv memory shows:
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

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 :)


Home | Main Index | Thread Index | Old Index