Sun-Spots Digest, v6n74
William LeFebvre
Sun-Spots-Request at RICE.EDU
Mon May 9 04:54:41 AEST 1988
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 at rice.edu
Send subscription add/delete requests to: sun-spots-request at 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 at 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 at 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 at jane.jpl.nasa.gov (Steve Groom)
Subject: Re: A Question about Shared memory (2)
Reference: v6n63
William Moran <moran-william at 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 at 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 at 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 at 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 at 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 at 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 at K.GP.CS.CMU.EDU
Subject: Re: Conference room sized color displays
>From: bob at 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 at 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 at 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 at csvax.caltech.edu ARPA
david at 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 at rutgers.edu (Steve Simmons)
Subject: Problem and Workaround To Too Many Fields In L.sys File
David Steinhoff of of Applied Dynamics International (des at 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 at lokkur.uucp
------------------------------
Date: Wed, 27 Apr 88 09:28:42 PDT
From: weiser.pa at 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 at 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 at 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 at nw.stl.stc.co.uk +44 782 662212 x235)
------------------------------
End of SUN-Spots Digest
***********************
More information about the Comp.sys.sun
mailing list