This message is from the T13 list server.
Pat, You have to keep this conversation straight. You asked me what 8 bit asynchronous SCSI requires independent of Windows or other implementation issues - and I've told you (in several messages). All DATA OUT commands send data out as a TRANSFER LENGTH or a PARAMETER LIST LENGTH, and these are exact values (this is all defined in the SCSI standard). On top of that, there is no mechanism for the device to somehow figure out it should terminate the date transfer early (on a successfult command). All of this has been in place for over a decade. Basically it makes no difference what Windows allows you to do - you wanted the SCSI requirements, and that's what you got. Put another way, if an OS allows you to do something to violate an independent IO standard, that still does not change the fact that it IS a violation of that standard if you use the OS capability. There is no provision anywhere that I know of to allow you to do this H < D or H > D you talk about at the device level. If you are seeing things in higher levels of the driver stack, then I assume that somewhere in the driver stack (or in the bridge) the problem is being taken care of. Put another way, have you ever seen a SCSI logic analyzer trace where H <> D on a successful command? Anything short of that does not tell us anything, since the SCSI standard is a host/device standard that only is applicable at that boundary (or a similar one like 1394). Specially the host can NEVER overrun the device on data (i.e. H > D is impossible) since the device paces all transfers (i.e. the host cannot send down a byte without a prior REQ). And H < D is impossible since that generate a hang condition (the device issues a REQ and waits for the next byte indefinitely). I cannot say it any plainer than that. You seem to want to discuss something like whether this is a good or proper thing to do. That's not really the point - it is just how SCSI is defined. Indeed, given the above how could you expect H > D or H < D to ever work - I literally cannot imagine a SCSI scenario for DATA OUT where that could make sense. Jim -----Original Message----- From: Pat LaVarre [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 02, 2002 11:50 AM To: [EMAIL PROTECTED] Subject: RE: RE: [t13] actual Scsi byte count decided how? This message is from the T13 list server. > "Mcgrath, Jim" <[EMAIL PROTECTED]> 01/02/02 11:53AM Thanks again for being so willing to talk. > D = H ... for SCSI DATA OUTcommands. > It has to be this way ... a host that tried to change this > after the command is issued would violate the standard > and/or hang the system. If this is the way it "has to be" ... what makes it so? I'm still working towards posting my existing Win9XME/2KXP demoes that show Windows has nothing in place to make this so for data in or out. I have a long memory of plug 'n play bus traces that show often this isn't so for data in. I'm out looking for Linux & MacClassic/OSX demoes for data in or out. It's probably a good thing that data out isn't much used in plug 'n play. Much of what little data out we do see is ModeSelect data, which when coherently constructed by analogy to ModeSense data often is the length the device expects. > D = H (using your terminology) ... Thank you for adopting this algebraic shorthand. I'm more confident in algebra than in English - in particular, I find it much easier to describe the whole problem concisely. This particular shorthand is not original with me - people in Usb Mass circles use it: there D != H easily triggers a bus trace. H is the count of bytes the host expects to move. D is the count of bytes the device actually agrees to move. To avoid the confusion of working with negative numbers in comparisons, Hi = abs(H) when the host expects to move data in else zero, Ho = abs(H) when the host expects to move data out else zero ... Di = abs(D) when the device actually tries to move data in else zero, Do = abs(D) when the device actually tries to move data else zero. > D = H (using your terminology) for SCSI DATA OUT commands. > It has to be this way due to the nature of the SCSI parallel interface > (for which the command set was originally devised). > That is, a host that tried to change this after the command > is issued would violate the standard and/or hang the system. Ahh. Now we run up against the real world. Yea D = H 99% of the time and that's what works well everywhere. Agreed classic Scsi hosts crash/ hang/ or cope quietly when Hi < Di or Ho < Do, especially if H is nonzero. The ones that cope quietly necessarily manufacture/ toss way data like we agree Ide Dma requires for odd length transfers, else they reset under the covers. I've never seen a classic Scsi Pio host choke over Di < Hi or Do < Ho ... have you? I have seen Dma hosts hang til timeout for anything except D = H. Ide Dma generally is disturbing as a Scsi transport because it requires a host to necessarily manufacture/ toss way the residual data that the device did not willingly clock across the bus. No matter that a UDma transfer included the residual data in its Crc. This is disturbing no matter whether the max count of such data is 1 byte or more. But can we agree on how to extend the standard to report the count of bytes of residual data ... unless we first agree the max count of residual bytes that may appear in a bus trace? Pat LaVarre Subscribe/Unsubscribe instructions can be found at www.t13.org. Subscribe/Unsubscribe instructions can be found at www.t13.org.
