Re: [PANIC] page fault -> bremfree: removing a buffer not on a queue

Hello,

Thank you for your reply!

On Wed, 2004-02-18 at 16:28, Daniel Papasian wrote:
> On Wed, 18 Feb 2004, Andreas Kohn wrote:
> > Hello,
> >
> > yesterday my computer crashed with this panic:
> >
> <snip>
> >
> > syncing disks, buffers remaining... panic: bremfree: removing a buffer
> > not on a queue
> 
> Okay, I'm not the only one who has had this panic.  I've been looking at
> it, but without essentially zero prior knowledge of the filesystem and no
> computer around with a filesystem I can afford to have corrupted,
> personally I'm afraid to take any sort of action.
/me too. Until I have a proper backup I don't think I will try to push
that box too hard.

> 
> > Before the panic happened, I was compiling/linking some software, and
> > watching TV (bttv/xawtv). The linking process gave some strange error
> 
> My question is, did you do this on a "dirty" filesystem using
> softupdates- that is, one that crashed and came up and fsck was in the
> process of reclaiming unused resources?
> 
No, at least I don't think so. I do have occasional panics with bgfsck
afterwards, but in this case the box was running for some hours, so
there shouldn't have been any fsck activity.

Most of the panics I get seem to relate to disk activity + xawtv
running, although I hadn't had any spare time to try to find the cause
yet.

> I believe the easiest solution is to test in bremfree whether there are
> less than or equal to 1 locks (BUF_REFCNT) on the buffer and if there
> aren't, simply return.  But by no means do I believe this solution to be
> correct; bremfree should not be called if this is the case, I suspect, but
> it is being called in such circumstances in more than one place (my
> crashdump, posted earlier to current_at_, called bremfree at a different
> place)
> 
> Unless, of course, the if(BUF_REFCNT(bp) <=1) assertion inside of
> bremfreel is not correct.
> 
I didn't look deeper into the sources yet, but perhaps someone else can
comment on this?

> -Dan
> 

Regards,
Andreas