Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!gatech!hubcap!ncrcae!ncrlnk!uunet!milhow1!how
From: how@milhow1uunet.UU.NET (Mike Howard)
Newsgroups: comp.unix.xenix
Subject: Re: system lockup
Summary: no crash on my box
Keywords: bug?
Message-ID: <238@milhow1uunet.UU.NET>
Date: 18 Feb 89 05:41:22 GMT
References: <60@estinc.UUCP> <555@marob.MASA.COM> <107@jcc-one.UUCP>
Reply-To: milhow1!how@uunet.UU.NET (Mike Howard)
Organization: Miller/Howard Investments, Malden-on-Hudson, NY
Lines: 35

In article <107@jcc-one.UUCP> djones@jcc-one.UUCP (Dan Jones) writes:
>I can confirm Fred's problem.  However I got a little suspicious, so logged in
>via a terminal line and tried it -- all was fine.

My system locked for about 2 minutes (1:53 according to time(CP)) and
then came back.  This was with nothing else going on.

A second test, with a couple of things going on (a few shells and
a cu): `date ; time tst ; date' - resulted in:
day of month 00:13:17

real  18:12.2
user      0.0
sys    1:49.4

day-of-month 00:31.29

The actual elapsed time was about 18 minutes, whereas the clock
only advanced 18 seconds.

As a guess: the `write()' is done as a more or less atomic operation
and the kernal fires the entire 1 Meg of zeros out at spl7 so that
the system `hang's.  [ if this is true, then it also implies that
the kernal is smart enough to not page in memory which is initialized
to zero and is being read, because my disk is not read ].  This is
supported by the clock not working correctly during the test: the
timer interupt is at spl6 and so is masked out during the spl7
time.

If there is a bug, it is in SCO's handling of tty interupts.
Anybody competent out there want to comment on tty drivers?

-- 
Mike Howard
uunet!milhow1!how