This message is from the T13 list server.
Hale L:
> Subject: [t13] but both host and device know
> From: Hale Landis
> Date: Friday - April 12, 2002 10:18 PM
> ... Many weeks ago I posted an example ...
...
> Subject: [t13] another example for Pat
> From: Hale Landis
> Date: Friday - April 12, 2002 11:33 PM
> ... I know I posted something similar before ...
If the English here fails to connect us, may I ask you to adapt one or more of your
unanswered examples to discusses the data transfers shown in one of the annotated soft
bus traces I present at:
http://members.aol.com/plscsi/scsinotq.html
?
> ... Many weeks ago I posted an example ...
> ... I know I posted something similar before ...
Indeed here we have fallen just short of connecting completely for a few months now.
Sorry about that.
I do think, every step of the way, you & Jim & co. have taught me to describe the
brutal reality of Windows Atapi more clearly. I'm still talking here because of how
much I appreciate your help.
I can try to echo what I hear you saying - but your examples here now leave me without
line-by-line commentary to offer because they seem to me to be artificially
constructed to duck the real issue.
> I can try to echo what I hear you saying
Yes, any time the host & device do agree out of band in advance over how many bytes to
copy, then using Ansi Atapi they can copy an arbitrary even count of bytes.
Furthermore, any Atapi host that cares could double-buffer to copy an odd count of
bytes, not that many actually do.
Have I heard you? Have I left anything out?
If not, then may we now return to the real world?
Here the host & the device commonly do Not agree over how many bytes to copy. Even
the agreement in read/write of whole blocks breaks down when the block size is not
0.5KiB.
The idea that an tapi Cdb plainly says how many bytes to copy which way is a false
myth. An Atapi Cdb does Not plainly say precisely how many bytes to copy Out. An
Atapi Cdb does Not plainly limit how many bytes to copy In. An Atapi Cdb does Not
plainly say whether to copy bytes In or Out or both ways.
Atapi Cdb's are worse than Scsi Cdb's generally, because of the pointless SFF vs. Ansi
headbutting.
But Scsi Cdb's are broken this way too - all my examples here have been pure Scsi.
Granted, in a sense, broken Cdb's are T10 problems. But at the T10 level, these
problems are complex. Nobody can see fixing them there any time soon.
At the T13 level, these problems are simple ... and in engineering, she who fixes the
problem owns it. T13 did fix these problems in AtapiPio, T13 can fix these problems
in AtapiDma.
We know these problems are simple because all of the plug 'n play OS - Microsoft,
Apple, Linux, ... - include a layer to fix this in the same simple way.
Rather than just passing thru the Cdb, these OS pass the Cdb thru together with a
limit on how many bytes to copy which way.
That is, internally, these OS do plainly say how many bytes to copy which way.
We in T13 have rudely chosen to give the host no way to pass that info on to the
device. Despite our rudeness, Atapi can still be workable, so long as we give the
device a way to say after the fact how many bytes it did not mean to ask to copy which
way.
> http://members.aol.com/plscsi/scsinotq.html
> http://members.aol.com/plscsi/20020328/oddwinme.txt
I'll go ahead and try to translate this one annotated soft bus trace into Hale English
myself.
The trace shows Microsoft WinMe AtapiPio talking to two different Atapi devices.
Always the Cdb is -x 12 0 0 0 05 0, sometimes we copy data by Pio, sometimes by Dma.
AtapiPio shows that our two devices differ in their interpretation of this Cdb. The
first device responds by asking to copy In 6 bytes. The second device responds by
asking to copy In 5 bytes.
AtapiDma hides this ifference - this difference which had been making the second
device work more often. In AtapiDma, both devices have to ask to copy In 3 "word"s of
Data. A standard AtapiDma host cannot know if a request to copy in 3 "word"s is a
request to copy In 6 bytes or 5.
Thank you very much to we of T13. With Atapi Dma, we can't know if the device has
asked copy N * 2 bytes or N * 2 - 1.
With Atapi MwDma in theory, with Atapi UDma in practice, this indeterminacy rises with
burst rate. Because the receiver can't halt a copy on arbitrary "word" boundaries,
the sender cannot know if the receiver meant to accept all the "word"s copied or in
fact quietly discarded as many as 2 * X + 1 bytes at the end.
Clear now?
Or can you verbalise why not?
Curiously yours,
Pat LaVarre
