Path: utzoo!attcan!uunet!ncrlnk!ncr-sd!hp-sdd!hplabs!ucbvax!bloom-beacon!RTI.RTI.ORG!shaddock
From: shaddock@RTI.RTI.ORG (Mike Shaddock)
Newsgroups: comp.windows.x
Subject: text: table is full
Message-ID: <8810051131.AA27214@rtivs1.UUCP>
Date: 5 Oct 88 11:31:13 GMT
References: <802@mace.cc.purdue.edu>
Sender: daemon@bloom-beacon.MIT.EDU
Organization: The Internet
Lines: 41


   Date: 5 Oct 88 01:33:47 GMT
   From: mace.cc.purdue.edu!mtr@j.cc.purdue.edu  (Miek Rowan)
   Organization: Unix Groupie
   References: <8810041919.AA14373@work8.icase.edu>
   Sender: xpert-request@athena.mit.edu


   This has been discussed in Sun-spots recently.  The quick 
   way to fix it is to up the MAXUSERS setting. (This is a define
   in the kernel sources (or headers if you have only objects) and
   this also requires that you generate a new kernel once you 
   change it)

   We set this in a Makefile define.  I think the SunOS4.0 comes
   with it set at 4 (FOUR!?!?)  We have it at 16.  Not to say that 
   is right, wrong or whatever.  

   The problem is that this increases some other tables that have 
   nothing to do with your problem.  Maybe a better thing is to 
   increase NPROCS -  Anyone wanna back that up?

   At a minimum, someone will correct me and you'll get a real
   answer ;-)

   mtr

Actually, you need to increase ntext in param.c, since they are
running out of text table slots, not proc table slots.  In param.c
there is a line which normally reads

	int ntext = 24 + MAXUSERS;

I changed mine to be

	int ntext = 36 + MAXUSERS*2;

However, I have a 3/160C with 16M of memory; you may want to make
yours smaller based on how much memory you have.  If you make MAXUSERS
too big, you can get a kernel which not only will not boot, but will
lock your system up.