This message is from the T13 list server.
> ... the number of bytes the device actually transferred. > Yes, for fully reliable I/O this value needs to be checked > against what the host adapter or bridge thinks was transferred. Yes. > For ATAPI devices we have a bit of a problem... not enough ... Yes we lack room in the task file for an Atapi device to publish the total byte count it commonly doesn't bother to calculate with its 8-bit microprocessor. This suggests maybe we should decide to publish just the Ide Residue: the most often zero, else most often odd, count of bytes clocked across the bus that the device did not willingly transfer. Even with UDma 133 allowing, is it 5 extra clocks, the worst case Ide Residue is 5 * 2 + 1 = 11 bytes. That fits easily into the x1F5:1F4 AtaCylinder aka AtapiByteCount registers. > ... the number of bytes the device actually transferred. > Yes, for fully reliable I/O this value needs to be checked > against what the host adapter or bridge thinks was transferred. Checking just the residue would make non-block Ide Dma as reliable as Ide Pio - and more reliable when we have the Crc's of Ide UDma. Agreed checking the total would be better ... but as best as we've guessed so far, that's Hard. Pat LaVarre >>> [EMAIL PROTECTED] 12/07/01 11:12AM >>> This message is from the T13 list server. Here are some ways the DMA data transfer count problem can be "fixed"... First it is not important to know how much data the "host side" transferred (fetch or store in memory). The important number is the number of bytes the device actually transferred. Yes, for fully reliable I/O this value needs to be checked against what the host adapter or bridge thinks was transferred. So... For ATA devices implementing 48-bit LBA and for 48-bit LBA R/W commands the device could place its byte count value into the Command Block 48-bit LBA registers at the end of an error free command. Yea, this would probably be a hardware change. Normally there is no data of interest in the Command Block registers at the end of an error free command (the failing LBA is there for a command with an error). For ATAPI devices we have a bit of a problem... There are not enough bits in the ATAPI Command Block register to hold a reasonable total byte count at the end of a PACKET command. The only way I know around this is implement a new ATA non-data command that causes the ATAPI device to put the byte count for the previous PACKET command into the Command Block registers (using SC, SN, CL, CH and the 4 bits in DH, that gives a 36 bit value). Of course this could also be done using an ATA PIO Data In command or even some new PACKET SCSI CDB command (but only if your wanted even worst performance!). *** Hale Landis *** [EMAIL PROTECTED] *** *** Niwot, CO USA *** www.ata-atapi.com *** Subscribe/Unsubscribe instructions can be found at www.t13.org. Subscribe/Unsubscribe instructions can be found at www.t13.org.
