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 
> arch/arm/include/arm32/frame.h
> 
> 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.