Re: CSPPC SCSI hangs

[Ignatios Souvatzis <is%jocelyn.rhein.de@localhost>]

On Tue, May 16, 2000 at 09:13:04PM +0200, Georges Heinesch wrote:
> Quoting Ignatios Souvatzis (14-May-00 10:18:39):
> 
> >> > Generally, if it doesn't work, its a cable or termination problem
> >> 
> >> Hmmm ... I have my doubts here. Why should it work fine under
> >> extreme conditions (24/24 hours, 7/7 days a week, many peak RW
> >> accesses ...) for +1 year until now?
> 
> > But it doesn't! you told in your message before:
> 
> It doesn't when using the CSPPC SCSI with NetBSD, but with AmigaOS, it
> works fine. Is that what you meant ... ?

No... I meant "it doesn't with AmigaOS". You told:

> >> The only thing the Viking doesn't like so much is sync transfer.
> >> Hence, it's diabled in my AmigaOS CSPPC bootmenu.

which indicates that something is wrong with timing on the cable.
at non-sync the data rate is always < 5 MHz. When sync is enabled, the
data rate on the '770 can be as high as 20 MHz (when the disk agrees to
that.

> > This indicates that either:
> > a) scsi termination is wrong
> > b) cable is wrong
> > c) disk firmware has a bug
> > d) disk driver in operating system has a bug
> 
> > As you have problems with the AmigaOS driver as well with NetBSD, I
> > suspect it is not d).
> 
> I was fiddeling around with the SCSI UW termination for quite a long
> time and managed to get some very deep into it (I did not volonteer ;).
> I am pretty sure that the termination is fine. Here the system:
> 
> Viking UW ---/UW/--- CSPPC ---/adapter/--- streamer ---scanner
> 
> 1. The Viking is actively terminated (jumper).
> 2. The Scanner (HP 6200C) is actively terminated (automatic).
Automatic? ugh. Hope this works. Although I must confess that the only
auto-terminating device that I've seen does work, indeed. (I don't want
to know what happens when two devices are auto-terminating...)

> 3. ---: normal SCSI cable.
> 4. ---/UW/--- UW cable.
> 5. The adapter actively terminates the 8 data bits!

The 8 upper data bits, I guess? Then termination should be ok.

> What can be wrong here?

First guess: external cable length. SCSI length at Ultra speeds is limited.
I looked it up... for non-differential busses:

speed           devices         length          active termination
<=  5 Mhz       *               <= 6.0 m        allowed
<= 10 MHz       *               <= 3.0 m        suggested
<= 20 MHz       *               <= 1.5 m        required
<= 20 MHz       <= 4            <= 3 m          required

Additional restrictions:
- no "stubs" (bus to device) connections of more than
  10 cm (including onboard distance from connector to SCSI chip).
- devices must be 30 cm or more apart.

The host adapter counts as a device in the table above!
The full cable length counts, including the internal part of the cable!

As an experiment, you could terminate the scsi chain at the streamer, 
disconnecting the scanner. Well, measuring the cables 

Also, you can try forcing the disk to non-sync, with the -I option (see 
my other message or "man boot".) as a workaround. But if its a cable problem
you should rather hunt it down... you didn't buy an Ultra Wide disk just to
not use 75% of the transfer speed, right?

Also, if it's a driver bug, we should hunt it down, too, of course. I don't
know Michael Hitch's setup, so I don't know wether he has multiple devices
connected; I only have one disk on the UW bus, and connected an old disk
and (occasionally) an external MO or scanner to the motherboard SCSI.

Actually, the workgroup server at work is set up in the same way: we have
a relatively short wide scsi chain for the two new fast disks, and a different
narrow scsi bus for the tape streamer and the old "slow" disks (which handle
the ftp and www server and /usr/local/src).

Regards,
        -is