> 
> | What does this all mean and what can be done? Jeez- that's tougher. Can
> | you reproduce this at will or was it a one time?
> 
> Well, it happened once this evening after the box had been up
> several days doing not much more than running rc5des and ntp and
> a couple other minor things that don't do much disk activity.
> 
> I hadn't seen it before, over a couple months of on-and-off use, 
> during which I did several disk-smashing things.
> 
> It also happened twice more - once when coming up multiuser,
> once after it had been multiuser for a while.
> 
> The box is off now.  It didn't need to be on and I figured I'd
> hear back from someone with tips.   However, maybe it was thermal
> or something came loose over time thanks to vibration, or maybe
> it will do it again.
> 
> Turning it on...
> 
> ... leads to it coming up multiuser all happily.
> 
> I will watch it and even try to provoke it a bit.  If I succeed,
> what should I do?
> 

One of several things:

	+ Wait for me to try and revamp some of the reset code some more.
	  There's clearly at least one idiocy right there in that the
	  failure to reset, no matter how harsh, shouldn't lead to a state
	  where all I/O starts getting bounced.

	+ Run a couple of test kernels for me.

I suspect that this resulted from a 'rare' event- some spoodge that bunged
a command. These things happen. Such is life. The real problem to me is
the Keystone Kops foulups that happened afterward. Sigh.

-matt