Sun-Spots Digest, v6n58
William LeFebvre
Sun-Spots-Request at RICE.EDU
Wed Apr 20 08:22:10 AEST 1988
SUN-SPOTS DIGEST Tuesday, 19 April 1988 Volume 6 : Issue 58
Today's Topics:
Re: Two Displays on a 3/60FC
Re: Bug in SUNlink X.25 (CUDF)
Re: NEC Silentwriter LC-890 "RS-232"
More disk noise
Information about thinwire Ethernet (long but informative)
SCSI as a general purpose bus?
meaning of disk error messages?
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: Mon, 11 Apr 88 22:38:07 PDT
From: Doug Moran <moran at ai.sri.com>
Subject: Re: Two Displays on a 3/60FC
Reference: v6n51, v6n39
In v6n51, there were two replies stating that it was easy to add a
monochrome monitor to a Sun-3/60FC. My information from Sun is that this
was possible on Sun-3/60FC's (and 3/60C's) shipped in 1987 and maybe the
first part of 1988. However, since then Sun has supposedly stopped
populating the monochrome video memory section on 3/60 boards going into
non-monochrome systems (3/60S's, 3/60C's and 3/60FC's). Consequently,
simply adding a monochrome monitor will not work for more recently
delivered 3/60s.
Aside: I have talked to various representatives of Sun on multiple
occasions about the desirability of having "two-headed monsters" in a
range of applications. Each time, I have been told that Sun is not
interested in supporting such configurations as options and been told the
usual caveat -- that while it may be be possible at that time to make such
additions, Sun will not make any commitment that future systems will
support that capability, even systems ordered at that moment. However,
the decision to stop populating the monochrome video memory is the first
instance I know of where such has actually happened.
Doug Moran
AI Center, SRI International
------------------------------
Date: Tue, 12 Apr 88 17:56 BST
From: Piete Brooks <pb%computer-lab.cambridge.ac.uk at nss.cs.ucl.ac.uk>
Subject: Re: Bug in SUNlink X.25 (CUDF)
Reference: v6n43
The symptoms I saw was that there was that the listener has a mis-aligned
structure, i.e. the length was correct but the data started at [1] instead
of [0].
Someone called SUN & was told that SUN knew about it but that it isn't a bug.
As the spurious byte is always a 0x00 and I never listen for a CUDF
starting with 0x00, I have added code to blow a raspberry if a 0x00 is
found & shuffle everything down.
[ This is only one of 9 serious bugs I found in the X25 code when writing PD
versions of x29d and ybts.inetd (a UK specific listener), two of which
caused the system to panic (and could be invoked as non-root).
]
------------------------------
Date: 12 Apr 88 12:04 -0700
From: David Harris <david at pharm.ubc.ca>
Subject: Re: NEC Silentwriter LC-890 "RS-232"
In continuation from my previous posting:
>We recently purchased a Sun 3/60 and a NEC Silentwriter LED array printer.
>Its "RS-232" port drives 0-5V only. ...
I recently received information from another LC890 user. He says that
when they followed up this problem, the specifications for the printer
were -5 to +5V on the RS-232 lines (although this was denied by a NEC
help-line person). Upon investigation of the motherboard in their printer
they found that a voltage converter supplying -5V to the driver circuit
was flaky, hence the output was 0.8 to 4.5V (not even TTL, ho-hum). They
replaced a shorted transistor and managed to get -2.5-4.5V, which worked
with their Sun, although still falling short of RS232 specs (a zero is
defined as below -3V).
Maybe NEC could pull up their socks ... and pull down the "RS232" lines to
where they belong.
David P. Harris, PhD MD
Faculty of Pharmaceutical Sciences
University of British Columbia
Vancouver, BC, CANADA V6T 1W5
(604) 228-6216
------------------------------
Date: Mon, 11 Apr 88 23:05:32 EST
From: "Tim G. Smith" (Mechanical) <tsmith at cad.usna.mil>
Subject: More disk noise
Another chapter in the continuing saga of the noisy disks...
After reading several folks messages about curing shoebox disks of their
horrible noises I decided it was time to fix mine.
I wasn't comfortable with the idea of just removing the anti-static brush-
with my luck the disk would blow the next day! I also had reservations
about putting any sort of tape inside the shoebox as it gets pretty hot in
there and I didn't want the tape to dry out, break up into litte pieces,
and generally muck up the works. I also was hoping to avoid having to do
this again every time the tape falls off. (Feel free to call me paranoid-
but I'd rather be paranoid with a working disk then adventurous and be out
a few thousand $ .)
What my boss, our tech and I came up with was the idea to take the disk
apart, remove the static brush, smear a bit of RTV in between the the V
(see picture) in the assembly and put the whole mess back together.
Here is a horrible ascii diagram of the brush assembly. [NOTE the angle
between the top and bottom pieces is MUCH smaller (like 15 degrees)]
-------------|- <- screw and nut that hold brush to circuit board go here.
\ <---
\ <--- put dab of RTV in here so that it touches both top and
\ <--- bottom pieces of brush.
\ <---
\
|-----|
| <------- Disk manufacturers thoroughly inadequate vibration mount
--------- and graphite cup.
|
| <-- spindle
|
You only need a small amount of RTV - smear it in there carefully and then
reassemble the whole works (putting everything back together before the
RTV sets makes sure that you have everything fit properly and also clamps
the brush in exactly the right position while it dries).
Standard Disclaimer and warning:
If you feel uncomfortable with this idea then feel free to ignore it. If
you are still under warranty you might not want to do this. If you try
this and muck things up don't flame me- it worked for me (so far). Go
ahead and try it if you like but it is at your own risk. Blah,blah,blah,
etc... (you get the idea, right?).
Good luck,
Tim Smith
E-Mail :<tsmith at usna.mil>
US mail:Tim Smith
CADIG mailstop: 11G
US Naval Academy
Annapolis, MD 21402
Tel # :(301)267-4413
------------------------------
Date: Mon, 11 Apr 88 13:09:18 EDT
From: smb at research.att.com
Subject: Information about thinwire Ethernet (long but informative)
First the easy ones... They both run at 10 Mbits/sec, using the same
encoding; in fact, I've heard that you can (with the proper adapter)
connect lengths of the two together, and everything should work. (I
haven't tried it yet.) Now for the differences... (Btw, most of this
data is taken from DEC's ``Networks and Communications Buyer's Guide'';
it's an excellent guide to configuring an Ethernet, and if you're on
friendly terms with a DEC salescritter you should ask for one.)
Thinwire Conventional
Segment length 185 meters 500 m
Number of devices 30 100
Interdevice spacing 0.5 meters 2.5 m
Transceiver attachment BNC plug N-type screw or vampire tap
The real differences don't fit into a table that neatly, though. With
conventional cable, you can run the cable in a concealed area, and add
transceivers and ``drop cables'' -- the 15-pin jobs -- to run to the hosts
as needed. If you use vampire taps, you don't disrupt the network while
you're adding them [[ at least in theory --wnl ]]; using N-type
connectors requires that you cut the cable (which disrupts the entire
net), add connectors to both ends (I won't use that pseudo-word
``connectorize''...), and screw in the transceiver.
Thinwire cable can be used the same way; however, there are no vampire
taps available that I've ever seen. Instead, you add connectors to the
cable, insert a T-adaptor, and plug the transceiver into the T. For
either cable technology, the drop cables can be up to 50 meters.
The big advantage of Thinwire technology is that many workstations have
integeral Thinwire transceivers; thus, the T-connector plugs directly into
the machine, without needing an external transceiver or drop cable. This
can save you $300 a station or more. But -- and it's a big ``but'' -- you
cannot attach a drop cable to the T; you must plug it directly into a
transceiver or workstation/transceiver. Thus, if your cable is in the
ceiling, you have to run a loop down to the workstation, rather than a
single cable or a neat wall-jack.
Here are some sample costs, taken from Cabletron's June 1987 price list.
I suspect that the relative costs are about the same today:
Thinwire Conventional Both
transceiver cable, 10m (may not need) $55.65
", Teflon $68.90
Transceiver (may not need) $275
PVC coax, per foot 0.15 0.90
Teflon coax 0.60 2.20
Which you use depends on the precise environment. We use both, in
different situations. For our machine room, we use thick coax with
vampire taps. First, it's an old network, and thinwire wasn't available
at the time. Second, we can't risk taking down the whole net to add a new
machine or device; adding connectors to cable takes too long. Besides,
when connectors loosen the entire net goes down; when a vampire tap
loosens, it only knocks off one machine. And none of these machines have
the integral transceivers.
For our offices, we use a DEC wiring plan called DECconnect. (I suspect
that DECconnect is a trademark but I can't find where it says so in the
DEC literature I have at hand.) Our constraints were as follows: (1) we
were prewiring about 120 offices under construction. During construction,
we could put in whatever wiring we wanted; afterwards, it would be
expensive to open up the walls. (2) The ceiling area is an environmental
air space. Thus, the fire code requires Teflon cables, and prohibits
active electrical gear such as multi-port transceivers or the like. (3)
We expected to have 60 +/- 20 workstations within 3 years. (After less
than 1 year we already have 45 or so.) (4) Some offices -- but we didn't
know which -- would have more than one Ethernet device. (5) We wanted the
ability to split the Ethernet into several separate segments, connected by
bridges or IP gateways, to isolate file server traffic.
We considered two principal alternatives. The first consisted of 3 to 5
thickwire coax segments covering the entire building; initially, they
would be butted together, but we reserved the option of splitting them at
these predefined points, and inserting bridges. A transceiver drop cable
would be installed in each office, but would just dangle in the ceiling
area until needed. To activate an office, we'd install a transceiver (it
is possible to obtain transceivers that are U.L.-listed for air plenums)
and connect the cable.
The second alternative, DECconnect, consists of a single Thinwire coax to
a faceplate in each office. These cables all terminate on a patch panel,
and are connected, as needed, to ports on an 8-port, Thinwire repeater
(DEC calls theirs the DEMPR, and charged about $3200 for it; other vendors
have equivalents). Connecting up a new workstation involves attaching a
length of Thinwire coax to the faceplate, connecting it to a T-connector
(and the T to a terminator), then connecting the whole assembly either to
a transceiver or the workstation itself. Finally, a patch connector is
installed between the DEMPR port and the patch panel. Elapsed time, ~5
minutes max; training need, little.
What sold us on this system was the flexibility. We can add new offices
very quickly, whereas installing a vampire tap took (a) significantly
longer; and (b) only a few people here had the experience to to it well.
And if we need to install bridges, we can group workstations to a segment
by file server, rather than geographically. I no longer recall the
difference in cost per port; the DEMPRs are expensive, but you make up for
that if you can avoid transceivers (as with most new Suns), and with the
lower cable cost. I think we broke even at ~60 workstations; below that,
the DECconnect was cheaper because we didn't need all the unused Teflon
drop cables (which are expensive). We did not assume we could avoid
transceivers; since we can, we've saved even more money.
--Steve Bellovin
ulysses!smb
smb at ulysses.att.com
------------------------------
Date: 12 Apr 88 06:20:34 PDT (Tuesday)
From: "James_L_Mayer.WBST128"@xerox.com
Subject: SCSI as a general purpose bus?
We are interested in the possibility of using the the SCSI interface on
Sun workstations as a general purpose peripheral bus. Does anyone know of
a driver that would allow some or all of the following?
(1) Continue to use Sun SCSI peripherals (disk, tape).
(2) Allow "add on" drivers to be easily added to the system.
(3) Supports a "generic" driver that allows user applications (privileged of
course) to issue "raw" SCSI commands.
On a related note, do you know of:
(4) A way to interface the new SCSI Apple Laserwriter to a SUN.
(5) A SCSI -> Centronics parallel port box.
-- Jim Mayer
Xerox Corporation, Webster Research Center
mayer.wbst12 at xerox.com, mayer at rocksanne.UUCP
------------------------------
Date: Tue, 12 Apr 88 10:07:35 est
From: mp at allegra.att.com
Subject: meaning of disk error messages?
Some of the Suns in our offices with the 2333 disks get disk errors every
few weeks.
- how do we know when a disk or controller is sick enough to need service?
I figure that messages like "read failed" or "write failed" indicate a
problem, but what about retries and restores? One recent example was when
running vi, reading in a file, and writing it out as 2 separate smaller
files, produced files with large regions of \252 characters. vi never
produced any error messages, and the console said:
xy0a: read retry (disk sequencer error) -- blk #8065, abs blk #8065
xy0a: read retry (disk sequencer error) -- blk #8196, abs blk #8196
xy0a: read retry (disk sequencer error) -- blk #16933, abs blk #16933
xy0a: read restore (disk sequencer error) -- blk #16934, abs blk #16934
xy0a: read retry (disk sequencer error) -- blk #20775, abs blk #20775
xy0a: read retry (disk sequencer error) -- blk #20833, abs blk #20833
xy0a is the root filesystem, where /tmp is. The owner of that system
thinks the problems are disk-related, since the error messages always
mention xy0a; he switched to using xy1a as his root several weeks ago
and has had no problems since. This is a 3/260 running 3.2 with a
single 451 controller.
- even if there are no console error messages, problems still seem to
occur. One system, a 4/260 running 3.2, developed a corrupted version
of othertools in the swap area. lockscreen would not draw certain
things correctly and wouldn't demand a password to unlock the screen,
but copying /usr/bin/lockscreen to a fresh file and executing that
worked fine. How can one check for these problems? A virtual memory
tester like sysdiag/vmem would do part of the job. Does anyone have a
program that will look for corrupted text in the swap area?
Mark Plotnick
allegra!mp
mp at att.arpa
------------------------------
End of SUN-Spots Digest
***********************
More information about the Comp.sys.sun
mailing list