This message is from the T13 list server.
Pat, Thanks much for the trace data. I took a look at your traces, but they did not help me much. Where is it being traced? Do you have a logic analyzer on the ATA bus, or is the program looking at the buffers used in the host? Since it is displaying additional bytes (the "2E") I suspect the latter (i.e. it is dumping from buffer memory and displaying whatever was in the buffer). My problem here is that ATA only focuses on what in on the bus, not what's in the buffer. What ends up in the buffer is a combination of what was transferred across the bus, what is then transferred across the PCI bus, and then what is copied by host software. The later two have nothing to do with ATA, T13, or T10. Indeed, since your trace appears to be doing this "rounding up to the nearest 4 or 8 bytes," I expect that the problem is in the host software/PCI hardware (e.g. someone thought that PCI should only be used to transfer multiples of 4 bytes, and avoided using the byte lane capabilities to transfer odd bytes for some reason). There is no reason I can think of why any ATAPI device would do this (they are usually 8 or 16 bit devices anyway). BTW, I'm not at all confused about the PACKET command not specifying the number of bytes to transfer. Indeed, I pointed it out in a previous email. It's why I'm totally confused when you talk about the number of bytes being transferred for a command being a negotiated quantity. Not only is that untrue in ATA/ATAPI, but it's also untrue in SCSI. All of this is only known at the command layer, not at the transport layer protocol. This fact is deeply rooted in the entire set of protocols. If the definitions of the SCSI commands, or the products that interpret them, are flawed (which I'm certainly willing to believe), then they should be fixed. Monkeying around with the transport layer just does not appear to make any sense, since the problem you're concerned about appears to be a command layer problem. In the case of your traces, I expect that the host software can interpret the device's response just fine (after all, these are shipping products). Unfortunately, the rules for how the host software behaves is not covered by ATA or T13/T10 standards, only in vendor documentation. And so I doubt it's uniform across all vendors. Jim -----Original Message----- From: Pat LaVarre [mailto:[EMAIL PROTECTED]] Sent: Saturday, April 13, 2002 7:59 AM To: [EMAIL PROTECTED] Subject: [t13] on residue - short, concrete, reproducible? This message is from the T13 list server. >>> [t13] but both host and device know >>> Hale Landis 04/12/02 21:23 PM >>> > this conversation ... the phone. I include my office/voicemail phone number in most person-to-person email, on request I'd be happy to include my pager number also. > ATA/ATAPI PIO works just like ATA/ATAPI DMA > Where or what is the difference you see? We now have actual concrete bus traces on the web, trivially reproducible, to show the reality of this difference that people here have been so consistently denying. Here I'll discuss: http://members.aol.com/plscsi/20020328/oddwinme.txt As Sbp3 folk suggested Friday, maybe the key misconception confusing the talk here is the false idea that an Atapi Cdb plainly tells the device how many bytes to copy which way. Try for example the Atapi Cdb -x 12 0 0 0 05 0. The pretty fiction published by Ansi T10 claims this Cdb asks to copy In up to 5 bytes i.e. up to all of the fixed length header that ends with the additionalLength byte at offset 4 to tell us how many more bytes the device has made available. Back in the real world, the annotated soft bus trace I mentioned i.e: http://members.aol.com/plscsi/20020328/oddwinme.txt shows us how I commonly see actual hosts and devices choose instead to copy In 8, 6, or 5 bytes. Only with AtapiPio - not with AtapiDma - do we ever see 5 bytes. Copying a T10-correct count of bytes is a competitive advantage AtapiPio, Usb, and classic parallel Scsi hold over some of the alternatives. Even with AtapiPio, we see 6 bytes instead of 5 depending on the quality of AtapiPio implementation. Always, because an Ide bus is two bytes wide, 2 * N bytes clock across the bus. The only question here is whether the device reports and the host appreciates that the last byte is meaningless. With AtapiDma, mere quaity of implementation can't rescue us. T13 offers no standard protocol for the device to report that the last N bytes were meaningless. Always, if we want to copy a fifth byte into memory, we have to also copy a sixth byte into memory. Microsoft's WinME AtapiDma implementation traced here is poor, but not uncommonly poor. Here the implementation seemingly rounds up the length of all AtapiDma copies to the nearest multiple of four. By analogy we can expect that in the years to come real people will start rounding lengths up to multiples of eight. WinME AtapiDma is at least not as broken as Win95B AtapiPio, which hung any time the AtapiPio DRQ ByteCount wasn't even. Clear now? An Atapi Cdb does not plainly tell the device how many bytes to copy which way. And neither does any vendor-specific Ata op. Nor do they plainly limit how many bytes to copy which way. Actual Cdb's correlate no more than loosely correlate with the counts of bytes the host and the device ask to copy which way. The reality of an actual bus trace is undeniable. We could still argue about how rare or common such traces are - but maybe I can't contribute much there. I have nothing but my seven years of fixing real plug 'n play troubles to back my claim that such traces are common. Thanks again all for helping me work thru why this reality is difficult to explain. Pat LaVarre
