qfhca81@memqa.uucp (Henry Melton) (09/14/90)
I have found a consistent method of locking up my AUX2.0 machine. I
was doing some maintence on a large set of files on an appleshare
volume and discovered that if I attempted some tasks, that my AUX OS
would lockup after completing the task. The only out was to hit the
reset switch:-(
Here is my environment: AUX 2.0 recently installed on a IIFX. Appleshare
done with the builtin appletalk. NSF installed and running (I had an
alien volume mounted in the AUX tree). TCPIP done via a EtherportII card
using the AUX 1.1 driver (works great, thank's). I was running MacX
at the time with a couple of local clients, xload and xclock. All X updates
were frozen during the appleshare task.
The task was copying the contents of one large folder into another folder
where there were some duplications/overwrites. The Appleshare volume
was running under Alisa. The task normally locks up the Mac for tens of
minutes. I locked up like this three times before dropping back to MacOs
to complete my maintence tasks. No lockups occurred under MacOS.
The last time it locked up, I had taken the precaution of starting a
telnet session to my AUX from another machine. I had worms running on
that screen all during the appleshare task. The worms locked up about
a minute or less before the open folder updated and the machine locked up.
The terminal session was definately dead at that point.
I am guessing that either:
(a) The X system filled up a buffer with update information that was not
being processed and crashed itself and the os,
or
(b) some driver task in the ethernet or appletalk exceeded some timeout
value.
Anyone really know?
--
Henry Melton qfhca81@memrqa.sps.mot.com
{slow} qfhca81@memqa ..!cs.utexas.edu!execu!sequoia!memqa!qfhca81
{home} henry@hutto ..!emx.utexas.edu!hutto!henry