Subject: Re: Simple way to panic arm kernels
To: Richard Earnshaw <firstname.lastname@example.org>
From: Richard Earnshaw <Richard.Earnshaw@arm.com>
Date: 04/26/2004 10:17:47
On Sun, 2004-04-25 at 21:50, Richard Earnshaw wrote:
> > I've seen the panic triggered by assertion at uvm_bio.c:257 on both
> > netwinder and shark (both diskless):
> > KASSERT(umap->refcount != 0);
> > I reliably get it running a test suite that executes a bunch of
> > commands with output to file. I get it when the output file is either
> > on nfs or mfs.
> > I have just reproduced the same panic with:
> > $ yes | sed 1000000q | while read; do \
> > ( echo -n 1 >>XXX; echo -n 2 >>XXX; echo -n 3 >>XXX ); \
> > done
> I've finally managed to track this down to revision 1.8 of
> That's somewhat odd, since I can't really see why that patch would
> introduce any sort of race condition that wouldn't have existed previously
> (and presumably that is what is happening). But the simple fact is that
> kernels built from code before that change are stable, and kernels built
> afterwards (or earlier kernels with that change applied) are not.
A 'current' kernel with frame.h backed off to revision 1.7 ran the above
test for 9 hours last night without panicing. That's about 9 times
longer than I've ever seen a broken kernel manage.