This message is from the T13 list server.
[ BC [EMAIL PROTECTED] ]
>> Hale: Why do you need all 16-bits of the Byte Count registers to report a
>residue value that can only be 0 or 1?
>Pat: In UDma 2 this value is sometimes as high as 5. I know at length here before
>I've failed to explain clearly why, but it's a fact.
That is because it isn't a fact
HELLO. It is on a BUS TRACE. Seen not only by my eyes but by eyes across the Usa and
abroad. It is a fact. The issue can only be that I'm not explaining myself clearly.
Trust me, I'm trying.
> The command, be it an ATA hard disk command or an ATAPI/SCSI CDB, absolutely and
>without question determines the data direction and the amount of data. A host must
>have every expection that the device will properly execute the command or indicate
>error status.
Yes.
> This is one of the most basic concepts of computer I/O?
Yes.
> Why are we talking about this here?
Because You're not listening? Certainly you're not hearing me.
(((Granted, I'm not hearing you well enough to echo back to you what you say in a form
you can swallow, but like you I am trying as hard as I can to listen. I haven't
phoned you today only because I missed the end-of-business deadline you shared
offline. I have acquired the AAA battery needed to make my pager work. You do have
my phone number.)))
Yes the "command" must indicate how many bytes to copy which way, however that is
encoded, yes certainly.
Your error here is to think the Cdb is the whole "command". Viewed in the light of
the most basic precepts of computer i/o, it isn't the WHOLE command. To a classically
trained programmer, what's bizarre about many Scsi-over-whatever protocols, and T13
Atapi protocol in particular, is that these protocols do not include in the "command"
a plain indication of how many bytes to copy which way. As a device, all you get is
the Cdb, in place of what you need. So you're stuck patching up life afterwards.
Yea, sure, on paper you can say that what you have must be what you need. Well, it
isn't. Welcome to the real world.
Ask yourself. Why is the common core of Scsi Api's across platforms:
int ...(void const * cdb, int cdbLength, void * data, int dataLength, boolean
pleaseIn)
That common core is not just:
void const * cdb, void * data
That common core does not just return pass/fail, but also positive residue.
Why is this?
Because "everyone knows" the Cdb does not plainly indicate how many bytes to copy
which way.
Take the now familiar example of Cdb -x 12 0 0 0 05 0. In unambiguous English, Ansi
T10 claims this Cdb means copy between 0 and 5 bytes In. But the trivially repeatable
trace http://members.aol.com/plscsi/20020328/oddwinme.txt shows that Windows often
decides instead to copy In 8 or 6 bytes, not just 5.
Hello, EIGHT. If as a host you were to claim that this Cdb copied In only 5 bytes you
would arrange for the device to ask to copy MORE bytes than the host asks. You'll
hang if you're lucky, crash if you're not.
I didn't construct this trace artificially. I took the two Atapi devices I had
nearest at hand, devices I use in office work, and I sent an Inquiry to sample the
additionalLength at offset 4 that by T10 tells me whether the device makes more bytes
available or not. This is a simple basic elemental start-of-life thing to do ... it's
one of the first things I tried on reading the Scsi spec in 1994 ... and in Atapi it
doesn't work. (In eight-bit parallel Scsi, it worked fine.)
All that pretty fiction published by Ansi T10 has no place in something as real and
essential as an Ansi T13 specification.
Ansi T13 AtapiPio tells a device how to ask to copy an arbitrary count of bytes either
way - no matter what how many bytes Ansi T10 thinks the device should have asked to
copy whichever way.
T13 AtapiDma should be equally arbitrary, equally free of T10 entanglement.
x4402 Pat LaVarre [EMAIL PROTECTED]
http://members.aol.com/plscsi/
>>> Re: [t13] Proposal to 'fix' ATAPI DMA
>>> Hale Landis 04/15/02 02:41PM >>>
This message is from the T13 list server.
On Mon, 15 Apr 2002 14:16:00 -0600, Pat LaVarre wrote:
>This message is from the T13 list server.
>> Hale: Why do you need all 16-bits of the Byte Count registers to report a
>residue value that can only be 0 or 1?
>Pat: In UDma 2 this value is sometimes as high as 5. I know at length here before
>I've failed to explain clearly why, but it's a fact.
That is because it isn't a fact. Here again we are back to what I can
only describe as a failure to understand how ATA/ATAPI data transfers
are performed and especially how UltraDMA transfers are performed. I
have posted several examples in an attempt to clear up this
misconception. Apparently you keep ignoring them because you think
they are not "real world" enough, yet they demostrate many of the
very basic issues that we keeping commenting on here without
resolution.
>In practice my fix for getting direction straight was (d) to write x1F3 with
>x80 In or x00 Out before o x1F7 xA0 Packet, to let the device see the
>direction the host wanted.
This has never been necessary to my knowledge in 10+ years of ATA or
8+ years of ATAPI. Why now?
The direction of data movement and the amount of data moved by a
command is not open for negotiation. The command, be it an ATA hard
disk command or an ATAPI/SCSI CDB, absolutely and without question
determines the data direction and the amount of data. A host must
have every expection that the device will properly execute the
command or indicate error status. Why are we talking about this here?
This is one of the most basic concepts of computer I/O?
*** Hale Landis *** www.ata-atapi.com ***
