This message is from the T13 list server.
On Fri, 7 Dec 2001 09:48:11 -0700 (MST), Jim Castleberry wrote: >If the host knows the count before the transfer can't it simply compare the >expected to actual after the transfer and detect errors easily? For correctly implemented devices and hosts... For an ATA device we know the following is true for PIO data transfer commands that end with no error: The number of bytes transferred is number_of_sectors * 512. For an ATAPI device we know the following is true for PIO data transfer commands that end with no error: The number of bytes transferred is the sum of the Byte Count values presented by the device each time the device is ready to transfer a DRQ data block. For an ATA device we know the following is true for DMA data transfers commands that end with no error: The number of bytes transferred is number_of_sectors * 512. For an ATAPI device we know the following is true for DMA data transfer commands (when using today's stupid DMA controllers): If the PACKET/SCSI command transferred fixed length data blocks and there was no error we can assume the number of bytes transferred is number_of_blocks * block_size. In this case both the host side and the device side must understand what "block_size" is. Please note that a CD-ROM has many many different "block_size" values. This is one reason why something like an X-to-ATAPI bridge must parse each SCSI command block and understand what is going on. Then there is the problem of SCSI commands and SCSI devices that have truely variable sized data blocks. In this case there is no good way for the host to know how much data was transferred. The simple solution for these commands and devices is don't use DMA on an x86/PCI host adapter when this condition is present. I will point out again that this was not a problem with the old ISA bus DMA engines... Those maintained an accurate "residual byte count" so a host could determine how many bytes were transferred. So it seems to me that the only problem here is the last one (ATAPI DMA) and it is a problem for both today's x86/PCI hosts and for X-to-ATAPI bridges but generally only when the SCSI command might transfer a variable number of blocks. However, except for a device with truely variable block sizes (and I know of only one but it also has a fixed block mode) the solutions are: 1) use PIO, or 2) fully understand the SCSI CDB and act accordingly. >BTW, how did/does 1394's Tailgate handle this? That spec might be worth a >read to see if there's a better way than changing drive specs and abandoning >the installed base. 1394/OHCI devices have NO data integrity. A host can not determine anyting about the data transfer it thinks should have happened. There is no way to know accurately if any data was transferred, if some data was transferred, if some data was lost in transit, ... you get the idea. 1394 should NEVER be used to transport critical data. I don't want to go into this any more in this thread (or even here on T13) but every 1394 based mass storage device I have seen so far has serious data corruption problems... An normal ATA or SCSI drive with these kinds of problems would not last 10 seconds in a normal product eval test. *** Hale Landis *** [EMAIL PROTECTED] *** *** Niwot, CO USA *** www.ata-atapi.com *** Subscribe/Unsubscribe instructions can be found at www.t13.org.
