Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!uakari.primate.wisc.edu!ames!uhccux!munnari.oz.au!murtoa.cs.mu.oz.au!ditmela!yarra!cit5!minyos!chudich!rcodi
From: rcodi@chudich.co.rmit.oz (Ian Donaldson)
Newsgroups: comp.sys.encore
Subject: Re: Umax4.3 & NFS (& shared memory size)
Message-ID: <1865@minyos.xx.rmit.oz>
Date: 19 Nov 89 16:24:21 GMT
References: <10396@encore.Encore.COM>
Sender: news@minyos.xx.rmit.oz
Lines: 70

dwm@pinocchio.Encore.COM (Dave Mitchell) writes:

>>> Does anybody know if it supports more than 64k of shared memory?
>>> 
>>> (Umax 4.2 had this limitation and it was the *only* reason we went
>>> to Umax V; regretting it ever since)

>	But, the first poster's question is apparently asking about
>	the sysV compatible shmop(2) routines.  This limit is built
>	into the system configuration program, sysparam(8), and
>	there is no particular reason for its (the limit's)
>	existence.

We tested both share(2) and shmop(2) and both would give us no more
than 64k.  64k appeared to be the limit that sysparam(8) would give us.  
Not having access to include files documenting the format of /Umax.param
didn't help any.

>	You should talk to customer service, and request a custom
>	version of sysparam to work around your problem - it's
>	a very simple change.

Now thats more like it!  A decent answer.  

FLAME ON

What I want to know is why a previous poster from Encore claims that
the problem has been fixed in 1986 and its 1989 (thats 3 years later!)
that we receive a software release and it STILL isn't fixed!!

FLAME OFF

Would somebody at Encore be willing to mail an tar'd/uuencoded binary of such
a sysparam(8) utility to me please (for Umax 4.2, rel 3.3.0, for APC's, which
is the latest we had until we switched)?

If we can get a new sysparam(8) that lets us have more than 64k shared
memory we will probably switch back to Umax 4.2 .

FLAME ON

We told our vendor of this problem and gave them several weeks to
come up with the answer.  We repeatedly asked them to tell us
on progress of the request and insisted it was the prime reason
we couldn't make use of the 64MB memory that we bought.  
(its a research machine for parallel processing architectures)

What the hell happened I don't know, but we didn't get one, so we 
were forced by this action to switch from our quite reliable 
Umax4.2 to a very buggy UmaxV.  It now crashes one or two times
a day for various reasons (lately mostly due to runaway processes filling
up the swap devices, requiring a reboot to clear it... we have 192Mb
of swap; the rest of the time it crashes due to kernel bugs, mostly
activated by processes using lots of shared memory; and then there's
those processes that are stuck in the run state and are unkillable, 
unreschedulable, but just renicable, hogging our cpus; and then
theres the problems with pty's due to a lack of a vhangup(2) after rlogind
opens them... letting other people access your session and shell!!!; the
list is VERY long... [we're running 2.2h])

FLAME OFF

Is there a customer support service for Encore customers via email?
(DIRECT to Encore, NOT via vendors)
I fear our bug reports are NOT getting through to the right people.
(yes we have full software and hardware maintenance)

Ian D
BTW:  what is the current release number for Umax 4.[23]
      (a proper release, not a beta release)