> 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.

R.