This message is from the T13 list server.
(((Apologies in advance if you see this twice. I sent this four hours ago, it has not yet arrived back. Is that life on the Internet ... or is something really wrong? It's inconvenient for me because I'm quoting t13 traffic in offline correspondence.))) > > [EMAIL PROTECTED] 11/26/01 10:42PM >>> > > [any bridge to Ata/pi is an Ata/pi host] > > a bridge thing should be able to detect > > when ... and when a command has transferred > > the correct number of data bytes, etc, > Pat LaVarre 11/27/01 09:09AM > But I've been told counting the bytes moved is > an unsolvable problem in the UDma protocol > as it stands? I'm pleased to report I can now back this rumour up with specific detail. Anyone care to confirm/deny this defect in the protocol to which we all apparently gleefully agreed without mention? The issue arises with UDma hosts & devices that are so rude as to move one to four bytes of extra data past the termination of the last burst in a UDma transfer. If the transfer is a write, the host cannot know if the device wrote that data to the media. If the transfer is a read, the host cannot know if that data came from the media. By design, the UDma Crc offers no protection: that Crc includes every byte that crosses the bus, no matter if the device wrote/read it on the media or not. > ... Workarounds? Ick, nothing that's good & fast & cheap. The key phrase in all of these is "if somehow magically". 1. If somehow magically the host & the device can establish that the sender of the data will never be so rude as to clock garbage, then both the host & the device can count byte pairs clocked. Then they both can know how many byte pairs the receiver moved. 2. If somehow magically the host & the device can establish that they both agree that the transfer was a block transfer, and also that they both agree how large a block was for this particular transfer, then they can round off the apparent count of byte pairs to the nearest block. 3. If somehow magically the host & the device can establish a maximum possible byte count for the transfer, then they can round down the apparent byte count to that max. 4. If the device reported an error on a non-block transfer, the host & device are out of luck. They flatly cannot know how many byte pairs the other did move. Of course, if we really meant computers to be useful for more than games, we would design them in many, many different ways. I once met a designer who spoke of issues like this as "farts in the wind". Pat LaVarre x4402 Subscribe/Unsubscribe instructions can be found at www.t13.org.
