Sun-Spots-Request@RICE.EDU (William LeFebvre) (05/09/88)
SUN-SPOTS DIGEST Friday, 6 May 1988 Volume 6 : Issue 74 Today's Topics: Re: A Question about Shared memory (2) Re: Problems with rasfilter8to1 '-d' Re: Problems with philips monitors Re: Conference room sized color displays Sun-3 Service Announcement: PROM upgrade Problem and Workaround To Too Many Fields In L.sys File slip for suns running 3.n--including Sun-4's? printing tex dvi files on a sun laserwriter: psdf? Changing software carrier flags? 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. ---------------------------------------------------------------------- Date: Wed, 27 Apr 88 09:34:41 PDT From: weiser.pa@xerox.com Subject: Re: A Question about Shared memory (1) Reference: v6n63 To share more than 512kbytes of memory on SunOs 3.x (x>=2, I think), you need to rebuild a kernel. In the conf file for your particular machine, in among all the options (like "options NFS", add two lines like the following): options SHMPOOL=8096 # max number of shared kbytes, total options SHMSEG=64 # max shared segments per process To just increase the max shared size, change SHMPOOL. But for my application I was sharing lots of segments, so I also increased SHMSEG. Of course, all of the shared pages are locked in real memory, so make sure you have enough real memory. The above SHMPOOL setting locks down 8Mbytes, which works for me with a 16M machine. But all changes for the better with SunOS 4.0, coming soon I think. -mark ------------------------------ Date: 27 Apr 88 16:33:15 GMT From: stevo@jane.jpl.nasa.gov (Steve Groom) Subject: Re: A Question about Shared memory (2) Reference: v6n63 William Moran <moran-william@yale.arpa> write: >Is there any reason that the limit on shared memory is 512k in Sun OS 3.5? >My life would be made easier if this limit could be raised. Thanks. > >Bill Moran >moran@cs.yale.edu This is entirely configurable. Read chapter 7 entitled "Tuning IPC System Parameters" of the "System V Enhancements Overview", one of those little white-with-blue-stripes booklets that Sun ships with the manuals. Specifically, the following config file IPC options have these meanings, default values in []'s. To use, add a line in your config file options XXXXXX=nn where XXXXXX is the parameter and nn is the value. Then rebuild your kernel. Consult config(8) for the whole scoop on the config file. IPC Message Parameters: MSGPOOL - size (Kbytes) of kernel's message memory pool, may not exceed 255. [8] MSGMNB - max # of message bytes that may be on any particular message queue. [2048] MSGMNI - max # of uniquely identifiable message queues that may exist simultaneously, each increment reserves 49 bytes of kernel memory. [50] MSGTQL - total # of undelivered messages that may exist at any time. Each increment reserves 12 bytes. [50] IPC Semaphore Parameters: SEMMNI - max # of uniquely identifiable semaphore clusters that may exist simultaneously. No reason for this to be larger than SEMMNS. Each increment reserves 32 bytes. [10] SEMMNS - max # of semaphores in the system. Each increment reserves 8 bytes. [60] SEMUME - max # of semaphores per process that may simultaneously have non-zero adjust-on-exit values. Must be less than 32768. [10] SEMMNU - max # of processes that may be using the IPC SEM_UNDO feature simultaneously. No reason to set larger than the system's max # of processes (16*maxusers). Each increment reserves 14+(8*SEMUME) bytes. [30] IPC Shared Memory Parameters: SHMPOOL - total amount of shared memory (Kbytes) that may be in use in the system at any time. Current implementation allocates shared memory as non-pageable, so indisciminate use can lead to system deadlock. Size is rounded up to page size of target machine (Sun2=2Kb, Sun3=8Kb). [512] SHMSEG - max # of shared memory segments taht may be attached to a single task. Each increment reserves 4 bytes per process descriptor, or 4*(16*maxusers) bytes. SHMMNI - max # of shared memory segments that may simultaneously exist in the system. Each increment reserves 42 bytes. [100] /* Steve Groom, MS 168-522, Jet Propulsion Laboratory, Pasadena, CA 91109 * Internet: stevo@elroy.jpl.nasa.gov UUCP: {ames,cit-vax}!elroy!stevo * Disclaimer: (thick German accent) "I know noothingg! Noothingg!" */ ------------------------------ Date: Wed, 27 Apr 88 08:29:46 +0200 From: jeremy cook <jeremy@kheops.cmi.no> Subject: Re: Problems with rasfilter8to1 '-d' We had exactly the same problem when we upgraded to 3.4. There's something wrong with the upgrade script when going from 3.2 to 3.4 which I have not investigated but the result is that the links for some graphics utilities are not put in and you are left with old (3.2 ?) executables instead. The remedy is:- cd /usr/bin rm clear_colormap rasfilter8to1 rasrepl screenload ln -s screendump clear_colourmap ln -s screendump rasfilter8to1 ln -s screendump rasrepl ln -s screendump screenload ps: maybe you should check that you have the correct version of screendump first. Ours is dated Apr 22 1987 and 'sccs what screendump' says that modules for the above 4 utilities are included in the code. -- Jeremy Cook [[ Thanks also to Jim Frew <frew%huevos@hub.ucsb.edu> for a similar note. "rasfilter8to1" has indeed been merged into "screendump". --wnl ]] ------------------------------ Date: Wed, 27 Apr 88 09:36:57 +0200 From: jeremy cook <jeremy@kheops.cmi.no> Subject: Re: Problems with philips monitors Reference: v6n44 I gather from our service guy that its a problem with a/the thyristor. My Philips telly throws a wobbler every time the fridge switches on. It's all due to the same problem apparently, monitors and tellys alike. ------------------------------ Date: Wed, 27 Apr 1988 11:12-EDT From: David.Maynard@K.GP.CS.CMU.EDU Subject: Re: Conference room sized color displays >From: bob@allosaur.cis.ohio-state.edu (Bob Sutterfield) >... >I've been pretty impressed with the Electrohome ECP Graphics projector. >It does color and handles scan rates of 15-80KHz, so you should be able to >get your PCs in there too. I saw a demo of an Electrohome attached to a Sun-3/160C. It took video directly from the RGB lines, and worked pretty well on color graphics displays with black or dark backgrounds. However, it wasn't sharp enough to read black-on-white text displays (SunView buttons for example). The display may not have been adjusted properly so you might be able to to better. By far the best projection monitor I have ever seen is marketed by IBM (I forget the number). I believe that Sony actually makes the projector. It will display a near-perfect picture (excellent color, good black/white contrast with little smearing) directly from the RGB. The IBM display autosyncs to the scan rate (as does the Electrohome). The IBM display costs more I believe. However, it seemed to be clearly better. Serious buyers should probably consider both of them. Depending on your needs, either could be a good choice. David P. Maynard (dpm@cs.cmu.edu) Dept. of Electrical and Computer Engineering Carnegie Mellon University Pittsburgh, PA 15213 -- Views expressed are mine only, not those of CMU or anyone else. ------------------------------ Date: 27 Apr 88 03:08:44 GMT From: elroy!david@ames.arc.nasa.gov (David Robinson) Subject: Sun-3 Service Announcement: PROM upgrade Sun-3 SERVICE ANNOUNCEMENT April 15, 1988 1/4" Tape Format to Change for Sun-3 Software Products -- PROM Changes Necessary for Some Older Sun-3's -- To improve quality of software distribution tapes and reduce software installation time, Sun is changing the format of 1/4" cartridge tapes for Sun-3 products. The format change is planned in May with the delivery of SunOS 4.0 and will apply only to cartridge tapes which contain system software for Sun-3, 68020-based workstations. Tape formats will remain the same for Sun-2, 68010-based software tapes and Sun-4, SPARC-based software tapes. (Note: Sun-4 systems currently utilize this format.) This announcement describes the new format, and explains how to determine if your Sun-3 workstation needs a new PROM to read the 1/4" SunOS 4.0 distribution tapes. Today, Sun uses a 4-track, QIC-11 format for Sun-3 software products shipped on 1/4" tape. To improve product quality and reduce software installation time, Sun will begin shipping Sun-3 system software on 9-track, QIC-24 format 1/4" tape. All 1/4" tape drives and tape controllers Sun has shipped with Sun-3 workstations will read this 9-track format. However, some early Sun-3's may have boot PROM's which do not enable the 1/4" controller to read QIC-24 format tapes. ** Do You Need a New PROM? This section tells you how to check if you need a new PROM to read 9-track, QIC-24 format tapes. The next section lets you know how to get a newer version of the PROM if you need one. The Sun-3 products which might be affected by the change in tape format are: Sun-3/50 Sun-3/60 Sun-3/75 Sun-3/160 Sun-3/260 Sun-3/280 Early revisions of the Sun-3 PROM's do not "understand" QIC-24 tape. You can check the revision level of your PROM by halting the system and typing kb after the ">" prompt from the PROM monitor. If you don't know how to halt your system safely, find someone who does, or refer to your System Administrator's Guide. The revision level of the PROM you need depends on the tape controller in your system. It's easy to tell which type of tape controller is in your system just by inserting a tape in the tape drive. After you insert a 1/4" tape in the tape drive, observe the red or green light on the front of the drive. One kind of controller (Emulex) turns on the light when you insert the tape. If you have this controller, you need a PROM with a revision level greater than 1.7. The other kind of controller (Sysgen) does not turn light on. You need a PROM with a revision level greater than 2.6 for this controller. Sun's current PROM revision level is 2.6, so if you have an Emulex controller and your PROM revision level is 1.7 or less, you can call Sun now for an upgrade PROM. For customers with the Sysgen type controller, Sun will have a 2.7 version of the PROM's available by the time the 4.0 version of the SunOS begins shipping. You should call Sun for a 2.7 version of the PROM when you receive your copy of SunOS 4.0. If you load a QIC-24 tape into a workstation that can read only a QIC-11 tape, you will get an 86A8 or an 86A0 error from the controller. This error indicates that the controller was unable to read the header block on the tape. Since this error may result from a faulty tape even if the tape controller can read QIC-24 tapes, check your PROM revision level or try another tape if you get this error message. ** If You Need a New PROM... ** and You HAVE On-Site or Comprehensive Support If you have an On-site Hardware or Comprehensive support contract, Sun will install the new PROM's for you. Please phone the Sun Response Center at (800) USA-4-SUN, request Hardware Service (press "#1" on your phone), and schedule PROM installation. If you want to install the PROM's yourself, you should call the (800) USA-4-SUN phone number, request Field Service, and ask for a Sun-3 PROM Upgrade Kit to be mailed to you. ** If You Need a New PROM... ** and You DO NOT HAVE On-Site or Comprehensive Support If you do not have an On-Site or Comprehensive support contract, Sun will mail you this kit at no charge. You do not need to have a support contract to receive this PROM. The kit contains instructions for replacing the PROM chip on your CPU board, a process that takes about 10-15 minutes. You should call Sun's (800) USA-4-SUN phone number, request Hardware Service (press "#1" on your phone), and ask for a Sun-3 PROM Upgrade Kit. If you want Sun to install the PROM's, Sun will bill you on a time (but not materials) basis. ** Reading Your Existing QIC-11 Tapes Sun-3 systems which are upgraded with the latest version of the PROM will continue to read QIC-11 tapes. Your upgraded system will read all tapes you produced before you upgraded. David Robinson elroy!david@csvax.caltech.edu ARPA david@elroy.jpl.nasa.gov ARPA {cit-vax,ames}!elroy!david UUCP Disclaimer: No one listens to me anyway! ------------------------------ Date: Tue, 26 Apr 88 20:22:27 EDT From: umix!lokkur!scs@rutgers.edu (Steve Simmons) Subject: Problem and Workaround To Too Many Fields In L.sys File David Steinhoff of of Applied Dynamics International (des@amara.uucp) and I bumped into some interesting mail and uucp problems on the ADI suns. It turns out we had the same problem at Schlumberger, but had lucked past it. Both of us talk to a local system at the University of Michigan, umix. The most reliable way to get to umix is thru MERIT, U of Ms network. To do this requires a horrendous chat script. This monstrosity (broken into several lines below) lets Sun uucp work thru MERIT without losing characters, significant bits, etc, etc. umix Any ph1 1200 7636520 "" \r ost? %echo=off\r\r ost? umix\r\r umix \r login: BREAK ! %remote\sbinary=on\r\r "" BREAK ! %binary=on\r\r login: none_of ssword: yer_bizniz Problem: If this system is not *last* in the L.sys file, systems below it are not found by mail. *BUT* they show up sporadically with uuname, and directly invoking uucico works fine. Only mail fails. We called it in to Sun, and they eventually came back and said that mail couldn't deal with more than 24 fields in the L.sys. Once it saw that many, it stopped processing the L.sys. Solutions: If you only speak to one host that requires that huge a chat script, put it last. To avoid blowing out mail, put this line before it in the L.sys: umix NONE Now all your utilities will work fine. Uucico will also continue to work fine, correctly ignoring the NONE line and processing the following long one. Although we've not needed it, we suspect that you can have multiple >24 field entries by putting them all at the end following a bunch of NONE entries. Steve Simmons Schlumberger CAD/CAM scs@lokkur.uucp ------------------------------ Date: Wed, 27 Apr 88 09:28:42 PDT From: weiser.pa@xerox.com Subject: slip for suns running 3.n--including Sun-4's? "[slip] runs fine on suns running version 3.n of the system as well with the latest tcp software from berkeley & van jacobson." Does this include Sun-4's? I have gotten slip, but NOT Van Jacobsons improvements, to run on Sun-4's. -mark [[ No mention was made in the shar file about Sun 4 machines, either one way or the other. This leads me to believe that it has not yet been tried on a Sun 4. --wnl ]] ------------------------------ Date: 25 Apr 88 22:57:08 GMT From: cracraft@venera.isi.edu (Stuart Cracraft) Subject: printing tex dvi files on a sun laserwriter: psdf? Sun's lpr(1) manual page says that 'lpr -d' will print a tex dvi file on a sun laserwriter. Further inspection seems to show that this would invoke the 'psdf' filter residing in /usr/local/lib/lw/psdf. However, the file in question is a shell script which comments itself out, e.g. reports that psdf is unavailable. Question for the newsgroup: is 'psdf' available? Is there something else that is needed to convert tex dvi files to be able to print on a sun laserwriter? Stuart ------------------------------ Date: Wed, 27 Apr 88 11:03:59 BST From: Operator <mcvax!nw.stl.stc.co.uk!root@uunet.uu.net> Subject: Changing software carrier flags? Does anyone know of a way of changing the software carrier flags in the SUNOS 3.2 kernel without recompiling? I'm sure that in the early days of our SUNs I was given a variable to change using 'adb' but I've lost the scrap of paper. I have tried zssoftCAR which I can change in /dev/kmem but not in /vmunix, all I get is "text address not found". Regards, Howard Pelling (admin@nw.stl.stc.co.uk +44 782 662212 x235) ------------------------------ End of SUN-Spots Digest ***********************