This message is from the T13 list server.
Pat, In SCSI NON-DATA commands are not a problem. DATA IN commands allow the device to send however many bytes they want up to some pre defined (on a command by command basis) by the host. Since 1993 I don't know of any SCSI data being passed that requires odd bytes (once again, maybe some variable block size tapes as an exception). And for DATA OUT the host always precisely tells the device the transfer length (number of bytes) it intends to transfer. So I don't understand your premise (although I am understanding better some of your messages). All of the expected byte transfer lengths are established at the COMMAND level in SCSI. And for DATA IN commands, since the device terminates the command, the lower levels just assume that the device terminated it by sending back the "correct" number of bytes (as long as it is shorter than that allocation length). It is up to higher level software to take it from there. At last all of that is the standard SCSI model. Can you point to an exception? Jim -----Original Message----- From: Pat LaVarre [mailto:[EMAIL PROTECTED]] Sent: Monday, December 10, 2001 12:41 PM To: [EMAIL PROTECTED] Subject: RE: [t13] a fix for imprecise UDma residue? This message is from the T13 list server. > Harlan Andrews <[EMAIL PROTECTED]> 12/10/01 10:34AM > ... > Both the host and the target know the TOTAL number of bytes required. > ... > Sorry, I don't see the problem. You almost do see the issue: you state it precisely. You only have one step further to go: all you have to add is your explanation of HOW the host and the target come to agree over how many bytes they jointly agreed to move. They observe the bus? No. Except for AtapiPio transfers, all the host & device can observe mutually is that N * 2 bytes clocked across the bus. They both see N * 2 bytes clock across, no matter that the receiver of clocks may have begun signalling to stop as far back as X * 2 - 1 bytes ago. They came to exist only after their designers read the standard? No. Some commands were not well-standardised before the host and device shipped, especially in contexts like changing power modes, removable media, varying block sizes, and so on. Of the commands that were well-standardised, Scsi often flatly requires the device to stop short of the byte count given in a command. And all this gets worse any time the out-of-band communication of block size goes awry, or anybody ships any other kind of bug that scrambles byte counts. How do the host and the target come to agree over how many bytes they jointly agreed to move? They don't agree. Not unless the device reports precisely where it cut the expected data transfer short. Ansi Ata/pi Pio gives the device a way to do this. Ansi Ata/pi Dma, as yet, provides no option for the device to do this. My current Atapi prototypes report the residue in x1F5:1F4 at x03 Status INTRQ time. Pat LaVarre Subscribe/Unsubscribe instructions can be found at www.t13.org. Subscribe/Unsubscribe instructions can be found at www.t13.org.
