Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!purdue!decwrl!shelby!neon!kaufman From: kaufman@Neon.Stanford.EDU (Marc T. Kaufman) Newsgroups: comp.sys.mac.hardware Subject: Re: Sharing the SCSI bus? Message-ID: <1989Dec7.090026.16543@Neon.Stanford.EDU> Date: 7 Dec 89 09:00:26 GMT References: <1989Nov29.030959.27969@Neon.Stanford.EDU> <8252@pogo.WV.TEK.COM> <1989Dec5.165138.5192@Neon.Stanford.EDU> <4945@celit.fps.com> Sender: USENET News System Reply-To: kaufman@Neon.Stanford.EDU (Marc T. Kaufman) Distribution: na Organization: Computer Science Department, Stanford University Lines: 146 In article <4945@celit.fps.com> rory@fps.com (Thomas (Rory) Bolt) writes: >In article <1989Dec5.165138.5192@Neon.Stanford.EDU> kaufman@Neon.Stanford.EDU (Marc T. Kaufman) writes: ->The ATN line is usable (note that I didn't say "used"). The MacOS provides ->a SelectWithATN command, but only allows 1 byte to be sent before ATN is ->negated - thus precluding IDENTIFY. > Why would this preclude the IDENTIFY message? The standard IDENTIFY > message is only one byte. The EXTENDED IDENTIFY message may be several > bytes, however, this is a moot point anyway as I will explain below. You are correct. I forgot what I was trying to do, which was to send a TWO byte sequence, IDENTIFY-ABORT, to shut down a particular LUN. The Mac drops the ATN line after the first byte, making this impossible. -->how does the initiator send messages? Also the book "Inside Macintosh Vol IV" -->states on page 286 that Mac implements both arbitration and disconnect / -->reselection; I find it disturbing to find out that this is not so. ->I had never noticed that. You're right, it does. They lied. > No, Inside Macintosh is correct. You do not understand SCSI protocol. I don't think you are in a position to judge that. I have written several SCSI drivers and SCSI target controllers. > The Macintosh DOES support arbitration. (via SCSIget) Have you taken the time to disassemble the code, or have you just read the manual. YOUR Mac may support arbitration via SCSIget. MINE (a IIx running system 6.0.4) just sets a low memory byte to preclude other (Multifinder) processes from simultaneously trying to use the SCSI interface. --> PS. If there is an actual document with this information, I'd love to --> know its name, and how to get it. ->I suggest "Mac Nosy" by Jasik Designs. > I suggest the ANSI SCSI specification X3T9. The problem is that Apple > provided a low level interface to the SCSI protocol chip. This means > that people who wish to write SCSI device drivers MUST understand the > SCSI protocol. "Mac Nosy" will tell you what the Macintosh SCSI manager > does, NOT HOW TO USE IT. Well, it is certainly possible to access the chip directly and do whatever you want, including support of Arbitration and extended Messages. In fact, A/UX does both of those and Apple has announced full support of Disconnect and Reselect (which imply ATN and Arbitration) for System 7.0. The fact remains, however, that DTS strongly discourages users from accessing the chip directly -- and if you want to limit yourself to the SCSIxxx routines provided by Apple in system 6 and earlier, you do not get bus arbitration. With respect to Mac Nosy -- you would be suprised at how many things are implemented differently than the documentation states. Don't take MY word for it -- go look. Then tell me about arbitration and soft selection failures. > The attention line of the SCSI bus is used to signify that the >initiator is capable of handling messages. Specifically, if the initiator >asserts attention during the selection sequence to REQUEST that the target >go to a message out phase. If the target is capable of supporting messages >other than COMMAND COMPLETE, it will respond to this request by proceeding >to the message out phase after selection. True. But if you want to sent TWO messages (see above, IDENTIFY+ABORT), the initiator has to hold the ATN line following the first message byte out. > As I have stated in my previous posting, the TARGET controls the >bus phase sequence AND determines how many bytes of data should be sent after >selection has occured. This means that the target will determine when to >disconnect/reconnect (once the initiator has indicated it supports this), >how many bytes of message data it wants, etc. THIS IS WHY THE ATTENTION LINE >EXISTS, SO THAT THE INITIATOR (WHO IS NO LONGER BUS MASTER) CAN SIGNAL THE >TARGET (WHICH IS BUS MASTER) THAT IT WANTS A MESSAGE OUT PHASE. The attention >line is used only to request a message phase, it DOES NOT have to be asserted >for every byte of the message and does not guarantee that a message phase will >occur. All of that is true. HOWEVER, see above for multiple messages. > The Macintosh SCSI manager does supply all the pieces necessary to >support disconnect/reconnect. I have personally implemented it for several >companies. AS I SAID IN MY PREVIOUS POSTING, PLEASE STOP SPREADING >MIS-INFORMATION. I highly advise you to read the ANSI specification for SCSI >and make sure you UNDERSTAND it before you post further on this subject. I am not sure why the flame. The pieces are there, the details are not. In order to support disconnect/reselect correctly, you have to patch several SCSI routines to do proper arbitration and ATN handling (I know, MOST of the time you don't really need to arbitrate, after all the collision window is SO small, and you don't need two bytes of message if you just reset the entire device, or if you reset the bus -- but if thats the kind of code you supply to customers, please tell me who they are so I don't try to use any of their peripherals on my machine). If you want to have more than one device reselecting, or to different tasks, you need to implement command pointer tables and task identification in the command blocks -- Apple doesn't do this and I am guessing that your code will support disconnect/reselect on at most one device connected to at most one program (i.e. - not a file system hooked into HFS). > Apple has provided all of the tools neccessary to support a fully >ANSI compliant, single initiator, arbitrating system capable of supporting >disconnect/reconnect. Individual driver writers choose how much they are >willing to support. and how much they are willing to preclude others from doing the same thing. There is no dispatch method for reselection in the Apple supplied code. Indeed, some of the routines clear the ID register, so the 5380 will not automatically respond on a reselect. Presumably you would poll the chip periodically (at least twice every selection timeout period). What do you do if it's not YOUR device asking for reselect? What do you do if another disk driver, using Apple's SCSI routines (unless you have patched them) attempt a select without bus arbitration just as your device attempts to reselect? NAH, it could never happen. Please note that any system that correctly supports arbitration and disconnect/ reselect has implemented all necessary multi-initiator protocol sequences. The Mac may not be able to be a target device, but other initiators could certainly use the bus -- or a smart target could implement COPY. >KNOWN PROBLEMS/LIMITATIONS: > 1) Apple's ROM boot code is not very robust, boot will fail if another >initiator is using the bus. It's also not very friendly. It resets the entire bus rather than the single device it was trying to access. Ever see an Exabyte tape reset 6 times on startup? > 2) The system will only be as robust as the least compliant driver >allows. > 3) Using Apple's traps incurs moderate overhead for implementations >which handle the SCSI protocol as a finite state automata. This overhead may >be insignificant compared with the access time of the device. >Rory Bolt (rory@fps.com) ***** And now for a REAL hardware question: does anyone know enough about the insides of the SCSI helper PALs for the SE and the II(x) family to be able to categorically state whether the DMA ACK, cpu DTACK, and Bus Error timeout logic preclude or allow data loss on read. [i.e.: If you get a bus error, can you be SURE that a byte was not accepted from the SCSI chip?] My suspicion is that data can be lost (in a small but non-zero timing window), but then I may just have a program bug. Marc Kaufman (kaufman@Neon.stanford.edu)