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 08:05:07PM +0200, Manuel Bouyer wrote:
> On Fri, Jun 27, 2008 at 06:35:21PM +0200, Manuel Bouyer wrote:
> > I added some checks, see the attached patch (the BC_PRIV flag is something
> > I added to check if private buffers from xbdback or vnd did show up
> > there). I got right at boot:
> Of course some of the checks here are bogus. I should have looked at it
> more before posting. Sorry for the noise.
> Some more facts:
> - the faultly buffer seems to always come from the LRU list
> - b_cflags seems to always be 0x4000030, b_flags 0x404, b_oflags 0.

So BC_SCANNED is set. There is only one place were we set it, it's
in ffs_full_fsync(). I added a KDASSERT() here and it fired:
panic: kernel debugging assertion "!checkfreelist(bp, &bufqueues[BQ_LRU])" 
failed: file "/dsk/l1/misc/bouyer/current/src/sys/ufs/ffs/ffs_vnops.c", line 386
fatal breakpoint trap in supervisor mode
trap type 1 code 0 rip ffffffff804ac1ad cs e030 rflags 246 cr2  7f7fffffbf90 
cpl 0 rsp ffffa0000d030a70
Stopped in pid 0.42 (system) at netbsd:breakpoint+0x5:  leave
breakpoint() at netbsd:breakpoint+0x5
panic() at netbsd:panic+0x255
__kernassert() at netbsd:__kernassert+0x2d
ffs_full_fsync() at netbsd:ffs_full_fsync+0x2d2
spec_fsync() at netbsd:spec_fsync+0x59
VOP_FSYNC() at netbsd:VOP_FSYNC+0x34
sched_sync() at netbsd:sched_sync+0x14d

So we set BC_BUSY just before releasing bufcache_lock, on a buffer which is
in the LRU queue. That's why we're getting the panic later.

Now, is it OK to have a dirty buffer in the LRU queue ? It looks like
we could recycle dirty buffers from the LRU queue without flushing them
to disk first, isn't it ?

Manuel Bouyer <>
     NetBSD: 26 ans d'experience feront toujours la difference

Home | Main Index | Thread Index | Old Index