This message is from the T13 list server.
[ BC [EMAIL PROTECTED] ] > > http://members.aol.com/plscsi/20020328/oddwinme.txt ... > From: McGrath, Jim > Date: Saturday - April 13, 2002 9:39 PM ... > your traces, Where is it being traced? > ... buffers used in the host ... I suspect Yes, thank you for looking, sorry I misled you. By an "annotated soft bus trace" I meant a trace taken "in system" by a host, not a trace taken by a logic analyser plugged into a disassembled host. For the three test cases here, sending down precisely the same x 12 0 0 0 05 0 Cdb in fact copied In 8, 6, and 5 bytes of data. I'm claiming a logic analyser would have shown: Dma: 3 "words" clocked In across the bus Pio: BSY DRQ C/D I/O = 0 1 D I x1F5:1F4 ByteCount = x00:06 3 "words" clocked In across the bus Pio: BSY DRQ C/D I/O = 0 1 D I x1F5:1F4 ByteCount = x00:05 3 "words" clocked In across the bus In order to understand each other here, I think for the sake of discussion we can accept my claim of what the logic analyser would have said - please tell me if you disagree? > ... deeply rooted in the entire set of protocols. Yes. > ATA only focuses on what in on the bus, > not what's in the buffer. Yes. > 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. Not in real life. T13 actually does directly influence how many bytes actual host software copies which way. Of the 3 "word"s that always clock across the bus, Microsoft Win98 & WinMe copies 5 bytes as T10 specifies, rather than 8 o 6, only in AtapiPio. Clearly here Pio works and Dma doesn't. Why? Because in AtapiPio T13 gives the device a way to tell the host that the last byte was not wanted. That is, Ansi AtapiPio already includes an analogue for what in Scsi was the largely unused option of IgnoreWideResidue. Ansi AtapiDma, by contrast, gives the device no standard way to report that X * 2 + 1 unwanted bytes did clock across the bus. > "rounding up > to the nearest 4 or 8 bytes," > I expect ... the host software/PCI hardware Me too. > I'm not at all confused > about the PACKET command > not specifying the number of bytes to transfer. Consensus! Thank you. > I'm totally confused > when you talk about the number of bytes > being transferred for a command > being a negotiated quantity. In the example here, the host consistently asks to copy x10 bytes In. The devices ask to copy in 3 Dma "word"s, 6 Pio bytes, and 5 Pio bytes. Here always the host and device agree which way to copy bytes, never do they agree over how many bytes to copy. We actually see 8, 6, and 5 bytes copied In. Why? Because the host agreed to copy in the 3 Dma "word"s, the 6 Pio bytes, the 5 Pio bytes, and then added 2, 0, and 0 bytes from its own internals. This is a "negotiation". Neither the host nor the device decided in advance how many bytes to copy which way. They came together, communicated their preferences, and compromised. > negotiation Suppose the device had asked to copy In x11 bytes. The host should refuse, rather than accessing x11 bytes of memory when it only had x10 bytes allocated. In this fourth example, a maximally tolerant host would copy In x10 bytes and then reset the device. I know of shipping Atapi apps that work only on hosts that in fact are this robust. Suppose the device had asked to copy bytes Out (i.e. BSY DRQ C/D I/O = 0 1 D O rather than 0 1 D I). In this fifth example, the host should refuse. These too are "negotiation"s. > If the definitions of he SCSI commands, > .. they should be fixed. True but impractical. Noone is going to fix them. Noone can. Given that the Cdb never will say plainly how many bytes to copy which way, then more than just the Cdb should cross the bus to the device from the host. The host should tell the device plainly how many bytes to copy which way. Protocols that rudely choose to keep this info off the bus, like Atapi, thereby take up the obligation to let the device report residue accurate to the byte. This is a Dma problem because Pio works and Dma doesn't, not because it should be a Dma problem. Among programmers, she who fixes a problem owns it. > 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). Yes these devices do mostly work. But we haven't ramped to volume on Atapi UDma yet, have we? Anybody yet trying to use Atapi anywhere they can't resort to Pio for non-block transfer? In these Inquiry examples, the only thing host folk have to know to write code that works is that -x 12 0 0 0 24 0 -i x24 is the only legitimate Inquiry command. T10's claim to define other forms of Inquiry is little more than a pretty fiction. Device folk who want their stuff to just plain work, not just mostly work, over time, across platforms, in OEM qualification tests, ... those people have to work to make more of the T10 fiction real for them. We in T13 have first denied AtapiDma device folk the privilege of a plain indication of how many bytes to copy which way, and then secondly the privilege of reporting residue accurate to the byte. We have thereby denied AtapiDma device folk the privilege of supporting T10 fully. Pat LaVarre
