This message is from the T13 list server.
Pat, On things that can do wrong with USB, I agree that folks can get into software problems at the host level. But I don't know what we can do about that at the ATA level. Remember that in a bridge ALL of the information we get to run the ATA protocol is decoded from USB/SBP/etc... commands originally. If the host is trashing the control information before it ges to the bridge, then there is little we can do about it, since the "trashed" data may otherwise look perfectly legal (if unintentional). Jim -----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.
