In article <1992Feb28.003028.29811@cs.brown.edu> cgy@cs.brown.edu (Curtis Yarvin) writes:
quoted text
>In article <1992Feb27.224616.11648@colorado.edu> drew@cs.colorado.edu (Drew Eckhardt) writes:
>|In article <1992Feb27.032547.2035@ccu.umanitoba.ca> umthom61@ccu.umanitoba.ca (Adam Thompson) writes:
>|>I d/l (using kermit - when will serial I/O work properly?)  all the compiler
>|>binaries, as86, bison, flex, gcc, and stuck them into /tmp.
>|>Then I try 'uncompress as86.tar.Z' ... it works for a little while, then
>|>hangs the machine.  I can type for about ~15-25 seconds after I execute
>|>(fg or bg - doesn't matter except in timing) and then the whole machine just
>|>sits there ... a nice-looking paperweight. 
>|> 
>|
>|If you have corrupt .Z files, this is what happens.  Your choices are
>|1.  Re download.
>|2.  Get tars on floppy from some one else.
>
>Even if you do have corrupt .Z files, this shouldn't happen.  If compress
>can crash a machine this way, there is a kernel bug involved.
>

By an amazing coincidence, I did this, (kermit text mode on .Z file)
right after mailing Adam Thompson the probable cause.  I found it hung
the particular shell; the other shells available via virtual console
still worked, and when I killed the uncompress from one of them, the
original shell also worked.  So I guess just the uncompress process
hangs. (At least sometimes)

-- 
Al - aclark@netcom.com - My opinions are my own.
      *** Practice random kindness and senseless acts of beauty! ***