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.
