simpson@spp3.UUCP (Scott Simpson) (06/18/88)
We are running stock SunOS 3.5 on a Sun 3/60 (diskless) and we keep getting
the error message "text: table is full" error message after our Suns have
been up a bit. When this happens, the OS kills our processes. I have
even gotten these error messages when I have only 1 shell running and I am
the only person on the machine. There are not a whole lot of other root
processes sitting around either. How do you make your text table bigger?
(We are a binary site). I tried increasing the number of our users in our
kernel to no avail thinking that might increase the size of the kernel tables.
Here is the head of our kernel config file
machine "sun3"
cpu "SUN3_60"
ident "CLIENT"
timezone 8 dst
maxusers 8 # Made this puppy bigger
options INET
#options SYSACCT
#options QUOTA
options NFS
options NIT
options IPCMESSAGE
options IPCSEMAPHORE
options IPCSHMEM
config vmunix root on nd
pseudo-device pty
pseudo-device bk
pseudo-device ether
pseudo-device loop
pseudo-device nd
pseudo-device win128
pseudo-device dtop4
pseudo-device ms3
pseudo-device kb3
...
--
Scott Simpson
TRW Space and Defense Sector
...{decvax,ihnp4,ucbvax}!trwrb!simpson (UUCP)
trwrb!simpson@trwind.trw.com (Internet)guy@gorodish.Sun.COM (Guy Harris) (06/21/88)
> We are running stock SunOS 3.5 on a Sun 3/60 (diskless) and we keep getting > the error message "text: table is full" error message after our Suns have > been up a bit. When this happens, the OS kills our processes. I have > even gotten these error messages when I have only 1 shell running and I am > the only person on the machine. There are not a whole lot of other root > processes sitting around either. How do you make your text table bigger? > (We are a binary site). I tried increasing the number of our users in our > kernel to no avail thinking that might increase the size of the kernel > tables. You increase the number of users. Check out "param.c"; "ntext" is computed as "24 + MAXUSERS". You may just not have increased it by enough, or there may be a "leak" (I fixed one such leak in 3.2, but there may be others left; there aren't any such leaks left in 4.0, since 4.0 doesn't have a shared text table...). Note: despite what at least one person believes, increasing "maxusers" does *not* violate the terms of your Sun license nor does it violate the terms of the AT&T binary license. "maxusers" is not used to enforce maximum user limits; I think that's handled by bundling the prices of a license expansion into the price of the terminal muxes.
dieter@nmtsun.nmt.edu (The Demented Teddy Bear) (06/21/88)
I'm having trouble convincing trwind.trw.com that it can talk to trwr (doesn't grok trwr!simpson@trwind.trw.com), so I'm posting. Someone will surely explain in gory detail if I've gotten something wrong :-). In article <507@spp3.UUCP> you write: >We are running stock SunOS 3.5 on a Sun 3/60 (diskless) and we keep getting >the error message "text: table is full" error message after our Suns have >been up a bit. When this happens, the OS kills our processes. I have >even gotten these error messages when I have only 1 shell running and I am >the only person on the machine. There are not a whole lot of other root >processes sitting around either. The key is the number of *different* processes that are running. Fifteen /bin/csh processes use one text table slot. However, /bin/csh, /usr/bin/ suntools, /usr/bin/othertools, and /usr/local/bin/emacs use four text slots. If this still isn't clear, drop me a note. I'll try to do better. >maxusers 8 # Made this puppy bigger >... You probably want maxusers to be 10 or 12, if that doesn't cause problems. Since 3/60s have 8 Mb memory (I believe), that should work fine. Next step is in /usr/sys/conf/param.c, around line 50, is a line that reads "int ntext = N + MAXUSERS;", where N is some number. You might want to increase N. We're using 24, and things seem to work fine. However, our MAXUSERS is 16, so you might want to add a fudge factor. >pseudo-device win128 >pseudo-device dtop4 >pseudo-device ms3 >pseudo-device kb3 >... You can make up for the space used by the extra text slots by reducing these numbers some. Does your 3/60 really have 3 mice and 3 keyboards? If you (as I suspect) only have one of each, change "ms3" and "kb3" to "ms1" and "kb1" respectively. If you only have one monitor, you can also reduce "dtop4" to "dtop1". "win128" says you can have up to 128 windows/pixrects (effectively). There's actually a fudge factor of about 2.5 in that, so call it 50. Do you *ever* have 50 windows at a time? It seems unlikely. We're running that particular value at 32, and have never had any problems with it. Good luck. Dieter (3.2 source is nice. Too bad we're running 3.5) Muller -- Welcome to the island. You are number six. ...cmcl2!lanl!unm-la!unmvax!nmtsun!dieter dieter%nmt@relay.cs.net <-- most likely to succeed dieter@nmtsun.nmt.edu
rbj@arpa.icst-cmr (Root Boy Jim) (06/24/88)
? From: Guy Harris <guy@gorodish.sun.com> ? Note: despite what at least one person believes, increasing "maxusers" does ? *not* violate the terms of your Sun license nor does it violate the terms of ? the AT&T binary license. "maxusers" is not used to enforce maximum user ? limits; I think that's handled by bundling the prices of a license expansion ? into the price of the terminal muxes. This is a very good point. MAXUSERS generally sizes various tables, and should not be construed as a limit on the number of real users. We have a Sequent machine which enforces the number of *logins* on both real and pseudo ttys (rlogin == login) in /etc/init with the aid of a fake entry in /etc/passwd. So the only (minor) point I would add to Guy's posting is that terminal muxes are not entirely the issue, as they do nothing to limit network access. However, you can be sure that vendors will force you to upgrade your license to cover all the tty ports provided by muxes, unless you can convince them that you want to run another 16 laser printers off a tty device :-) And isn't it nice to see Guy and me being so polite to each other these days? (Root Boy) Jim Cottrell <rbj@icst-cmr.arpa> National Bureau of Standards Flamer's Hotline: (301) 975-5688 The opinions expressed are solely my own and do not reflect NBS policy or agreement Careful with that VAX Eugene!
mouse@mcgill-vision.UUCP (der Mouse) (06/26/88)
In article <507@spp3.UUCP>, simpson@spp3.UUCP (Scott Simpson) writes: > We are running stock SunOS 3.5 on a Sun 3/60 (diskless) and we keep > getting the error message "text: table is full" error message after > our Suns have been up a bit. [...] I have even gotten these error > messages when I have only 1 shell running and I am the only person on > the machine. Growing the text table may do nothing but increase the time your machine can be up until it dies. I understand that under some circumstances, when an NFS server fails (times out) when the client is trying to demand-load text segment pages from the image file, the client's kernel may lose a text table slot. And if you run out of text table slots this way? The only cure I know of is to reboot the client. > How do you make your text table bigger? (We are a binary site). The simple way is to patch ntext in /vmunix and reboot: # adb -w /vmunix _ntext?D _ntext: _ntext: 28 (Hmmm, 28 slots? Let's up it to 50.) _ntext?W 0t50 _ntext: 0x1c = 0x32 $q (There. Now reboot....) # /etc/fastboot (Some things can be patched in the running kernel and take effect immediately. _ntext is not one of these; you must patch the kernel file and reboot.) This change will go away next time you build a kernel. Most kernel configuration schemes have a way to override the default values for things like ntext; see param.c in your system configuration directory. der Mouse uucp: mouse@mcgill-vision.uucp arpa: mouse@larry.mcrcim.mcgill.edu