This message is from the T13 list server.
Pat,
I think you're asking for something that just really does not make any sense
in this context:
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.
All of these protocols do require that the host and device agree on what the
CDB (Command Descriptor Block) is and act accordingly. You appear to want
some sort of independent check on that. But that is just insane. If the
host and device do not agree on the command being used, then you IO system
is smashed. For instance, if the device thinks the host wants a FORMAT with
it issues a READ, then you're just hosed.
Note that other than hardware transmission failures (which the various
interfaces do a better or worse job of handling), the only other reason I
can see for this sort of miscommunications is incorrect software. But
that's why we have standards, documented APIs, and in the last resort
compatibility testing. I can certainly see people writing bad software, but
this problem does not have anything to do with PIO or DMA and the like.
Jim
-----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.
> 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.
