This message is from the T13 list server.
> >>> Hale Landis 04/15/02 05:38PM >>> > I strongly suggest you talk to your friends at > Microsoft if you think their OS drivers are not working properly. This is silly. Microsoft Is. There's nothing I can do about it, even if I thought they were broken, and I don't. > >> Harlan said: The device is SUPPOSED to transfer in 6 bytes > >> the host requests 5. > >No ... or you lost me. > > Harlan is right. The *device* transfers 6 bytes. It is all in the > definition of a "pad byte". I agree our English is falling apart precisely here. I'm drawing a very careful distinction between the count of bytes clocked across the bus, which people like T13 can redefine meaningfully, and the count of bytes copied, which was set in stone by the dawn of Scsi and the need to be utterly compatible ever since, no matter what anyone prints on paper. > On Mon, 15 Apr 2002 16:45:00 -0600, Pat LaVarre wrote: > >This message is from the T13 list server. > >Yes exactly. T13 AtapiPio lets the device ask the o.s. to double-buffer at > >least the last byte by making the sum of x1F5:1F4 odd. T13 AtapiDma leaves > >that feature out. > > No it didn't! Yes it did. Look, I can tweak firmware here. If in the device I change nothing but the x00:05 to x00:06, Windows copies In 6 bytes rather than 5. Windows chokes if the app only allows 5 and I ask to copy in 6, but works just fine when the app only allows 5 and I ask to copy In 5. I'm talking about real life, not printed fictions. Windows AtapiPio gives the device this much control over achieving the correct result of copying In 5 bytes, and no more. Windows AtapiDma gives less. T13 could help fix that. > The CDB said the application wanted 5 bytes. T10 agrees with you that the Cdb -x 12 0 0 0 05 0 copies In 0 to 5 bytes. Ever device I ever shipped agrees with you. But I haven't shipped more than twenty different Scsi devices in my life. But lots of real devices disagree with you and me. Welcome to the real world. > This has > nothing to do with the execution of the ATAPI PACKET 'Inquiry' > command on the ATA interface. We're talking about two bus traces that differ only in one bit. Can't get more gut-level than that, can we? > Pat: Let me ask a question: If your program attempted to execute this > 5 byte Inquiry [Cdb] and in the parameters to the OS driver stack > it provided the following: > > a) your famous Inquiry CDB. [-x 12 0 0 0 05 0] > b) the memory address of an 8 byte I/O buffer. > c) the size of the I/O buffer as 8 bytes. > > How many bytes would you expect the OS driver stack to store into > your application program's I/O buffer? This is no different in essense then the case actually traced at http://members.aol.com/plscsi/20020328/oddwinme.txt ? There the host asked to copy x0E bytes, but the distinction between x08 and x0E bytes of Data buffer is not significant here. I would expect the OS to copy in 8 or 6 bytes if I was using Dma, 6 or 5 bytes if I was using Pio. I would wish for the OS to copy In 5 bytes always, in accord with the empty fantasies printed by T10, but I wouldn't lose much conscious time over that. If I was using Pio with a T10 & T13 compliant device, I would expect the OS to copy in 5 bytes ... but devices like that are rare. I've never seen one that I didn't ship myself, except for the devices that shipped from the same firmware base that I was hired to modify. (I've worked mostly with desktop devices available retail.) > Pat: Another question: What if you application's CDB asked for 100 > bytes but the I/O buffer was only 8 bytes? What happens? Hmmm. I think here you mean the command -x 12 0 0 0 64 0 -i 8, sent to a device that responds by asking to copy In x64 bytes. T10 does not require this response - a device could choose to make some other count of bytes available, like x24 or x5. But if we assume the device does ask to copy In x64 bytes, then here we have the device asking to copy In more bytes than the host means to allow. This is the Hi < Di case, case 7 of the 13, discussed among other forms of "negative residue" at http://members.aol.com/plscsi/ftf.html#minus What's fun is that with Microsoft Windows AtapiDma we can get into this same situation with the command -x 12 0 0 0 05 0 -i 5. No matter that the device meant to ask to copy In 5 bytes, Windows will decide the device asked to copy In 6 or 8 bytes or more. What happens next varies with the quality of implementation. At that #minus Url above, we see: "(H < D) Negative Residue (Cases 2, 3, 7, 13) Here the device asks to copy more than the host asks. "A host that agrees to this has agreed to evil: the host either has to discard bytes copied In or else fabricate bytes copied Out. "To say "negative residue" here, we have to expand the "residue" to mean the difference between the count of bytes the host asked to copy and the count of bytes the device agreed to copy. In cases 2, 3, 7, and 13, that residue is negative. "Many systems hang when this occurs. Others really do discard and fabricate data without complaint. > >Are you carefully distinguishing the 6 bytes that should be clocked across the > >bus from the 5 bytes that should be copied into memory? I'm not sure, since > >you chose to use the term "transfer". > > At T13 we don't normally talk about internal OS device driver design > issues, especially how OS drivers access and use I/O buffer space in > system memory. Somebody wrote this text into the standard: Revision 18 19 August 1998 ... Ata/Atapi 4 ... 8.21 PACKET ... A0h ... 8.21.5 Normal outputs ... 8.21.5.2 Data transmission ... ... 5) if the byte count is odd, the last valid byte transferred is on DD[7:0] and the data on DD[15:8] is a pad byte of undefined value; 6) if the last transfer of a command has a pad byte, the byte count shall be odd. ... I/O - Shall be cleared to zero if the transfer is to the device. Shall be set to one if the transfer is to the host. How can anyone read "if the last transfer of a command has a pad byte, the byte count shall be odd." to be anything but a reference to the fiction of T10 and realities at the same level? > >May I vote to defer discussing MWDMA and UDMA til we understand each other re > >PIO and SWDMA? > > I don't want to do that because ... Please? MwDma in theory & UDma in practice are only more broken than SwDma when we can't know out of band in advance that the device & the host have agreed over how many bytes to copy which way. So long as you persist in denying that reality, you won't see the problem. We can't talk about MwDma & UDma until you're ready to suspend your disbelief for the duration of a discussion. x4402 Pat LaVarre [EMAIL PROTECTED] http://members.aol.com/plscsi/
