[rescue] rescue Digest, Vol 165, Issue 5

Mike Spooner mike.spooner.ux at gmail.com
Sun Aug 7 13:33:23 CDT 2016


On 7 August 2016 at 18:00, <rescue-request at sunhelp.org> wrote:

> ----------------------------------------------------------------------
> Date: Sun, 7 Aug 2016 00:34:11 -0400 (EDT)
> From: eddie_cottongim eddie_cottongim <eddie_cottongim at cox.net>
> To: rescue <rescue at sunhelp.org>
> Subject: [rescue] SS10 SCSI Controller
> Message-ID: <787566592.7040.1470544451811.open-xchange at eastrmapsu115>
> Content-Type: text/plain; charset="us-ascii"
>
> My SPARCstation 10's SCSI controller seems to have died. I've gone
> through a bunch of swaps of trying both internal and external cabling,
> multiple drives, etc. It suddenly went from working well (with internal
> SCSI2SD and external DVD) to hanging while trying to boot. ("The SCSI Bus
> is hung.") OBP b test scsib  fails (-1) most of the time. To my
> surprise, probe-scsi can still see the SCSI2SD, but hangs after printing
> that line, with the access light on SD2SCSI still on.
>
> Are there any repairable common failure modes here? I checked the
> termination PTC fuse as well as I could b  its hard to get clear access
> to the legs, but I think it is ok. If it is misbehaving under load, I
> wouldn't be able to tell with a simple continuity test.
>
> My main options would be replace the motherboard, or find an add-in SCSI
> controller?
>
> Thanks,
>
> Eddie
>

The most common failure mode is to have SCSI termination enabled on an
internal peripheral device - this is not needed on the SS10 for *internal*
drives, because the (2nd) internal funny plastic device-connector actually
has a SCSI terminator in it. Termination *is* needed on the last *external*
device in the chain.

Having the peripheral device terminated as well, will cause the SCSI bus to
be a bit marginal, often works but sometimes doesn't. If the SCSI2SD
adaptor has a jumper for "Termination", set the jumper to the disabled
position.

The second-most common failure mode is that the peripheral device itself
has (started to) fail. In your case, this could be the SCSI2SD adaptor, or
(more likely) the SD card itself, as a passive "inquiry" command is
succeeding, but nothing more. Try a "probe-scsi" with a different SD card,
and if that still doesn't look any better, try it with eg: a real
narrow-SCSI disk drive or another SCSI2SD adaptor.

It might be worth unplugging the motherboard end of the SCSI cable (that
rectangular plastic DIP plug), and reseating it. In *very* old SS10s that
have seen a lot of dust and humidity, I have seen the pins on that
particular plug get a bit corroded - reseating can often scrape the pins
enough to get a clean connection again.

Failure of the onboard Emulex ESP SCSI chip is extremely rare - I have only
ever seen such failures from physical damage (spilled beer, half-assed
soldering mods, dropped screwdriver, and so on). Try all the other measures
first.

Finally, add-in SBus SCSI cards are *almost* all for external peripherals
only - they do not have IDC 50-pin connectors for a "standard" internal
SCSI cable.
Thus you would either have to have the SCS2SD device in an external
enclosure, connected with an "external micro-50-to-micro-50" SCSI cable (I
don't know whether you have it this already), or butcher one of those same
external-SCSI cables to fit an IDC-50 connector to one end, and then route
it from the external plate of the SBus card back through the hole left by a
removed backplate into the inside of the chassis to reach the internal
drive-bays.

If all else fails and you do have to go with an SBus card, the Sun FSBE/S,
part numbers 501-2015 or 501-2981, is the best bet (supported by SunOS
4.1.3 and later, NetBSD 1.2 and later, and all SPARC Linuxen).

-- Mike Spooner
http://mbus.sunhelp.org


More information about the rescue mailing list