This message is from the T13 list server.
Pat, To the nub of this issue: > I hear you saying it's not a T13 problem if in the new Dma trace the host > copies In 6 bytes whereas in the similar old Pio trace the host copies In 5 bytes. > I'm saying that Pio works and Dma doesn't is a T13 problem. Who above he level > of T13 cares if we're using Pio or Dma? The problem here is that the number of physically bytes copied across the ATA interface (which is the only thing T13 can control) is always 6, never 5. How can the host conclude that the 6th byte is a pad? You contend that it does this by counting bytes via reading the registers presented by the device on each DRQ triggered transfer. Note that this exact mechanism cannot be replicated anyway in DMA, since the host software would not read it until the end of the command. But some new mechanism could be derived. All of this is transport layer information. The problem I think Hale is having is that the register values in ATAPIO mode are not being generated out of thin air. The device is "cracking the CDB" and understands how many bytes can be transferred by looking at command level information. The question is why isn't the host software, which has access to the same CDB information (afterall, it sent it originally) also privy to the same value? In which case it can take the 6 bytes transferred, discard the pad, and be right regardless of ATAPIO or ATADMA. I think this is exactly what host drivers using DMA in this case are doing (otherwise they would never work). So Hale's issue is why is this an ATA problem? Is not it really a problem of people writing bad software drivers? Another way to look at this is why does ATADMA work sometimes and not at other times (assuming that is correct)? Is it the driver used? This is important precisely because you CANNOT replicate exactly the same protocol for PIO and DMA. DMA has no provision to allow controlled register access under PIO to read the byte count values until the end of the command. That means that the maximum data transfer length for a embedded SCSI command would be 64K bytes. Yes, a new protocol could be devised that would handle this problem. But if the original problem was due to host software not using the CDB information correctly today, then why would we expect them to use the new protocol correctly tomorrow? It's these uncertainties in whether any such solution at the T13 level would actually work (and if so how soon) that are at the hear of Hale's concerns. I think his attitude is that if some host software is not working, then it should be fixed, not the ATA protocol. Jim PS Hale, forgive me please for putting words into your mouth.... -----Original Message----- From: Pat LaVarre [mailto:[EMAIL PROTECTED]] Sent: Sunday, April 14, 2002 2:03 PM To: [EMAIL PROTECTED] Subject: Re: [t13] on residue - to what can we all agree This message is from the T13 list server. Hale L: Ouch, sorry again, I keep wasting your time, you & who knows how many other folk here too. I'm caught fast in that programmer's illusion of "I just fixed the last bug". I keep thinking we almost understand each other. Friday, an engineer from .co.jp wrote me offline to confirm understanding offline - there I was entirely understood. And Jim & I seem to be connecting - have you read that traffic too? And Sbp2 folk & I seem to be connecting here. We're talking about Scsi-over-whatever that just plain works vs. Scsi-over-whatever that only mostly works. We are by definition talking about the less normal situations. Let me try one more time to connect with you over your Dma examples. Can we agree traces such as the following two are common? Dma: 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 If you don't like these examples, can you tell me what's wrong? What have I not reproduced from your examples that matters? I read your examples to be saying that in both of these traces we see: 3 "words" clocked In across the bus I agree. Of course. Goes without saying. The bus is two bytes wide. Yes. I hear you saying that x86 folk copy In 3 "word"s only via 3 REP's of INSW. I disagree. I see people using 2 REP's of INSW followed by an IN AX followed by a MOV AL. I see 5 bytes copied In, not 6, in Win98 & WinMe. I say this is a kind of double-buffering, one kind among many. I hear you saying it's not a T13 problem if in the new Dma trace the host copies In 6 bytes whereas in the similar old Pio trace the host copies In 5 bytes. I'm saying that Pio works and Dma doesn't is a T13 problem. Who above he level of T13 cares if we're using Pio or Dma? It is the BSY DRQ C/D I/O ByteCount info that tells the host to copy In just 5 bytes. T13, me included, we left I/O and ByteCount out of Atapi Dma, whoops. Sure you're free to disagree. But are you telling me I am incoherent? Can you not see my point of view? T13 used to pass info across the bus that it passes across the bus no longer. Me & friends, we were using that info. Then 17e+6 byte/s began to feel constricting. Then I noticed T13 had deleted that info. Now here I am. Am I any clearer yet? Yes I am saying UDma has a further issue past that, yes I hear you say no, but if we can I'd like to defer assessing my UDma claim until we get consensus on at least how broken Atapi Dma is as a Scsi-over-whatever mechanism for copying odd counts of bytes. My offer to connect by phone & pager remains open. Pat LaVarre
