From: neese@adaptx1.UUCP (Roy Neese)
Subject: Re: 1542B Synchronous/Asynchronous
Organization: Adaptec Inc., Texas
Date: Mon, 17 Aug 1992 19:47:46 GMT

In article <2152@ncr-mpd.FtCollins.NCR.COM> gkendall@ncr-mpd.FtCollins.NCR.COM (Guy Kendall) writes:
> In article <1992Aug06.144142.6358@adaptx1.UUCP> neese@adaptx1.UUCP (Roy Neese) writes:
> >One thing you should be aware of and the reason for the jumper to begin
> >with is this; some devices want to negotiate for the sync protocol and
> >in that case, you must remove the 1542B jumper.  You can't have both the
> >target and initiator negotiate for sync protocol.  Or you must disable
> >sync negotiation on the target device in order for the 1542B to
> >negotiate for sync.
> 
> Roy, I wanted to see if you could clarify this a little bit. I don't
> understand why you would need to disable initiating the synch negotiation
> if the other device is one that will initiate the synch negotiation. If the
> initiator wants to initiate negotiation, it will just assert ATN (most likely
> during selection phase so it can send the 5 byte synch negotiation message
> after the identify message) causing the target to assert MSG_OUT phase.
> Then the target would assert MSG_IN phase and send 5 bytes back and they
> would both be set to do synchronous. Now if the target initiated the
> negotiation it would assert MSG_IN first, and the initiator should 
> respond.

Thanks for pointing this out, Guy.  It is a very device specific
question and scenario.  In the real world, I have run into devices that
would negotiate for sync and when either target or initiator
re-negotiated for sync, someone gets confused.  I have seen where the
1542 would negotiate for a period/offset and the target would come back
and re-negotiate and, due to a different table being used, the
negotiated speed would drop.  This is okay so far, but for some reason
some devices don't like sync negotiation taking place more than once.
If a different period/offset is negotiated for after the first one, the
device tries to continue to use the original and of course the bus would
enentually hang.  I have witnessed this with several different manufacturer's.
 
> It seems that both devices should be able to recognize that the other
> device did the negotiation and should not initiate another negotiation.
> Now I believe that you might be saying that some devices you have
> encountered have problems with this, which would indicate problems with
> the drivers if I am not mistaken.

I'm with you.  The 1542B will not re-negotiate sync if another device
has already done the negotiation.  But I have seen devices that would
not only negotiate for sync, but would do so on every command,
suggesting they don't keep a table.  The 1542B will negotiate once and
that is it, unless the bus or adapter is reset.  If another device does
the negotiating, the 1542B will keep track of the table.
 
> For that matter, I believe that the spec allows more than one negotiation
> per device. It would seem unneccessary, but I believe it is allowed for
> devices to re-negotiate their synchronous parameters.

Quite right.
---

			Roy Neese
			Adaptec Senior UNIX/SCSI Software Engineer
			UUCP:	convex!egsner!adaptex!neese
			Inet:	neese%adaptex@cirr.com
Newsgroups: comp.periphs.scsi