Filepro-list Digest, Vol 42, Issue 43

[Jay R. Ashworth]

On Thu, Jul 26, 2007 at 03:48:57PM -0400, Kenneth Brody wrote:
> Quoting Jay R. Ashworth (Thu, 26 Jul 2007 14:40:00 -0400):
> [...]
> > Cause, in my 23 years of experience, I've *never* had a user break a
> > *nix machine.  Ever.  I'm only had 6 panics in that time, and 4 of them
> > were bad hardware.  1 a bad driver, and I never did trace down the
> > other one.
> [...]
> 
> I saw the "shut her down, Scotty" message a couple of times.  I saw a
> few actual "panic" crashes over the years.

Ah, yes: Bugchk: SCKMUD

(Or something like that).

As I recall, it means that the Xenix kernel got a Can't Happen of some
sort back from the IO coprocessor.

> I also ran into two bugs in kernels that would lock things up.  One, on
> an NCR Tower, would freeze the entire system if you did the equivalent
> of "unlink(-1)".  (No panic message.  The entire system simply stopped.)

Yeah, that's a bug.

> Another, on a SCO box, would cause an i-node to be kept locked at the
> kernel level, meaning any process which attempted to access that i-node
> would freeze solid.  (By "freeze solid", I mean that the process was in
> a wait state that even "kill -9" couldn't get out of.)  I never did find
> the actual cause, but I was able to repeat the lock on demand.

kill -9 can't kill *lots* of stuff, actually, the most common case
being an IOwait on a stuck 'fast' device.  (IO to 'slow' and 'fast'
devices is handled differently with respect to interruptibility.  Fast
devices were expected to return quickly enough in the general case that
their accesses couldn't be otherwise interrupted.)

Cheers,
-- jra
-- 
Jay R. Ashworth                   Baylink                      jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com                     '87 e24
St Petersburg FL USA      http://photo.imageinc.us             +1 727 647 1274