This message is from the T13 list server.
On Sat, 13 Apr 2002 09:49:08 -0600, Pat LaVarre wrote: >This message is from the T13 list server. >If the English here fails to connect us, may I ask you to adapt >one or more of your unanswered examples to discusses the data >transfers shown in one of the annotated soft bus traces I present >at: http://members.aol.com/plscsi/20020328/oddwinme.txt I did look at these web pages. But I don't see that they are actual bus traces from an ATA, SCSI, USB or 1394 hardware bus analyzer. I can only assume these are in memory results your test program thinks it is seeing after the execution of a command. Does you program use the Windows ASPI interface? Or does it take advanage of some "back door" API entry to the Windows driver stack? How can we know if the apparently data movement seen by your program is the result of hardware activity or OS driver software activity? Can you provide us with a real ATA bus analyzer trace showing the same command(s)? Then we will have something to talk about (maybe). >Here the host & the device commonly do Not agree over how many >bytes to copy. Even the agreement in read/write of whole blocks >breaks down when the block size is not 0.5KiB. CD-ROM device have all kinds of "block sizes" and most are not N*512 bytes. I have not heard that this is a big problem or that it is any kind of problem. >The idea that an [A]tapi Cdb plainly says how many bytes to copy >which way is a false myth. An Atapi Cdb does Not plainly say >precisely how many bytes to copy Out. An Atapi Cdb does Not >plainly limit how many bytes to copy In. An Atapi Cdb does Not >plainly say whether to copy bytes In or Out or both ways. Huh? (I don't know what else to say as a response!) >But Scsi Cdb's are broken this way too - all my examples here >have been pure Scsi. But do we know what all the layers of OS device drivers are doing while executing your examples? Do we know what is really happening on the ATA, SCSI, USB or 1394 hardware interfaces? >At the T13 level, these problems are simple ... and in >engineering, she who fixes the problem owns it. T13 did fix >these problems in AtapiPio, T13 can fix these problems in >AtapiDma. OK, get a T13 document number and submit your proposal to fix the problem(s) you see. At this point I think this is the *ONLY* way we will understand what you think is broken and why it should be fixed. >Rather than just passing thru the Cdb, these OS pass the Cdb >thru together with a limit on how many bytes to copy which way. OK, and will we also define all the possible error conditions that result when this doesn't work? Where and how are these errors detected and reported? >That is, internally, these OS do plainly say how many bytes to >copy which way. You knowledge of the internal working of these OS drivers certainly exceeds my knowledge! >I'll go ahead and try to translate this one annotated soft bus >trace into Hale English myself. >The trace shows Microsoft WinMe AtapiPio talking to two >different Atapi devices. >Always the Cdb is -x 12 0 0 0 05 0, sometimes we copy data by >Pio, sometimes by Dma. >AtapiPio shows that our two devices differ in their >interpretation of this Cdb. The first device responds by asking >to copy In 6 bytes. The second device responds by asking to copy >In 5 bytes. No, we know the ATA interface is 2 bytes wide. We know that on the ATA interface 6 bytes where transferred. You are not showing us a trace of the actual ATA interface activity so we don't know what Byte Count value(s) the device used. But we don't care, the CDB tells us that only the first 5 bytes should contain the data we requested. I don't see a problem here. >AtapiDma hides this ifference - this difference which had been >making the second device work more often. In AtapiDma, both >devices have to ask to copy In 3 "word"s of Data. A standard >AtapiDma host cannot know if a request to copy in 3 "word"s is a >request to copy In 6 bytes or 5. Again we don't care. The CDB tells us that only the first 5 bytes contain the data we requested. Plus we don't know how the data your program sees in its data buffer got to that data buffer. Did the hardware PRD point directly to the buffer? Did the OS drivers "double buffer" the data and then move the data a word or a byte at a time to your buffer? >Thank you very much to we of T13. With Atapi Dma, we can't know >if the device has asked copy N * 2 bytes or N * 2 - 1. We know that 2*N bytes were transferred on the ATA interface. We know that only 2*N-1 (or in this case 5 bytes) contain the data we requested because that is what we requested in our CDB. >With Atapi MwDma in theory, with Atapi UDma in practice, this >indeterminacy rises with burst rate. Because the receiver can't >halt a copy on arbitrary "word" boundaries, the sender cannot >know if the receiver meant to accept all the "word"s copied or in >fact quietly discarded as many as 2 * X + 1 bytes at the end. As I have said before: Only a BAD HOST would program the host side DMA engine incorrectly. The CDB tells the host to program the DMA engine for 6 bytes and the CDB telss the device to send 5 bytes plus a pad byte. We can discuss broken host or device impelemtations all day but that is a waste of time. Please get a T13 document number and submit your proposal! *** Hale Landis *** www.ata-atapi.com ***
