jim@wor-mein.UUCP (Jim Chekerylla) (08/26/88)
I am running X11V2 on a monochrome Sun 3/60 with a local disk and 4 MB of RAM. It is also a file server for one other Sun 3/60 diskless node. Others are rloging into my machine from some uVAXen. When I run too many demo programs, I get the error message "text: table is full" in my xterm console window and other people's processes (eg. compiles) get killed. My display continues to work just fine. Does anyone know what is going on? It seems if I add more RAM (already ordered), that I'm just pushing the problem off until a heavier load is reached. Jim Chekerylla Quantum Medical Systems Issaquah, WA 98027 206-392-9180 -- ================================================================================ Jim Chekerylla - Quantum Medical Systems - Issaquah, Washington ihnp4 -------------------------> seismo!rochester!bullwinkle ---> !uw-beaver!tikal!wor-mein!jim ucbvax!hplabs!tektronix -------> ================================================================================
dana@dino.bellcore.com (Dana A. Chee) (08/26/88)
In article <1396@wor-mein.UUCP> jim@wor-mein.UUCP (Jim Chekerylla) writes:
I am running X11V2 on a monochrome Sun 3/60 with a local disk and 4 MB of
RAM. It is also a file server for one other Sun 3/60 diskless node.
Others are rloging into my machine from some uVAXen.
When I run too many demo programs, I get the error message "text: table is
full" in my xterm console window and other people's processes (eg. compiles)
get killed. My display continues to work just fine. Does anyone know what
is going on? It seems if I add more RAM (already ordered), that I'm
just pushing the problem off until a heavier load is reached.
What this means is that you have too many different processes for the
operating system's (Unix's) process table. The maximum number allowed
can be found by typing '/etc/pstat -T'. This will show used/allowed
values for various tables in Unix with text being the fourth line.
To increase the number allowed requires you (or your SA) to rebuild
Unix with a higher number. This number should be changed in the file
/sys/YOURMACHINE/param.c on your source machine. Look for the line
'int ntext = ' and change the number there to something reasonable
(ours is set to 24 + MAXUSERS, where MAXUSERS is 10, but is also
settable in the /sys/conf/YOURMACHINE file).
Anyway, hope this helps.
Jim Chekerylla
Quantum Medical Systems
Issaquah, WA 98027
206-392-9180
--
+*************************************************************************+
* Dana Chee (201) 829-4488 *
* Bellcore *
* Room 2Q-250 *
* 445 South Street ARPA: dana@bellcore.com *
* Morristown, NJ 07960-1910 UUCP: {gateways}!bellcore!dana *
+*************************************************************************+mdb@silvlis.COM (Mark D. Baushke) (08/26/88)
> Date: 25 Aug 88 23:26:09 GMT > From: uunet.uu.net!wor-mein!jim (Jim Chekerylla) > To: xpert@athena.mit.edu > > I am running X11V2 on a monochrome Sun 3/60 with a local disk and 4 MB of > RAM. It is also a file server for one other Sun 3/60 diskless node. > Others are rloging into my machine from some uVAXen. > > When I run too many demo programs, I get the error message "text: table is > full" in my xterm console window and other people's processes (eg. compiles) > get killed. My display continues to work just fine. Does anyone know what > is going on? It seems if I add more RAM (already ordered), that I'm > just pushing the problem off until a heavier load is reached. The short answer is that you need to configure your kernel to have more text segments. The easiest "quick fix" would be to bump your MAXUSERS to 12. Another possibility would be to modify /sys/conf/param.c something like this: *** /sys/conf/param.c-dist Mon Jul 7 21:28:32 1986 --- /sys/conf/param.c Thu Aug 25 16:23:06 1988 *************** *** 50,54 **** int nproc = NPROC; int maxuprc = MAXUPRC; ! int ntext = 24 + MAXUSERS; int ninode = (NPROC + 16 + MAXUSERS) + 64; int ncsize = (NPROC + 16 + MAXUSERS) + 64; --- 50,54 ---- int nproc = NPROC; int maxuprc = MAXUPRC; ! int ntext = 36 + MAXUSERS; int ninode = (NPROC + 16 + MAXUSERS) + 64; int ncsize = (NPROC + 16 + MAXUSERS) + 64; A combination of both increasing MAXUSERS and changing param.c is also a possible solution. At our site, Sun 3/60s with only 4MB are configured with MAXUSERS 12 based on the STDT60 kernel and no changes to param.c. Note: Do not use the GENERIC kernel if you can avoid it. Start with STDT60 as a base if possible. This question has been covered in depth recently in the Sun-Spots Digest mailing list. You might consider reading up on this topic by getting copies of recent issues of the Digest from the sun-spots archives. I seem to recall that v6n101 and v6n111 discussed this problem, but you might want to get an index of v6 and get all appropriate issues. The standard header for issues of Sun-Spots Digest contains the following: > Send contributions to: sun-spots@rice.edu > Send subscription add/delete requests to: sun-spots-request@rice.edu > Bitnet readers can subscribe directly with the CMS command: > TELL LISTSERV AT RICE SUBSCRIBE SUNSPOTS My Full Name > Recent backissues are available via anonymous FTP from "titan.rice.edu". > For volume X, issue Y, "get sun-spots/vXnY". They are also accessible > through the archive server: mail the request "send sun-spots vXnY" to > "archive-server@rice.edu" or mail the word "help" to the same address > for more information. Enjoy! ------------------------------------------------------------------------------ Mark D. Baushke Internet: mdb%silvlis.com@sun.com Silvar-Lisco, Inc. Nameservers: mdb@silvlis.com 1080 Marsh Road Usenet: {pyramid,sun}!silvlis!mdb Menlo Park, CA 94025-1053 Telephone: +1 415 853-6411 / +1 415 969-8328
dob@xpiinc.UU.NET (David O. Bundy) (08/31/88)
In article <1396@wor-mein.UUCP> jim@wor-mein.UUCP (Jim Chekerylla) writes: >I am running X11V2 on a monochrome Sun 3/60 with a local disk and 4 MB of >..... > >When I run too many demo programs, I get the error message "text: table is >full" in my xterm console window and other people's processes (eg. compiles) >get killed. .... >It seems if I add more RAM (already ordered), that I'm >just pushing the problem off until a heavier load is reached. I am mailing this to the net since I have answered this about 10 times already and I couldn't figure out a mail path to Jim. Your problem is not memory but your kernel configuration! Buying more memory won't solve it!!! The problem is that the variable ntext in /sys/conf/param.c is set too low! We made the following two changes to make it higher: In /sys/conf change the following two files: ----> GENERIC or whatever your system's configure file is: changed maxusers 4 to maxusers 8 ----> in /sys/conf/param.c changed int ntext = 24 + MAXUSERS; to int ntext = 24 + (4 * MAXUSERS); You then need to do a config GENERIC (or whatever yours is) then go into /sys/GENERIC and do a make depend, and make vmunix. Then copy the new vmunix to where you boot and reboot. Your now ready to start as many clients as you like until you run out of swap space but then you just need more disk! Dave Bundy
dshr@SUN.COM (David Rosenthal) (08/31/88)
You advise people to mess around with the GENERIC configuration files. WARNING: Anyone who is doing ANYTHING AT ALL with a GENERIC kernel except using it to configure a specific kernel for their particular configuration is seeing performance that is MUCH WORSE than they should. GENERIC kernels use much more memory than tailored kernels. In the case of Jim Chekerylla's Sun 3/60, he should base his configuration file on /usr/sys/sun3/conf/SDST60, since his machine has a local disk (SD). If it were diskless, he should be using DL60. For details, see Chapter 9 of the "System & Network Administration" manual. If Jim is running a GENERIC kernel, he is very likely to see "text: table is full" error message (and other errors). The reasons for this are that the GENERIC kernel is not intended for normal use, only for temporary use while you build a tailored kernel. Of course, the real fix for the "text: table is full" message is to upgrade to SunOS4.0, which no longer has a text table for you to run out of space in. On the other hand, with 4.0, it is even more important to configure a tailored kernel. David. REMEMBER - if you're running a GENERIC kernel, you have only yourself to blame for the mediocre performance.