Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!caen!umich!terminator!pisa.ifs.umich.edu!rees
From: rees@pisa.ifs.umich.edu (Jim Rees)
Newsgroups: comp.sys.apollo
Subject: Re: Model Thread Limit in DSEE
Message-ID: <4fefa2ea.1bc5b@pisa.ifs.umich.edu>
Date: 21 Feb 91 00:30:45 GMT
References: <1991Feb20.153655.6540@digi.lonestar.org>
Sender: usenet@terminator.cc.umich.edu (usenet news)
Reply-To: rees@citi.umich.edu (Jim Rees)
Organization: University of Michigan IFS Project
Lines: 25

In article <1991Feb20.153655.6540@digi.lonestar.org>, kgallagh@digi.lonestar.org (Kevin Gallagher) writes:

  So, "Why did SR10.3 fix it?"  HP/Apollo's answer is that the model
  thread size limit is associated with a system "constant" SEG_SIZE
  in SR10.2.  In SR10.3 this constant was changed to a function (?).
  In SR10.2, the limit is 32k.  Information on the new limit for the
  "function" SEG_SIZE in SR10.3 was unknown by our contact.

The function seg_size() returns the virtual memory segment size.  The
sr10.2 version just returned a constant 32k:

32173C0: LINK.W      A6,#FFFC 
32173C4: MOVE.L      #8000,D0 
32173CA: MOVEA.L     D0,A0 
32173CC: UNLK        A6 
32173CE: RTS /

The sr10.3 version gets the value out of PM private data, where it was
presumably stored at node boot time.  If you're using a newer node that has
an MMU that supports the new segment size (dn2500?), then switching to
sr10.3 will give a larger return value from seg_size().

If you're a cowboy you might be able to patch the place in dsee where it
calls seg_size().  This may void your warranty.  I do not recommend trying
to patch the constant in the pmlib.