Sun-Spots-Request@RICE.EDU (William LeFebvre) (04/20/88)
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@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: Mon, 11 Apr 88 22:38:07 PDT From: Doug Moran <moran@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@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@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@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@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@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@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@xerox.com, mayer@rocksanne.UUCP ------------------------------ Date: Tue, 12 Apr 88 10:07:35 est From: mp@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@att.arpa ------------------------------ End of SUN-Spots Digest ***********************