This message is from the T13 list server.
Pat,
>From your email:
"Lets turn back to Ata, not Atapi, for a moment. Suppose a
direct-attached Ata host moves out too many blocks for a
vendor-specific Ata command like op xFA. To which standard do we point
to say this host is a BadHost?"
The whole point of vendor specific is that there is no standard to point to
(it is vendor specific). If one of those op codes is used then you have no
clue as to whether the command is a DATA IN or DATA OUT, or has any data at
all. You also cannot parse any of the command information. Unless of
course you know the definition of the (vendor specific) command.
So by definition an ATA host CANNOT move too many or too few blocks for
vendor specific commands, since there is no definition for the number of
blocks to move (if any) in the ATA standard at all. An ATA host can only be
rated on how well it complies with the vendor unique standard, not the ATA
standard, which is silent.
This is a crucial point - some people think standards are designed to answer
all questions and resolve all conflicts. They are not. The vendor specific
command provision is a good example of where a standard allows the
implementer to do whatever the hell they like at the command level (as long
as everything else supports it of course). Note the SCSI has exactly the
same provision and operates in the same manner.
Obviously you use vendor specific commands at your own risk.
Jim
-----Original Message-----
From: Pat LaVarre [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, December 11, 2001 6:18 AM
To: [EMAIL PROTECTED]
Subject: Re: [t13] to Dma from Pio: more Atapi clocks sent?
This message is from the T13 list server.
> [EMAIL PROTECTED] 12/10/01 21:34 PM
> I think my previous email
> basically covers this but....
Me, I do think I see something new here ...
> > The bridge will send too many clocks
> > any time its host tells it only
> > how many bytes of buffer
> > for data out were allocated,
> > rather than the smaller number of bytes
> > that should pass thru.
> Then this is a broken "host"... BAD HOST!
Ahh. Fun. This is slippery in exactly the right area.
Lets turn back to Ata, not Atapi, for a moment. Suppose a direct-attached
Ata host moves out too many blocks for a vendor-specific Ata command like op
xFA. To which standard do we point to say this host is a BadHost?
Suppose the host was built in layers: a bottom layer written by Microsoft,
the upper layer that composed by the command block written by the device
vendor. Can we say the Microsoft layer is broken? Surely not: it's just
accurately passing thru what the vendor's layer asked to have go thru?
Not if a hardware Usb/Ide bridge is transparent enough to let a Usb host
create the identical Ide bus trace, can we say the Usb/Ide bridge is broken?
I don't think so. We have to say the host that composed the command block
and associated a length and direction of data with it is broken. The bridge
is just accurately simulating what would happen if that same host were more
directly attached to the device.
> Attempting to write more data ...
Whoa.
Agreed the bridge is broken per Ansi Ata/pi only if it sends more clocks
than by protocol the device appeared to request. Agreed the results in
Pio/SwDma/MwDma are particularly indeterminate, since they lack the check of
a Crc.
But can we say the bridge is broken per Ansi Ata/pi if it just sends more
clocks than were wanted, simly because they were apparently requested?
For example, if an MwDma device turns DMARQ around too slowly to avoid
requesting x202 bytes rather than x200 bytes, is the host broken to clock
out the extra pair of bytes? If a UDma device turns around too slowly to
avoid requesting x204 bytes rather than x200 bytes, is the host broken to
clock out an extra 4 bytes?
Maybe you want to say yes ... but according to specifically what portion of
what standard?
Even with Ata rather than Atapi, clocking out as many as R + X * 2 + 1 bytes
is correct protocol for such cases as write errors that cut the data
transfer short.
No?
> could be a hung host
> (a host that thinks more data
> will be transferred and is not expecting
> the device to end the command).
Ouch. I have heard of Dma hosts that wait for a timeout to discover the
device did cut the data transfer short. This occurs much too commonly in
Atapi to let a bridge easily be so fragile, though any particular host that
composes command blocks can/should work to avoid this situation.
Pat LaVarre
Subscribe/Unsubscribe instructions can be found at www.t13.org.
Subscribe/Unsubscribe instructions can be found at www.t13.org.
