This message is from the T13 list server.
Pat, I think we're making some progress here. My contention has been that this is a command level issue, and you appear to agree. My problem here is that I'm not convinced its a practical problem, since it would appear that SCSI commands are executed perfectly fine today on a whole variety of physical interconnects. So why is this not a problem for them, while it is a problem for ATA (as you contend?) True, parallel SCSI has a message to tell the receiver that the last data word (16 bits) was only a single bye with a pad. But I've never seen anyone use this approach. I'd need more information to make a good guess myself, but my intuition tells me that most SCSI implementations probably handle this by only execution the "strange" data commands (e.g. INQUIRY) while in 8 bit transfer mode (at power up/after reset when 8 bit is the default, and before wide negotiation). At the end of the day how SCSI commands are transported across various protocols is actually a T10 responsibility. Other committees, like T13 for ATA and T11 for Fibre Channel, will implement what is required, but the requirements come out of T10, since they control SAM and the command sets. So I'd bring up the issue first with T10, and get their direction. If T10 thinks there is a problem, then I'm sure T13 will implement a solution. But since T13 is not responsible for SCSI command set issues, I doubt they're going to want to "patch" a protocol to fix a command layer issue - especially without input from the people who do control the command layer. To me that's only common sense. Jim -----Original Message----- From: Pat LaVarre [mailto:[EMAIL PROTECTED]] Sent: Saturday, April 13, 2002 8:49 AM To: [EMAIL PROTECTED] Subject: Re: [t13] another example for Pat This message is from the T13 list server. Hale L: > Subject: [t13] but both host and device know > From: Hale Landis > Date: Friday - April 12, 2002 10:18 PM > ... Many weeks ago I posted an example ... ... > Subject: [t13] another example for Pat > From: Hale Landis > Date: Friday - April 12, 2002 11:33 PM > ... I know I posted something similar before ... 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/scsinotq.html ? > ... Many weeks ago I posted an example ... > ... I know I posted something similar before ... Indeed here we have fallen just short of connecting completely for a few months now. Sorry about that. I do think, every step of the way, you & Jim & co. have taught me to describe the brutal reality of Windows Atapi more clearly. I'm still talking here because of how much I appreciate your help. I can try to echo what I hear you saying - but your examples here now leave me without line-by-line commentary to offer because they seem to me to be artificially constructed to duck the real issue. > I can try to echo what I hear you saying Yes, any time the host & device do agree out of band in advance over how many bytes to copy, then using Ansi Atapi they can copy an arbitrary even count of bytes. Furthermore, any Atapi host that cares could double-buffer to copy an odd count of bytes, not that many actually do. Have I heard you? Have I left anything out? If not, then may we now return to the real world? 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. The idea that an 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. Atapi Cdb's are worse than Scsi Cdb's generally, because of the pointless SFF vs. Ansi headbutting. But Scsi Cdb's are broken this way too - all my examples here have been pure Scsi. Granted, in a sense, broken Cdb's are T10 problems. But at the T10 level, these problems are complex. Nobody can see fixing them there any time soon. 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. We know these problems are simple because all of the plug 'n play OS - Microsoft, Apple, Linux, ... - include a layer to fix this in the same simple way. 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. That is, internally, these OS do plainly say how many bytes to copy which way. We in T13 have rudely chosen to give the host no way to pass that info on to the device. Despite our rudeness, Atapi can still be workable, so long as we give the device a way to say after the fact how many bytes it did not mean to ask to copy which way. > http://members.aol.com/plscsi/scsinotq.html > http://members.aol.com/plscsi/20020328/oddwinme.txt 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. 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. 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. 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. Clear now? Or can you verbalise why not? Curiously yours, Pat LaVarre
