This message is from the T13 list server.
>>> "Mcgrath, Jim" <[EMAIL PROTECTED]> 12/05/01 02:22PM >>> > ... on the last burst transferred > the sender should never be sending > any more bytes than the receiver should expect > if the number of bytes for the COMMAND (not the bursts) > was known ahead of time to both parties. Yes if. > If the sender does do that (i.e. in essence > decrements the bytes to send for the command > counter to a negative number), > then feel free to shoot the vendor of the product. I wish. Any fully transparent Usb/AtapiUDma bridge will do exactly this on occasion. 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. The receiver of clocks won't get a chance to halt the traffic until after (X * 2 + 1) too many bytes have clocked across the bus. Maybe many more hosts will start to adopt the Wintel tradition of pretending to have allocated only the number of bytes to pass thru. That tradition has its own troubles. I remember seeing AtapiPio hosts that passed thru the count as a byte count limit at op xA0 Packet time. This meant that the device sometimes saw unintelligible byte count limits like x00:00 and x00:01. But maybe on balance trying to count just the bytes that should pass thru is the least awful choice. Pat LaVarre Subscribe/Unsubscribe instructions can be found at www.t13.org.
