This message is from the T13 list server.
Pat, why do you insist that ATA/ATAPI can ever stop at an odd-byte boundary? It transfers data as atomic words (except for CFA, which I hope you aren't gonna confuse matters by talking about that). You may be getting this on the host-side of a USB-to-ATA/ATAPI bridge, but not specifically due to any ATA/ATAPI interface allowance. Your insistence that this happens on ATA unnecessarily perpetuates these threads. MKE. -----Original Message----- From: Pat LaVarre [mailto:[EMAIL PROTECTED]] Sent: Friday, January 25, 2002 5:01 PM To: [EMAIL PROTECTED] Subject: Re: [t13] UDma < Pio for byte count negotiation? This message is from the T13 list server. This message is from the T13 list server. > Harlan Andrews <[EMAIL PROTECTED]> 01/25/02 04:41PM > Maybe I begin to see your confusion. Thank you Harlan A and all the other listeners here for your remarkably continued patient interest. Here now in just three sentences is a new try at an English nutshell of the pain I'm feeling: Switching to AtapiUDma from AtapiPio introduces a different kind of assymetry into the negotiation of byte counts transferred. In AtapiPio, the host can end the data transfer on any 16-bit "word" boundary and the device can end the data transfer on any byte boundary. In AtapiUDma, the sender of data clocks can end the data transfer on any "word" boundary but the receiver of data clocks can only end the transfer after as many as X unwillingly requested words cross the bus. > The pause ( which creates the 'extra' bytes) can happen at ANY point. Yes. This gets interesting only when the host and the device do not agree perfectly out of band in advance which byte should be the last byte, for example by less than perfectly agreeing over Cdb interpretation. > If you are using the byte count > to determine SECTOR size, then forget it. > It can't be done. I think I did hear this was what Mark S was doing. I hesitated to reply here under the same subject line, because this is NOT what I'm doing. Me, I'm just trying to get the host and device to agree precisely and explicitly on how many bytes each has moved. Me, I don't care if the agreed byte count relates intelligibly or not to the block count expressed in the Cdb ... but I do think I did hear Mark S does care. > If you are using the byte count > to determine SECTOR size, then forget it. > It can't be done. I imagine this works ok in AtapiPio for Mark S because of a common practice nowhere guaranteed in the specs: that the AtapiPio INTRQ DRQ x1F5:1F4 Cylinder (aka ByteCount) be a multiple of whole blocks. This common practice is hinted at in the Jan 1996 Sff8020i rev 2.6 discussion of the Ansi DRQ "byte count limit" (i.e. the Sff "DRQ limit"): "... the minimum size of the DRQ limit shall be no smaller than the length of data to be transferred for one sector from the media. This limitation would only be valid for Media Access commands and not applicable to Mode Sense, Inquiry, etc. I think I remember the Ansi texts give the device no protocol to reject unsupported byte count limits. In effect, this lack of protocol says that a device shall support, for example, moving block data just two bytes at a time. I've long been curious to discover if I will die before I discover a device willing to do such a silly thing. I hear instead that actual devices either round up the byte count limit to the block size, or they reject the command with a vendor-specific SK ASC ASCQ, or they hang BSY, or .... > The burst size has NOTHING > to do with the SECTOR size. No spec'ed relation, aye. > The pause ambiguity is not really extra bytes. These bytes are "extra" in the sense of "not willingly requested". Suppose a device stops a UDma33 transfer out after x202 bytes clocked across the bus and the Crc check passes. If we had been using Pio mode instead, would this same device have requested x1FC, x1FD, x1FE, x1FF, x200, x201, or x202 bytes out? We cannot know. Aye, the device and the host can agree that x202 bytes clocked across the bus, with more confidence in UDma than in Pio because of the Crc. But we cannot know how many of these bytes the device wanted to move unless it tells us, using some not yet invented protocol. > The pause ( which creates the 'extra' bytes) can happen at ANY point. _Can_ happen at any point, aye. _Does_ happen is less simple. Much AtapiUDma hardware has a knowledge of block size. In particular, Usb 480e+6 bit/s hardware pauses between the x200 byte "packets" of Usb. Conveniently enough, those pauses correspond precisely with x200 byte disk blocks. Why do we ever care? Well, suppose the sender of UDma data clocks merely neglects to sends clocks for more than a turnaround time at each block boundary. I don't mean negotiate a pause - I mean just neglect to clock another "word" for a time. Any such sender in effect gives the receiver of clocks an opportunity to end the transfer at any block boundary. > some not yet invented protocol I suggest the Atapi device ordinarily end a command with x1F5:1F4 Cylinder (aka ByteCount) zeroed. Any device designer who agrees it is possible for the host to move more bytes out than wanted can (probably trivially) count the bytes leftover and report that count as a nonzero residue. Any host designer who believes it is possible for the host to move more bytes out than wanted can look at that count to find out how many more did move. > The pause ambiguity is not really extra bytes. > They are part of the data stream. They are part of the Crc, aye. > At the end of the transfer, the amount of data > actually transferred will be (number of blocks) * (BlockSize). This is the relation at issue. The equality stated holds true only if the host tries to move out only less than or precisely as many blocks as the device expects. Suppose the host tries to move out more blocks. Then the count of bytes clocked across the bus will be a count chosen indeterminately according to relative timing from the range N * K + 0 ... N * K + X * 2, where N = number of blocks, K = block size, X = the max indeterminacy counted in 16-bit "word"s. > You should NOT expect > the intermediate bursts > to have ANY resemblance to block size. This resemblance commonly does appear. But, again, few/no public specs mention it, much less guarantee it. > Maybe I begin to see your confusion. I share your hope. Thanks again in advance. Pat LaVarre Subscribe/Unsubscribe instructions can be found at www.t13.org. Subscribe/Unsubscribe instructions can be found at www.t13.org. Subscribe/Unsubscribe instructions can be found at www.t13.org.
