This message is from the T13 list server.
Pat, What are you talking about? In DATA OUT the host never tells anyone the number of bytes allocated in the buffer. It ALWAYS tells the device the EXACT number of bytes it will transfer. It's only on DATA IN that the host tells folks about buffer allocation sizes and not exact transfer lengths. Once again, there is NEVER a problem with either DATA IN or DATA OUT in ATAPI using UDMA as long as the number of bytes in the command is a multiple of 2 (not the block size, which has nothing to do with any of this). At least, nothing that you're telling me indicates a problem. Only the odd byte case looks interesting (and that only at the end of the command). If you are seeing otherwise you're dealing with faulty products. Basically you have to either trust the intelligence in the host and device or parse the commands yourself in the bridge. But you appear to be asking for a check on the host and/or device outside of parsing commands. That just does not appear to make a lot of sense (once again, odd byte may be an exception). Jim -----Original Message----- From: Pat LaVarre [mailto:[EMAIL PROTECTED]] Sent: Monday, December 10, 2001 9:24 AM To: [EMAIL PROTECTED] Subject: [t13] to Dma from Pio: more Atapi clocks sent? 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. Subscribe/Unsubscribe instructions can be found at www.t13.org.
