I had responses from:
Simon Coppins <coppins@arch.adelaide.edu.au>
danielle@systems.caltech.edu (Danielle Sanine)
mjacob@auspex.com (Matthew Jacob)
ekurgpol@develop-law.usc.edu (Elmar Kurgpold)
ebumfr@ebu.ericsson.se (Mike Rembis 6259)
poffen@sj.ate.slb.com (Russ Poffenberger)
rick%pgt1@Princeton.EDU (Rick Mott)
(Peter J. Welcher -- math FACULTY <pjw@math46.sma.usna.navy.MIL>)
Eckhard.Rueggeberg@ts.go.dlr.de
Thank you. The question was:
>> I would like to get the collective wisdom of our group here to get
>> opinions on the robustness of the Sparc 1+ SCSI bus. We have had
>> two 1+'s that seem to have difficulty supporting more than 2 or 3
>> SCSI devices. The errors are generally logged in the messages file
>> and are things like:
>>
>> SCSI bus DATA IN phase parity error
>> SCSI bus STATUS phase parity error
>> SCSI bus MESSAGE IN phase parity error
>> disk not responding to selection
>> disk okay
>> data transfer overrun
>> SCSI transport failed: reason 'incomplete': retrying command
>> SCSI bus MESSAGE OUT phase parity error
>>
>> All this has led me to believe that the SCSI bus on the Sparc 1+ is slightly
>> inadequate. Would any other managers care confirm this?
============ HERE ARE THE RESPONSES =================
Simon Coppins <coppins@arch.adelaide.edu.au> wrote:
> We had the same problem on our 1+ some time ago when we added a second
> disk (in it's own box) and an Exabyte to the existing Shoebox. The
> SCSI transport errors made the system unworkable.
>
> We used the Sun supplied cable going from the SS1+ to the shoebox as
> those mini-D SCSI connectors we impossible to source at the time. In
> addition we were using some one metre cables to finish the chain. Only
> the last device was terminated, as per spec.
>
> Apparently the SS1+ (and possibly others) can only support a SCSI
> chain up to seven metres long including any "virtual length" caused by
> connectors. The Sun Shoebox has an internal cable + connectors valued
> at 1.4 metres!! If you take that as an average, three devices makes
> the chain way over.
>
> Our solution was to use Insulation Displacement Connectors (IDC) with
> ribbon cable and make SCSI cables exactly the right length (about
> 300mm in our case). The problems went away and all is well but I have
> always wanted to fit a CDROM on that system and have never been
> sufficently motivated enough to tempt disaster.
I always try to use the *shortest* cables possible! The problem cases
are all under 2 meters total, but I agree, shorter is better.
====================================================================
danielle@systems.caltech.edu (Danielle Sanine) wrote:
> Please summarize. I have an SS1+ with only a single, internal scsi
> disk (Hitachi 312C-25) and I have been getting alot of scsi errors.
> Most mention data transfer overrun then say they are reverting to
> async. mode or reducing sync. transer rate. I have replaced the
> disk, but the messages persist. What kind of internal disks do you
> have? Could they be the problem?
No. We have the infamous "sticky" Quantum 105's in ours. Have you
checked the external termination on the SCSI port coming out the back?
====================================================================
mjacob@auspex.com (Matthew Jacob) wrote:
> Yes, the SCSI bus for Sparc 1+ machines *is* slightly inadequate.
> SS2 is a bit better. SS10 is even a bit better than that.
Our SS2 SCSIs seem pretty robust. Don't have a SS10 yet :-(.
====================================================================
ekurgpol@develop-law.usc.edu (Elmar Kurgpold) wrote:
> I use a SPARC 1 (no plus) with an external 1.3 GB hard disk,
> 5.0 GB tape drive, and cdrom. I have had no such problems,
> even when using all three at once. Sounds like something is
> physically wrong with your system to me.
Our three Sparc 1's seem pretty robust also. But they don't have
particularly fast disks.
====================================================================
ebumfr@ebu.ericsson.se (Mike Rembis 6259) wrote:
> Yes we confirmed a couple of years ago that the SS1 and 1+ busses were
> *very* inadequate. We found that 9 feet was the max for all external cables.
I keep the length (including internal ribbon) to less than that in most
cases.
====================================================================
poffen@sj.ate.slb.com (Russ Poffenberger) wrote:
> I have had similar problems with SLC's, but have not seen a problem with
> SS-1's or IPX's.
Our IPX's are doing alright.
====================================================================
rick%pgt1@Princeton.EDU (Rick Mott) wrote:
> I don't know what you're doing, but I wouldn't be in a hurry to blame the
> bus or the Sun drivers. We've spent a LOT of time working with Sun on
> the issue of SCSI since the SunOS 3.5 days, and have loaded six or seven
> devices on the bus with no sweat. As far as we're concerned, it's solid
> as a rock.
We don't appear to have many problems when using the slower SCSI peripherals
but a fast Fuji 1.2 GB drive really drove the bus crazy... I suspect it
is speed related.
====================================================================
Peter J. Welcher -- math FACULTY <pjw@math46.sma.usna.navy.MIL>) wrote:
>I've seen similar symptoms in the log files.
> Also, I've had 3 SCSI units (internal drive, external drive, external
> 1/4" tape) unterminated on a 1+ work fine, then added 3rd party Toshiba
...
This is interesting. I have had our service rep (Polaris) tell us to run
our SCSI bus unterminated! I haven't had the courage to try it yet (no
have time for a lengthy restore!)
> CD player unterminated and damaged the CPU board (twice: my hardware
> repair technician (DEC) wanted to witness it for himself). It seems
> to have burned out at least the SCSI port, and the video was screwed
> up until the Sun had been power-cycled.
Ouch! I thought I had problems! ;-)
====================================================================
Eckhard.Rueggeberg@ts.go.dlr.de wrote:
> the SCSI in a 1+ must be a bit different than on any other
> Sun, because we get our (MicrTek ZS 600) scanner only to work
> at a 1+, nor at a 1, neither at 2, IPC or IPX. I dont know why.
---------------------------------------------------------------------------
Ted Asocks tra@lick.ucsc.edu
Systems Administrator VOICE: (408)459-4020
UCO/Lick Observatory FAX: (408)426-3115
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:07:20 CDT