Re: kern/39052: assertion "!ISSET(bp->b_cflags, BC_BUSY)" failed

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Fri, Jun 27, 2008 at 10:05:00AM +0000, Manuel Bouyer wrote:
>       This is a Xen dom0, with 2 linux domUs. The domU's virtual disks
>       are backed by files in a FFS.
>       The system reliably panics when running the daily scripts with:
> panic: kernel diagnostic assertion "!ISSET(bp->b_cflags, BC_BUSY)" failed: 
> file
> /dsk/l1/misc/bouyer/current/src/sys/kern/vfs_bio.c", line 1320
> fatal breakpoint trap in supervisor mode
> trap type 1 code 0 rip ffffffff804abc0d cs e030 rflags 246 cr2  7f7ffdfec000 
> cp0
> Stopped in pid 2726.1 (find) at netbsd:breakpoint+0x5:  leave
> breakpoint() at netbsd:breakpoint+0x5
> panic() at netbsd:panic+0x255
> __kernassert() at netbsd:__kernassert+0x2d
> getnewbuf() at netbsd:getnewbuf+0x2c4
> getblk() at netbsd:getblk+0x91
> bio_doread() at netbsd:bio_doread+0x24
> bread() at netbsd:bread+0x22
> ffs_read() at netbsd:ffs_read+0x372
> VOP_READ() at netbsd:VOP_READ+0x2d
> ufs_readdir() at netbsd:ufs_readdir+0x10b
> VOP_READDIR() at netbsd:VOP_READDIR+0x39
> vn_readdir() at netbsd:vn_readdir+0x10e
> sys___getdents30() at netbsd:sys___getdents30+0x89
> syscall() at netbsd:syscall+0x98
> (I've seen different variations of the stack trace, but it's always FFS doing
> getblk()).
> Michael van Elst suggested it could be related to locking issues in vnd,
> but I don't have more details. Note that the xen backend block device
> calls bdev_strategy() from interrupt context, I don't know if it
> can have a bad effect. AFAIK, this will cal vndstrategy() which will
> enqueue the buffer and wakeup a kernel thread to handle it. This shouldn't
> interract at all with the buffer cache.

Another parameter is that this box is using a amr(4) controller. It's
my only system with an amr(4) running -current, and I can't reproduce this
on onther -current Xen dom0.
The amr(4) interrupt routine can be called from interrupt context,
or a kernel thread. Under heavy I/O load some of the I/O request completion
could be handled from thread context and not interrupt context.

-- 
Manuel Bouyer, LIP6, Universite Paris VI.           
Manuel.Bouyer%lip6.fr@localhost
     NetBSD: 26 ans d'experience feront toujours la difference
--