tech-kern archive

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

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

On Fri, Jun 27, 2008 at 04:48:49PM +0200, Manuel Bouyer wrote:
> On Fri, Jun 27, 2008 at 04:06:53PM +0200, Manuel Bouyer wrote:
> > [...]
> > > 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.
> I've been able to reproduce it without any domU running. So it's not related
> to vnd or xbdback. As I can't reproduce it on any system but this one,
> the problem may be within amr(4) or ld(4).

It's not amr(4) or ld(4) either. I've now been able to reproduce it on
a dom0 with a single wd(4) drive on ahcisata(4), and also with a
GENERIC+DEBUG+DIAGNOSTIC+REALEXTMEM="130048" amd64 kernel. The key point seems
to have the RAM set to 128MB. With bigger values, this problem doens't seem to
happen. So it would be something that occurs when the buffer cache is under
pressure, and is not related to any device or pseudo-device, or Xen.

So to make it clear how to reproduce this:
on a NetBSD/amd64 current system with some extra files (e.g. checkout of
src and pkgsrc) build a kernel with
include "arch/amd64/conf/GENERIC"
options         DIAGNOSTIC      # expensive kernel consistency checks
options         DEBUG           # expensive debugging checks/support
options         KMEMSTATS       # kernel memory statistics (vmstat -m)
options         REALEXTMEM="130048"

boot it, and run (csh-style):
while (1)
sh /etc/daily

it should panic within a few interations.

Manuel Bouyer, LIP6, Universite Paris VI.  
     NetBSD: 26 ans d'experience feront toujours la difference

Home | Main Index | Thread Index | Old Index