Subject: Re: CSPPC SCSI hangs
To: Georges Heinesch <ghmlist@attglobal.net>
From: Ignatios Souvatzis <is@jocelyn.rhein.de>
List: port-amiga
Date: 05/14/2000 21:43:20
On Sun, May 14, 2000 at 10:18:39AM +0200, Ignatios Souvatzis wrote:
> On Sun, May 14, 2000 at 04:18:17AM +0200, Georges Heinesch wrote:
> > > 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:
> 
> > The only thing the Viking doesn't like so much is sync transfer. Hence,
> > it's diabled in my AmigaOS CSPPC bootmenu.
> 
> 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).

Maybe I should have been more elaborate... 

as sync transfers don't work reliably with either AmigaOS or NetBSD..., I
suspect the drivers are not faulty.

(sync transfers can be MUCH faster, especially with UW boards like the CSPPC,
than async transfers, making correct high frequency behaviour of the cable 
(which includes termination) and correct timing behaviour of the disk firmware
and the drivers VERY important.)

Now, I guess this doesn't help you much, especially as you're convinced that
your cables and termination are correct... 

Let me explain how to force the siop2 driver to avoid sync transfers even if
the disk claims it can do them. (I had to look up driver source to make sure
this works with this driver, which is why I didn't mention it earlier).

the boot block (and loadbsd) take an option "-I somenumber", where number
is a 32 bit number used to pass sync inhibit flags to some scsi bus drivers.

sbic (A3000 internal) and siop and siop2 are aware of this.
sbic (which is scsibus0, so it comes first) uses up 8 bits of this (from the
right).
siop2 will be scsibus1, and it consumes 16 bits, each denoting one target id
(wide scsi has 16 of them) which won't be asked for sync transfers.

so booting with 

netbsd (other parameters) -I 0xffff00 will inhibit sync transfers on 
all siop2 targets. Please try this.

This is more or less explained in "man 8 boot". I understand it is difficult
to read without a running system.

Regards,
	Ignatios