Sun-Spots-Request@RICE.EDU (William LeFebvre) (02/19/88)
SUN-SPOTS DIGEST Thursday, 18 February 1988 Volume 6 : Issue 17
Today's Topics:
Administrivia
Re: Sun monitor behaving strangely (2)
Re: 3.2 vs. 3.4 `time' command
Sun IPC device driver bug
Fig
fig2ps
SLIP & 3/60's?
Controlling PCs from a Sun Window (?)
rcp and rlogin hang in 3.4EXPORT, fix?
LPS-40 Laser accessible over DECnet from a SUN?
teaching assembly-programming with Suns?
Re: Maximum Disk Space
Installing 68881 chips
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 stored on "titan.rice.edu". For volume X, issue Y,
"get sun-spots/vXnY". They are also accessible through the archive
server: mail the word "help" to "archive-server@rice.edu".
----------------------------------------------------------------------
Date: Thu, 18 Feb 88 14:02:33 CST
From: William LeFebvre <phil@Rice.edu>
Subject: Administrivia
If it seems that a message you sent to Sun-Spots has taken a long time to
appear in a digest, you are not alone. Current turn-around time for
messages is about 10 days. I am doing my best to get a digest out every
day (while still keeping the size in the vicinity of 20K) in an attempt to
clear out the backlog. I apologize for the delay, but I still haven't
recovered from the Christmas break. If you have a message that must
appear within the next day or two, please place the word "URGENT" in the
subject field and I will do my best to handle it quickly. I assume that
the readership would rather have a temporary 7 to 10 day backlog than be
deluged with many and/or large digests within a short period of time.
Comments about this situation should be mailed to Sun-Spots-Request@Rice.edu.
William LeFebvre
------------------------------
Date: Sun, 7 Feb 88 13:49:26 EST
From: bwong@sun.com (Brian Wong - TSE Washington DC)
Subject: Re: Sun monitor behaving strangely (1)
Frequently, this happens when the power supply reaching the display is
unstable. You don't say what kind of sun3 you have, but most often I see
this when there are a number of systems plugged into the same wall circuit
-- generally four systems with at least two disks. By wall circuit, I
mean (for example) one circuit inside the wall, not one wall outlet. The
noted behaviour is generally to have the screens swim or waver when
somebody's disk gets beat up -- a compile of a 2000 line program is a good
example. The remedy is simple but often logistically difficult: move one
or more systems to another circuit. Check your power drains against the
rated capacity of the circuits in your office. You config guide should
tell you enough to calculate the ballpack (ballpark) power consumption.
------------------------------
Date: Mon, 8 Feb 88 09:09:32 EST
From: Chuck Musciano <chuck@trantor.harris-atd.com>
Subject: Re: Sun monitor behaving strangely (2)
> Does anyone have any experience with a Sun 3 monitor behaving strangely,
> waving and acting as though the tube may be on its last legs?
My machine (a 3/50 with 70 Meg disk, but I doubt that matters) had a
monitor which began to get little flashes of noise across it. This began
to occur more and more frequently, and then it finally died. We are under
a maintenace contract to Sun, and they Fed-Exed a new tube the next day.
The most interesting part of the whole thing was finding out how the
monitor is attached to the 50's base. The new monitor has a slight bend
in the upper right corner, though.
Chuck Musciano
Advanced Technology Department
Harris Corporation
(305) 727-6131
ARPA: chuck@trantor.harris-atd.com
------------------------------
Date: Sun, 7 Feb 88 12:14:39 CST
From: Hans Boehm <boehm@flora.rice.edu>
Subject: Re: 3.2 vs. 3.4 `time' command
Memory usage reported by all versions of the csh `time' command that I
have run into so far was in units of pages. (I know this is inconsistent
with both the letter `k' following the numbers and the documentation.)
Apparently 3.4 fixed this bug (finally). Thus the factor 8 difference
between 3.2 and 3.4. (I believe there was a factor of 16 difference
between VAXen and Suns for a while, for the same reason.)
Hans-J. Boehm
boehm@rice.edu
------------------------------
Date: Sat, 6 Feb 88 15:55:29 PST
From: edelsohn%astroplasma.Berkeley.EDU@lilac.berkeley.edu (David Edelsohn)
Subject: Sun IPC device driver bug
There is a problem with the IPC device driver that Sun recently figured
out (with the help of a system administrator and part time kernel hacker).
It is now on their list of known bugs and will be fixed, but until then
all SA's for machines with IPC boards should know the following:
No matter how many actual IPC boards are installed, all four drivers
(pc0-pc3) MUST be configured in the kernel. The driver was incorrectly
written so that all four data structures are accessed no matter how many
exist. If the unused drivers are commented out of the configuration file,
the number of data structures created is correct, but the driver accesses
the memory range that would be occupied by FOUR structures and turns
whatever gets mapped there instead into mush. The obvious work around is
configure all four drivers.
Our machine (a lightly loaded 3/260 serving two lightly loaded 3/50's)
amazingly lasted for days at a time. I had not heard anything about this
problem until I contacted Sun so I assume that most others have not heard
either.
David Edelsohn INTERNET: edelsohn@astroplsma.Berkeley.EDU
------------------------------
Date: Mon, 8 Feb 88 09:06:19 PST
From: Neil Hunt <hunt@spar-20.spar.slb.com>
Subject: Fig
Fig is definitely an interesting program. I agree with Charles Roberson
that some additional features such as multiple fonts and rotating text
would be nice; however my enquiry concerns a postscript filter and a latex
filter. Does anyone have programs which convert from the native fig format
to either of these other formats?
If not, then I shall be putting key to editor soon and writing something
myself. All being well, I will be able to distribute it.
Neil/.
[[ See the (next) article in this digest entitled "fig2ps". There is
also a program called "fig2tex" which, I believe, is still being beta
tested. --wnl ]]
------------------------------
Date: Sat, 6 Feb 88 23:55:39 PST
From: coraki!pratt@sun.com (Vaughan Pratt)
Subject: fig2ps
Since fig seems to be in use I should 'fess up to fig2ps. It produces
both standalone and tex-\special .ps files. It features an alternate text
font (default Greek) accessed by putting % in front of the affected letter
(as in diam = 2%pr) in the .fig file. Thickness of dashed and solid lines
in the .ps output is independently controllable, and also dash size (0 =
solid) (whence figures with mixed thick and thin lines are possible if you
forgo dashes). Scale and text point size are both controllable.
I will not distribute or support fig2ps myself, but I will be happy to
provide the source to one or two people willing to take on at least one of
those functions, ideally at the same sites that distribute fig.
-v
------------------------------
Date: Sat, 6 Feb 88 11:53:29 EST
From: "Tim G. Smith" (Mechanical) <tsmith@usna.mil>
Subject: SLIP & 3/60's?
Is anyone out there running SLIP on their low end suns?
I would like to connect 2 3/60's via SLIP. Both systems would also be
connected to local ethernets and would be expected to gateway between the
two networks.
I am interested in hering about what software and hardware is being used.
I would like to dive the SLIP connection as fast as possible- I have a
direct 4 pair wire connecting the systems so I could theoretically get a
T1 type leased line type modem (1.5Mbps). I seem to remember
hearing(reading) that the serial ports on the suns are only rated at 9.6k
incoming and 19.2k outgoing, is there any truth to this?
I would greatly appreciate any hints,pointers, or horror stories.
Thanks,
Tim Smith
E-Mail :<tsmith@usna.mil>
US mail:Tim Smith
CADIG mailstop: 11G
US Naval Academy
Annapolis, MD 21402
Tel # :(301)267-4413
------------------------------
Date: Sun, 7 Feb 88 20:53:38 PST
From: brian@white.stanford.edu
Subject: Controlling PCs from a Sun Window (?)
In our laboratory we do most of our work on SUNs, but we control real-time
experimental equipment (e.g. A/Ds, special graphics boards, measurement of
subjects responses) on PCs. These PCs share network resources via PC-NFS.
We would like to be able to edit-compile-debug PC programs that control
special purpose equipment on the PC-bus from within a Sun window. For
example, we would like to be able to open a window on a SUN and control
the PC for the purpose of program compilation, linking and execution.
This would provide us with a superior work environment for programming,
but still permit us to control the special purpose devices on the PC bus.
Does anyone know of a product or method we can use?
Thank you for your help.
Brian Wandell
brian@psych.stanford.edu
(415)-725-2459
Brian Wandell
Jordan Hall
Building 420
Stanford University
Stanford, CA 94305
------------------------------
Date: 4 Feb 88 10:15:13 GMT
From: Dolf Starreveld <mcvax!uva!dolf@uunet.uu.net>
Subject: rcp and rlogin hang in 3.4EXPORT, fix?
Since we have installed SUNOS 3.4 (EXPORT) on our SUNs we expierience the
following problem:
When starting an rcp to or from a remote hosts which is not a SUN (in our
case either a VAX 11/750 BSD4.3 or a Gould PN9000 UTX 2.0 == Bsd4.3) rcp
copies a few blocks (the exact block count varies) and then hangs. If you
let it hang it never terminates, not even with a network timeout or
something. Something similar happens with rlogins to one of these hosts.
The session is normally started and you usually get 5 minutes before
things go wrong. Suddenly, at some seemingly random moment, the
connection will hang. Nothing is able to "unhang" this situation. The
only thing we noticed is that it seems to happen more frequently just
after the remote hosts has sent a burst of output, than in situations were
there is a steady but relatively slow stream of output.
First we thought it might have something to do with tha VAX and the Gould,
but now this doesn't seem so likely anymore. What we finally did was leave
all 3.4 software installed, but run a 3.2 kernel. This solves our hanging
problems, but is off course an unwanted situation.
Does anybody out there expierence these problems? Does anybody have a fix?
Dolf Starreveld Phone: +31 20 525 7482/+31 20 592 5022, TELEX: 10262 HEF NL
EMAIL: dolf@uva.uucp (...!mcvax!uva!dolf), or dolfs@hasara5.bitnet
SNAIL: Dept. of Math. and Computing Science, University of Amsterdam,
Kruislaan 409, NL-1098 SJ Amsterdam, The Netherlands
------------------------------
Date: 5 Feb 88 08:50:44 GMT
From: trw@hrc63.co.uk (Trevor Wright Marconi Baddow)
Subject: LPS-40 Laser accessible over DECnet from a SUN?
The LPS-40 Laserprinter seems to only be accessible from DECnet networks.
If one had a Sun running their DECnet end-node software, could you get at
the LPS-40 that way, in particular from other nodes in an NFS setup,
including PC's with PC-NFS.
Trevor Wright
GEC Research
PS - what I'm really after is a faster A4/A3 laser to take the load off
some LaserWriters and be accessible from TCP/IP and DECnet networks - any
other suggestions appreciated.
[[ Imagen's laser printers speak TCP/IP and XNS, but not DECNet (at least,
as far as I know). --wnl ]]
------------------------------
Date: Fri, 5 Feb 88 12:07:50 +0100
From: gran!lind!ingvar@nta-odin.arpa (Ingvar Eidhammer)
Subject: teaching assembly-programming with Suns?
We are considering using sun 3 in teaching assembly-programming. Does
anyone know of a good programming-enirenment for assembly-programming
under UNIX, with pedagogical tools for debugging. Can anyone recommend a
good book for introduction to assembly-programming under UNIX.
Ingvar Eidhammer
Associate professor
University of Bergen
Department of informatics
Allegt. 55 N-5007 Bergen
Norway
E-mail adress: ingvar%gran.uucp@odin.arpa
------------------------------
Date: Mon, 8 Feb 88 07:31:31 PST
From: mutchler@sun.com (Dan Mutchler)
Subject: Re: Maximum Disk Space
The difference between the 3/260 and 3/280 disk space is very simple. The
3/260 is intended to be configured with pedestal SMD drives. Each pedestal
requires one controller and will hold 560MB of disk space. There can be
two controllers per machine, thus the maximum limit of 1GB. The 3/280 is
rack mountable and can use the Super Eagles (575MB each) with the same
controller limit of four drives. This gives the limit of 2GB.
Dan
------------------------------
Date: 6 Feb 88 04:34:57 GMT
From: roy%phri@uunet.uu.net (Roy Smith)
Subject: Installing 68881 chips
Some time ago, I mentioned that I was going to install 68881 floating
point chips in our 3/50's which didn't have them and promised I would
report back when I had it working. This morning I installed the first of
the 9 chips we got, so here's my report. First you have to know where to
get the chips. We got them from Schweber. The order read:
----------------
Schweber Electronics
Jerico Turnpike, C.B. 1032
Westbury, New York, 11590
Attn: Leslie Woll
516-334-7474
Quantity Item Number Description Unit Price Amount
9 MC68881-RC16A Motorola 16 MHz 68881 (mask A93N or higher)
floating-point coprocessor chip. $145.45
Delivery from stock
Total $1309.05
----------------
If you don't have a Schweber dealer near you, try one of the following.
Prices vary, and are outdated quickly so I won't bother listing them. I'm
sure any authorized Motorolla dealer will be able to get these parts for
you. Try calling Motorolla in Austin, Texas at 512-928-6800 (possibly
obsolete phone number) and ask for some local distributors.
Lionex, 516-273-1660 (Christine Russell)
Hamilton Avnet, 516-231-9800 (Bill Cooke)
Pioneer/Harvey, 201-575-3510 (Bruce Manning)
The "RC16A" says several things. The important part is the "16" which
means it's rated to run with a 16 MHz clock. They also come in 12's and
20's, with faster parts costing more. You can run a chip at a clock speed
below what it's rated for, but you'll just be throwing away good money.
You may also be able to run a chip at a higher clock speed than it's rated
for, but only if you don't really care too much about it working reliably.
:-) I believe there is a jumper on the 3/50 CPU board which you can move
to get a 12 MHz clock and thus use 12 MHz parts, but I'm not sure of the
details of how to do that but don't suggest you bother; the price
difference between the 12 and 16 MHz parts is not enough to make it worth
while. The particular board I worked on this morning was (apparantly)
jumpered for 16 MHz, as I suspect most, of not all, are. The "RC" and "A"
mean that it is a commercial (i.e. not MIL-SPEC) chip in a ceramic pin
grid array package. I don't know if the 68881 comes in any other flavors.
I suspect that if you could find a MIL-SPEC version it will cost several
times what the commercial part does without providing any practical
advantage.
You want to specify mask A93N or higher. I'm not sure of the details, but
apparantly earlier versions of the chip had some obscure bug in them. I
believe A93N's are the only parts currently being made, so that should not
be a problem.
Now that you have the chips, you need to install them. This is reasonably
straightforward, but: WARNING -- DO NOT ATTEMPT THIS UNLESS YOU ARE
FAMILIAR WITH THE PROPER PROCEDURES FOR HANDLING STATIC-SENSITIVE
COMPONENTS, AND HAVE PROPER ANTI-STATIC EQUIPMENT. If you do not know
what you are doing, you run the very real risk of destroying the chips by
static discharge. In fact, you could zap the entire CPU board. With
reasonable care and a standard anti-static kit, however, a competnt
technician should be able to do the whole job safely in 15 minutes. Keep
in mind that neither myself nor my employer take any responsibility for
any damage you may do to your machine. If your machine is still under
warranty from Sun, you will almost certainly void that warranty by
installing your own chips. If you have your machine under a service
contract, Sun may very well refuse to repair it if you break it while
attempting this (and I would't blame them). Check with your Sun
representitive for more information.
If I havn't yet scared you out of doing this, halt your machine,
disconnect the power cord, and unscrew all the various cables attached to
the CPU board. Don your static discharge strap, remove the 4 allen-head
screws, and pull the CPU board from the chassis, resting it on a
static-free work area. Locate the socket for the 68881. If you orient
the board with the VME connector South and the "outside" edge North, the
68881 socket should be just to the East of (and somewhat smaller than) the
68020 CPU. If you have trouble recognizing which is the 68020, you have
no business attempting this procedure. Remove the 68881 from the
conductive shipping material and check that all the pins are straight.
Some of mine were slightly bent; I carefully straightened them out with a
fingernail. Orient the chip so that the writing on it reads the same way
as the writing on the 68020 (and all the other chips on the board). One
of the corners of the chip should be marked on the top; that's the
North-West corner. As far as I can tell, the pins are symetric and you
could plug the chip in with an improper orientation; undoubtedly this will
lead to disasterous results. Carefully seat the chip until the bottom of
package is flush with the top of the socket. If you are used to plugging
in 16-pin DIPS, you will notice that you need considerably greater force
than you are used to. Be careful to apply force evenly over the surface
of the chip while seating it. If you push too hard on one side and crack
the package all the bits will leak out and the points inside will stop
floating. :-)
Once you are sure the chip is down flush, reinstall the CPU board, attach
the power, video, and keyboard cables, and turn it on. Try some quick
confidence tests (I use the memory read/write scan). If you don't know
how to use the PROM diag monitor, do L1-A and type "h<CR>" at the ">"
prompt for help. You want option "x" (extended diagnostics). If the prom
diags check out, attach the ethernet and boot single user. Mount /usr and
run /usr/etc/mc68881version, which should report something like:
MC68881 available; mask set appears to be A93N.
Approximate MC68881 frequency 15.9 MHz.
The approximate frequency reported should be 16.0 +/- 1.0 MHz, depending
on factors ranging from inter-machine variability to the phase of the
moon. The operative word is "approximate".
If that works, come up multi user and log in as "sysdiag", selecting
automatic mode when you get the menu. Note the "devtop" window at the
lower left; it should note the presence of the 68881 chip, and report that
it passes diagnostics (be patient; it takes a few minutes for each test).
Let it run at least a few passes through all the diagnostics.
Sun doesn't document sysdiag very well. See "man sysdiag" for a start.
If you've ever run any kind of system diagnostics, you should be able to
feel your way around without much trouble. Of course, the bottom line is
your own application. If you have a 3/50 with a factory installed 68881
which runs -f68881 binaries OK, but those same binaries fail on your
self-installed 3/50's, I'll bet you did something wrong, regardless of
what the system diagnostics say. Also, I think there's a bug in some of
the PROM-resident memory diags which cause error reports on perfectly fine
machines. Go figure. One last note. I believe the actual 68881
diagnostic program is /usr/diag/sysdiag/mc68881. If you run "strings" on
it, you get (in part):
----------------
Could not find configuration for MC68881 in EEPROM.
System Configuration does not have a MC68881 configured for this system.
Please remove the MC68881 now.
System has an MC68881, but system configuration does not have it configured for this system.
Could not find configuration for MC68881 in EEPROM.
System Configuration requires an MC68881 to be installed.
Please install an MC68881 now.
System does not have an MC68881, but system configuration has it configured for this system.
----------------
I'm not sure what all this means, but it seems to imply that there is some
configuration information in the EEPROM relating to the 68881. I can't
find anything in the hardware installation manual about it, and it seems
to work without any EEPROM fiddling, so I wouldn't worry about it.
Presumably those strings are meant to be printed during some sort of
factory burn-in or configuration check procedure.
If anybody with better or more up-to-date information has anything they
wish to add, I'd appreciate it if you would forward your comments to this
list so we can all benefit from your experience. Now, if we could just
get Sun to stop charging such outrageous prices for this option (if I can
buy them for $145, quantity one pricing, think how little they must cost
Sun in quantitites of thousands) we wouldn't have to waste our time doing
this at all.
Roy Smith, {allegra,cmcl2,philabs}!phri!roy
System Administrator, Public Health Research Institute
455 First Avenue, New York, NY 10016
------------------------------
End of SUN-Spots Digest
***********************