Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!spool.mu.edu!sdd.hp.com!ucsd!celit!hutch
From: hutch@fps.com (Jim Hutchison)
Newsgroups: comp.periphs.scsi
Subject: Re: Mixing sync and async SCSI devices
Keywords: SCSI async sync
Message-ID: <15888@celit.fps.com>
Date: 23 Feb 91 07:32:45 GMT
References: <1991Feb22.071227.26612@msen.com> <1991Feb22.201602.10592@dsd.es.com>
Sender: daemon@fps.com
Reply-To: hutch@fps.com (Jim Hutchison)
Organization: FPS Computing
Lines: 26

In <1991Feb22.201602.10592@dsd.es.com> courtney@tonto.es.com
(Courtney Goeltzenleuchter) writes:
:In <1991Feb22.071227.26612@msen.com>, osm@msen.com (Owen Scott Medd) writes:

:> If I mix sync and async SCSI devices on the same bus, do I force *all*
:> devices on the bus to be dealt with as async devices?

:No, you don't force all the devices to be async.  It is the job of the
:initiator (typically the host CPU) to negotiate with each target device
:whether or not the initiator will use syncronous transfers with that target.

The target is also permitted to attempt to negotiate for synchronous transfers.
As to whether the host adapter will reject such a message is up to the adapter.
It is not required to support synchronous transfers and can just reject the
message if it is so inclined.  The Fujitsu M1016A (and B) do this message, as
does the StorageTek 4280.  Both allow it to be turned off, as some adapters
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.

--
-
Jim Hutchison		{dcdwest,ucbvax}!ucsd!fps!hutch
Disclaimer:  I am not an official spokesman for FPS computing