This message is from the T13 list server.
Actually, in you examle none of the bytes are valid. The protocol clearly states that on commands with an error (which this would be), you cannot rely on the data transferred to tell you what was valid and what was not. Indeed, it is perfectly valid for the device to notice the error, continue to send you data bytes (which of course were not the ones you wanted), and at the end to signal that the command was in error. When you get a command error you can try and get more information from the device to pinpoint the error location. But in any event you have to retry the command (or break the command apart and try it for each of the LBAs seperately) in order to get the data you want. No data is valid unless these retrys succeed (i.e. no error on the command). Jim PS I'm actually an ATA expert, but I don't remember ATAPI commands behaving any differently. -----Original Message----- From: Pat LaVarre To: [EMAIL PROTECTED] Sent: 12/3/01 9:34 AM Subject: RE: [t13] UDma count well not - how observable on a PC? This message is from the T13 list server. Thank you again for sharing the PC experience you enjoy that I utterly lack. What you write looks to me like you like to pretend the out-of-band communication that decides which bits of the command mean a count of bytes moving which way in what units is reliable? To try and settle first the distinctive UDma limitation here, rather than the reality of the unreliable out-of-band communication that makes that distinctive limitation matter, let me try a new specific example: Suppose the host asks to read 7 blocks from Lba's 0 1 2 3 4 5 6. Suppose our device reads blocks 0 1 2 but then moves no more data, because block 3 was not intelligible, because of an unrecoverable error. (Possible everywhere but more common with removable media written by one mechanism and read by another.) Can we know how many bytes of the app data buffer does the host change? 3 blocks ... or 3 blocks plus two bytes ... or 3 blocks plus 4 bytes? Back in the halcyon days of Pio & Dma, we knew the answer: 3 blocks plus zero bytes. I'm being told, with UDma, we don't know the answer. Any of those three answers are permitted by indeterminacy built into and equally blessed by the standard. Untrue? Thanks again in advance. Pat LaVarre x4402 >>> "Ooi, Thien Ern" <[EMAIL PROTECTED]> 12/02/01 09:40PM >>> This message is from the T13 list server. On a PC, the host controller should/would not move garbage to main memory, because the host controller will not transfer more data than what was specified in the transfer count in the DMA engine. So, the extra data, garbage, if it may be, is used to calculate the CRC, but the host controller would be very careful about stopping at exactly the point when the transfer count expires, as far as sending the received data to memory is concerned. Then, when software ends the DMA transfer by first clearing the START bit, the garbage data, if any, is flushed. TE. -----Original Message----- From: Pat LaVarre [mailto:[EMAIL PROTECTED]] ... If UDma permits the sender to clock garbage, then even a host that double-buffers its i/o can't know how many bytes to move to/from app space. The garbage reaches all the way back to the app, just like the out-of-band communication that decides which bits of the command mean a count of bytes moving which way in what units. ... Subscribe/Unsubscribe instructions can be found at www.t13.org. Subscribe/Unsubscribe instructions can be found at www.t13.org.
