peter@citcom.UUCP (04/14/87)
xxx Every now and then, the console screen on our sun 3/50, 3/180 network fills with the repeating message "text: table is full"; we are unable to repeat the error reliably. We noticed the string by a "strings /unix" as well, but our sun did not come with any programs, only binaries, so we are somewhat out of luck. -- Peter Klosky, Citcom Systems (materiel de telecommunications) seismo!vrdxhq!baskin!citcom!peter
wagner@iaoobelix.UUCP (04/18/87)
> /***** iaoobelix:comp.unix.ques / citcom!peter / 4:10 pm Apr 14, 1987*/ > > Every now and then, the console screen on our sun 3/50, 3/180 > network fills with the repeating message "text: table is full"; > we are unable to repeat the error reliably. We noticed the > string by a "strings /unix" as well, but our sun did not come > with any programs, only binaries, so we are somewhat out of luck. > > -- > Peter Klosky, Citcom Systems (materiel de telecommunications) > seismo!vrdxhq!baskin!citcom!peter > I have also encountered this problem on our Suns. It just tells you that you have been using your swap space a bit generously... The message can be repeated quite easy: setup a number of shelltools running relatively processes, e.g. Emacs, and then try to compile a file with a huge number of preprocessor constants and #includes. Your cpp will print out a message "... killed", and the console window reads "text: table is full". Maybe Sun Inc. can give you more detailed information. Juergen Wagner, (USENET) ...seismo!unido!iaoobel!wagner ("Gandalf") Fraunhofer Institute IAO, Stuttgart
mlandau@Diamond.BBN.COM (Matt Landau) (04/21/87)
> /***** iaoobelix:comp.unix.ques / citcom!peter / 4:10 pm Apr 14, 1987*/ > > Every now and then, the console screen on our sun 3/50, 3/180 > network fills with the repeating message "text: table is full"; Even if the Sun in question does not have a full source license, you should be able to fix this by building a custom kernel as described in the Sun installation documents. The size of the text table is established in the file /sys/conf/param.c, where it is set to a default value of 24 + MAXUSERS (which almost always seems to be too small!). There are two ways you can increase the size of the text table: you can build a kernel with MAXUSERS set to some suitably large number in the kernel description file, or you can change /sys/conf/param.c to use a different formula for ntext. The latter has the advantage that you can selectively increase the size of the text table without incurring the other overhead of increasing MAXUSERS. -- Matt Landau "Oblivion gallops closer, mlandau@diamond.bbn.com favoring the spur, sparing the rein."
mouse@mcgill-vision.UUCP (der Mouse) (05/02/87)
In article <8200007@iaoobelix.UUCP>, wagner@iaoobelix.UUCP writes: >> Every now and then, the console screen on our sun 3/50, 3/180 >> network fills with the repeating message "text: table is full"; >> [...] We noticed the string by a "strings /unix" as well, [...] That just destroyed a lot of your accuracy credibility for me - on Suns it's called /vmunix! If I can't be confident you've reported accurately, it's much harder to diagnose. It also helps if you say what version you are running (3.0, 3.2, etc). > I have also encountered this problem on our Suns. It just tells you > that you have been using your swap space a bit generously... The > message can be repeated quite easy[sic]: [run pgms to gobble memory] Except that "text: table is full" is not that problem. Text table is full means that too many distinct programs are running at once. A program which is loaded with -z format (which is the default), when executed, has the text segment read-only and shared among all processes (on that machine) executing that program. There is a hard maximum, compiled into the kernel, on the number of such text segments active. When the kernel runs out, you get "text: table is full". I have gotten this message under circumstances that convince me that the Sun kernel (version 3.0, at least) loses slots, that is, it will sometimes leave them marked as in use when they really aren't, so eventually there are none left even if there aren't many processes running. Only fix I know of is to reboot the complaining machine. der Mouse (mouse@mcgill-vision.uucp)
pac@munsell.UUCP (05/12/87)
In article <752@mcgill-vision.UUCP> mouse@mcgill-vision.UUCP (der Mouse) writes: >I have gotten this message [text table full] under circumstances that >convince me that the Sun kernel (version 3.0, at least) loses slots, >that is, it will sometimes leave them marked as in use when they >really aren't, so eventually there are none left even if there aren't >many processes running. Yes, I have seen this also under 3.0. I was finally able to repeat it reliably by: running dbx, running a program, stopping at a breakpoint, re-compiling it, and running it again without first telling dbx to "kill" it. Sun agreed with me that it was there, that it wasn't a known dbx bug, and that it wasn't there under 3.2. (This implies that the bug lived elsewhere and dbx just happened to expose it, it also implies that there are other ways to lose slots) dbx no longer has this failing under 3.2, so I presume the bug was fixed. pZ -- Paul Czarnecki -- USENET, It's not just a job, but an adventure. {{harvard,ll-xn}!adelie,{decvax,allegra,talcott}!encore}!munsell!pz
ittfb@dcatla.UUCP (Thomas F. Blakely) (05/12/87)
>In article <8200007@iaoobelix.UUCP>, wagner@iaoobelix.UUCP writes: >>> Every now and then, the console screen on our sun 3/50, 3/180 >>> network fills with the repeating message "text: table is full"; >>> [...] We noticed the string by a "strings /unix" as well, [...] We've had this problem under SunOs 3.2, and _not_ on earlier versions. It seems they either shrank the process table in 3.2 or made it hard (I suspect it has to do with the Sys V compatibility stuff). If you haven't already, make MAXUSERS in the config file for your kernel 16. If this still doesn't fix it, SUN has a patch which will allow you to set MAXUSERS even larger. We have it at 16 on most of our machines, 32 on our ND server. That solved the problem for good. Tom Blakely {akgua, gatech, sun!sunatl}!dcatla!ittfb
guy%gorodish@Sun.COM (Guy Harris) (05/13/87)
> It seems they either shrank the process table in 3.2 or made it hard > (I suspect it has to do with the Sys V compatibility stuff). Well, your suspicions are wrong. It has nothing whatsoever to do with the System V compatibility stuff. The kernel changes for that were some minor tweaks to some existing system calls, some additional features in the tty driver, and the System V IPC code (message queues, semaphores, shared memory) - and that's it. Furthermore, the size of the process table didn't change in 3.2 - but then that wouldn't make any difference, since you're *not* running out of process table slots, but text table slots! However, the size of the text table didn't change either. The size of both the process and text table is set solely in "param.c", which is distributed as part of every release. The sizes of both those tables, as well as several other parameters, are functions of MAXUSERS; the functions in question did not change between 3.0 and 3.2. A bug in earlier releases that caused text table entries to be lost when the use of an image fetched via NFS was terminated (either by the process using that image "exec"ing another image or by that process exiting) if the NFS server in question was down or slow in responding was fixed in 3.2. (The code has to get the modes of the image file, in order to know whether it's a "sticky" image or not; if the attempt to get the modes failed, as it would do if the server didn't respond, the code acted as if the image were sticky.) There may have been another bug introduced into 3.2, but I'd suggest checking whether you don't just have more different daemons running on your new system.