osm@msen.com (Owen Scott Medd) (02/22/91)
This is a probably a stupid question, but I'll just plead temporary insanity. 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? Forgive my ignorance... Owen -- USMail: MSEN, 628 Brooks, Ann Arbor, MI 48103 Phone: +1 313 761-6624 FAX: +1 313 930-6636 UUCP: ...!crane!heifetz!osm Internet: osm@msen.com
mjacob@wonky.Eng.Sun.COM (Matt Jacob) (02/23/91)
It depends on the implementation of SCSI as to whether the host adapter driver supports mix-n-match. There is nothing in SCSI that precludes this. -matt
courtney@tonto.es.com (Courtney Goeltzenleuchter) (02/23/91)
In article <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. -- Courtney Goeltzenleuchter, Evans & Sutherland Computer Corporation Design Systems Division, P.O. Box 8070, Salt Lake City, Utah 84108 (801) 582-5847 UUCP: { decwrl | utah-cs | sun!sunpeaks!sunslc } !esunix!cgoeltze INET: courtney@dsd.es.com
grl@brb.dmt.csiro.au (Greg Lehmann) (02/23/91)
courtney@tonto.es.com (Courtney Goeltzenleuchter) writes: >In article <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. Agreed. SUN Microsystems won't support you if you have both sync and async devices on the same scsi chain. I suspect they want to sell more disk drives rather than there being any technical reason. Also from what I can gather all their tape drives are async. Doesn't make a lot of sense does it? -- Greg Lehmann, CSIRO Division of Manufacturing Technology, Telephone: +61 7 365 3877 c/- Dept. of Mining & Metallurgical Eng., Facsimile: +61 7 365 3711 The University of Queensland, QLD 4072. Internet: grl@brb.dmt.csiro.au
hutch@fps.com (Jim Hutchison) (02/23/91)
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
mjacob@wonky.Eng.Sun.COM (Matt Jacob) (02/24/91)
The Sun esp host adapter (as of 4.1.1) allows for the target negotiating synchronous first. It also clears 'sync known' state after each check condition in order to not fall into a hole for a REQUEST SENSE that might follow (in case somebody power cycled a target and destroyed the negotiated sync state).
ts@cup.portal.com (Tim W Smith) (02/28/91)
< 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