Hi everyone,
Last week, I inquired about a SCSI command timeoout problem with my
SS10 :
>
> Hi everyone,
>
> Ever since I installed the SUN1.05 drive on my SS10, I have been
> getting the following messages on booting :
>
> esp0: Current command timeout for Target 1 Lun 0
> esp0: State=DATA_DONE (0xa), Last State=DATA (0x9)
> esp0: Cmd dump for Target 1 Lun 0:
> esp0: cdb=[ 0x8 0x3 0x1f 0x50 0x4 0x0 0x0 0x0 0x0 0x0 ]
> esp0: Target 1.0 reducing sync. transfer rate
> sd1: SCSI transport failed: reason 'reset': retrying command
> sd0: SCSI transport failed: reason 'reset': retrying command
>
>
> I believe it is due to the Exabyte 8500 we have, is there a PROM
> upgrade on the Exabyte drive so that it'll support the fast SCSI
> or something ? By the way, the SCSI bus has :
>
> SS10 -> SUN0424 -> SUN1.05 -> CDROM -> EXB-8500 -> QIC150 -|
> (id0) (id1) (id6) (id5) (id4)
>
> If I unplug the EXB8500, I don't have the problem, and the EXB8500
> takes a long time to response to the probe device SCSI command
> on booting, is there a dip switch to set so that it'll response to
> the SCSI command without waiting for the reset to finish ?
>
> Thanks in advance ...
>
Thanks to all those responsed, most of you mentioned due to the high speed
nature of fast SCSI, the cable length is extremely important, and that
it probably is not my exabyte drive. I thought that I was using short
enough cable,
SS10 -> SUN0424 -> SUN1.05 -> CDROM -> EXB-8500 -> QIC150 -|
(id0) (id1) (id6) (id5) (id4)
(internal disks) 3ft 3ft 2ft
max. cable length is 6m = 19.68ft
Well, by taking into the internal cables on the external box, I think
I was on the edge very close to the cable length. I managed to find
another 2ft high-density SCSI -> DB50 cable, and replaced that cable
connecting from CDROM -> EXB-8500, and the SCSI timeout error went
away, suprisingly :-|. Then I also thought that the QIC-150 probably is
a extremely slow device, sync SCSI <= 3MB/s, I have then also
disconnected it.
Thanks to :
From: phil@cgrg.ohio-state.edu (Phil Ritzenthaler) :
>
> Just had this same problem . . . even if I reduced the length of the
> SCSI chain, the dual disk pack on the end always gave me problems . . .
> until I moved them closer to the SS10.
>
> It seems that some devices are more sensitive to the length of the SCSI
> chain than others are. Did you try moving and reconfiguring where your
> devices are located on the chain?
>
From: canuck@masc38.rice.edu (Mike Pearlman)
>
> Check the following
> CABLING
> TERMINATOR
> The SS10 supports SCSI-2 and is very sensitive to cabling and cable lengths.
> Keep them short a high quality. Are you using an ACTIVE terminator. The old
> terminators sold by many vendors were passive and worked fine at SCSI-1 speeds
> but the SS10 requires and active terminator.
>
From: plord@pioneer.uspto.gov (Paul Lord)
>
> Have you checked your SCSI cable lengths?
> paul
> --
From: jor@ts.se (Joakim Rastberg)
>
> The SS10 SCSI-controller can't sustain 10MB/s on the bus and therefore
> drops down in speed (first to 5MB/s sync, later to async (1-2MB/s))
>
> Whoa! You have too many devices on the bus! Single-ended SCSI at 10MB/s
> usually don't work with more than 3-4 devices. I had the same problem
> with our SS10's. Did some trial and error (the hard way) and finally
> came to the conclusion that for the onboard SCSI in a SS10 you can
> have at most 2 external boxes. (ie 3 disks + 1 [tape/exa/CD])
>
> Perhaps with high-quitaly cables and/or boxes and/or terminations
> you could have 6 devices on the bus but a don't think so...
>
> Your solution is: buy an extra SCSI-controller. It's cheap and it
> will include a 2:nd ethernet (TP) (can't hurt at all:-). If you
> really want to have 6 units on the SCSI you must go for differental
> SCSI (and still need to buy a new controller... and new disks:-(
>
> If you unplug the CD and/or QIC you can have the exabyte still on.
>
> The exabyte is slow because it aligns the tape every time the scsi resets
> (i think). it responds quicker if the door is open or no tape is loaded.
>
From: shankar@ulysses.att.com
>
> Some times this is caused by exceeding the SCSI cable length specs.
>
> Reduce your cable length (use shorter cables) and try.
>
From: mike@cd.com (Mike Heins)
>
> Sounds a lot like a bad cable. We ship thousands of cables, and every
> once in a while a customer gets a bad one. I have personally seen
> symptoms much like this.
>
> You might also double-check your termination.
>
From: Bryan Helvey <bryan_helvey@wiltel.com>
>
> How long (meters) is your scsi chain? And have you tried putting the
> Exabyte first in that chain?
>
From: aimt!breeze!paul@uunet.UU.NET (Paul V. Farr)
From: Tony.Tran@EBay.Sun.COM (Tony Tran)
>
> Tim,
>
> It's not because of the PROM problem on the Exabytes.
>
> Looks like you might have exceeded the 6 meter limitation
> on the SCSI bus if you attempted to daisy chain all of these
> devices in 1 SCSI bus. Note that each external cable is about
> 1m long (not counting about 3" internal cable for each device)
> (see page 19, Introducing the SPARCstation 10, under SCSI
> Bus Length)
>
> If that's the case, I would put a couple of them on a separate
> SCSI controller, and that should take care of your problem
>
> Tony Tran
>
From: Mike Raffety <miker@il.us.swissbank.com>
>
> I've noticed my SS-10/41 is VERY touchy about the SCSI length,
> especially compared to my old SS-2. I used to have external disk box
> (pair of 1 GB Fuji 2266s), QIC-150, and CD-ROM; now, it only works
> reliably with the disk drives, barely with the tape or CD added (i.e.,
> doesn't boot, but if I add it to the SCSI chain afterwards, it works)
> and not at all with all three external devices.
>
> I presume it's because of the fast SCSI features; the internal disk
> would be running fast, of course.
>
> I'll be interested in any summary you produce ...
>
From: "Michael R. Zika" <zika@fatman.tamu.edu>
>
> Has the kernel been reconfigured to transfer data at asynchronous
> speed? Sun admits a problem when mixing fast and slow SCSI transfer
> on the same SBus. Since the Sun424 and 1.05 drives on your bus
> are fast drives, and the 8mm is slow, this may be contributing to
> the problem.
>
> I will forward Sun's distribution concerning SCSI config's using
> Single-Ended fast SCSI devices.
>
> Hope this helps...
>
**** and Michael is kind enough to send me a copy of document named
**** "SCSI Configurations using Single-Ended Fast SCSI Devices"
> From ddoherty@chipcom.com Wed Jul 14 11:15:15 1993
From: kevin@uniq.com.au (Kevin Sheehan {Consulting Poster Child})
>
> I think the problem is 5 devices on the bus. Cable length and
> impedance matching are important with a lot of devices. I would
> check that 1) you have the shortest possible cables you can find/get/steal,
> and 2) that switching the cables around doesn't make a difference.
>
> SCSI controllers count as bus length in the calculation, I guess
> the 8500 is just "longer" than the others.
>
> l & h,
> kev
>
From: glenn@uniq.com.au (Glenn Satchell - Uniq Professional Services)
>
> How long are your scsi cables. This is a classic symptom of a scsi bus
> that is too long. You can only have 6 metres max, including the
> internal lengths of the devices. Did you have this problem before you
> added the 1.05G disk? If not I'll bet that removing any single scsi
> device will fix the problem.
>
> Solutions? Well, make sure that you're using the shortest cables you
> can get (typically 0.5 metre), and that you have an active terminator
> on the end. If it's a Sun terminator use one of the ones with the grenn
> light in the end, this shows the termination voltage is present.
>
From: Bernd Raichle <Raichle@informatik.uni-stuttgart.de>
>
> I have similar problems when adding a second internal 1GB drive to my
> SS10. The problem was the cable length of the complete SCSI bus
> (first internal drive, external drive+CD ROM+tape and now the second
> internal drive), which leads to read/write problems on the first(!)
> internal drive.
>
> To fix the problems try to
> -- use _active_ terminators
> -- use short SCSI cables (don't believe the specs about the
> possible maximum SCSI-2 bus length)
> -- use _good_ SCSI cables, otherwise reflections on the SCSI
> bus are possible
> -- or ... get a second SCSI interface
>
Tim Chan
================================== Address ==================================
Tim Chan, Staff Software Engineer, SynOptics Communications Inc.
(408)-764-1706 fax: (408)-988-8548 MS:SC01-04, 4401 Great America Parkway,
email : tim@synoptics.com P.O. Box 58185, Santa Clara, CA 95052-8185
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:08:01 CDT