Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!fernwood!portal!cup.portal.com!ts
From: ts@cup.portal.com (Tim W Smith)
Newsgroups: comp.periphs.scsi
Subject: Re: Mixing sync and async SCSI devices
Message-ID: <39645@cup.portal.com>
Date: 28 Feb 91 11:27:24 GMT
References: <1991Feb22.071227.26612@msen.com>
  <1991Feb22.201602.10592@dsd.es.com> <15888@celit.fps.com>
Organization: The Portal System (TM)
Lines: 39

< freak-out instead of just reject the message (so the vendors claim).  This
< message is *needed* for those times when the tape device is power cycled or
< otherwise externally reset without the knowledge of the host adapter.  Since
< the device goes back to async while the adapter thinks synch is all setup to
< go, and from there it gets ugly.

Actually, it would probably not get ugly for some devices.  Since the target
is async rather than sync, it is going to assert REQ and hold it while
looking for ACK.  Meanwhile, the initiator is going to see the REQ, deal
with the data bus, and then assert ACK.

The target is going to see this and drop REQ and then wait for the
target to drop ACK.

If the initiator were running async, it would wait to see REQ deassert.
However, since the initiator thinks sync mode is being used, it will wait
a while and then drop ACK.  If the target is fast enough to see the ACK
and drop REQ faster than the synchronous transfer period that the
initiator is using, things should work.

It would be interesting to try this with various combinations of targets
and host adaptors, and see which targets are fast enough to survive this
sort of thing.

Note also that even if the target will not negotiate for synchronous
data transfer (and most targets that I've seen don't), there still is
no problem in most cases.  After the target is reset, there should be
a UNIT ATTENTION condition created for each initiator.  This will let
the initiator figure out that the device has been reset and thus needs
to be renegotiated with.

The only place offhand that I can see where this will cause problems
is if the first command issued after the reset is an INQUIRY.  This
should only happen at system initialization time, when the bus is
being scanned.  As long as the host software refrains from negotiating
synchronous transfer until after the targets have all been identified,
everything should be OK.

						Tim Smith