Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!apple!decwrl!deccrl!oz.crl.dec.com!ran
From: ran@oz.crl.dec.com (Randy Osborne)
Newsgroups: comp.sys.encore
Subject: Re: Installing Umax 4.3.
Message-ID: <1990Jun8.195043.25205@crl.dec.com>
Date: 8 Jun 90 19:50:43 GMT
References: <9006081439.AA01527@cs.niu.edu>
Sender: news@crl.dec.com (USENET News System)
Reply-To: ran@oz.crl.dec.com (Randy Osborne)
Organization: DEC Cambridge Research Lab
Lines: 46

In article <9006081439.AA01527@cs.niu.edu>, rickert@CS.NIU.EDU (Neil
Rickert) writes:

	... lots about problems installing UMAX 4.3

We had the same sort of problems here installing UMAX 4.3.

|>  I had to do some partitioning by hand, after running the script, just to
|> have big enough user partitions.  But, as I feared, the non-selectable

We had to do this anyway since we wanted to increase the size of the paging
partitions. We didn't want to gamble that Encore might have actually
fixed a kernel bug in UMAX 4.3 that existed in 4.2 (and which seemed to also
exist in a beta release of UMAX 4.3 at MIT). The bug occurred when the system
ran out of swap space. Certain processes would hang in the kernel and because
they were in the kernel, they were unkillable and thus we could not get them to
release their storage. Except by booting the machine. Anybody else ever had
problems like this? With 64Mb of swap space I was able to cause the problem
quite consistently by starting up a Lisp with a 30MB heap. This problem seems
to be behind us now that we have 256MB of swap space. Others may also want
to consider increasing the swap space (unless you can get some definitive
info from Encore that the problem has been fixed - we couldn't).

|>      well enough that I could login at a video terminal and run devconfig
|>      to fix up the bad DCT entries.

I found that devconfig was even brain damaged running interactively at a
video terminal. It wouldn't let me store changes into the DCT because of
a detected
"error" in boot order it found in my changes (which were correct). I had
to edit
the Umax.config file directly. The cause of all the mess with booting off the
bkuproot device seems to be because the installation script makes most
of the non-terminal devices in /dev bootable, and leaves bkuproot as the
first bootable
device in the DCT (which is searched linearly for a boot device at boot
time). I
told Judy Leach at Encore about this mess, but I guess my advice for
others would
be to just edit the Umax.config file directly after booting off bkuproot and
then reboot. Oh yes, there's no documentation for the Umax.config file format
and Judy Leach at Encore couldn't find any either - but it's all in ASCII and
you'll figure it out as I did. This seems to be what Encore customers have to
do.

Randy Osborne