This message is from the T13 list server.
Pat, As a follow up to my previous email, I think the issue here is that Hale is saying that the host software must crack the CDB to make sure it knows what and how much is transferred. You contend that the host software can avoid that. Yes and no. It can only avoid that if it relies on the device to crack the CDB (afterall, someone has to do it). And then certain other behaviors you have cited as undesirable MUST follow. For instance, on writes the host does not know how to program the host DMA controller. It has a buffer, and perhaps a length, but has no idea what is in the buffer. So it will just program the host hardware to start at the buffer starting address and to transfer everything in the buffer. The device did crack the CDB, so it knows that only 80% of the buffer (for example) has valid command data (the mismatch is due to the fact that the buffer was allocated in easy multiples, like powers of 2 bytes, in order to avoid memory fragmentation). So the host will transfer away. After the device receives the 80% it is due, it will try and halt the DMA transfer. But at this point the host will still be blasting away, so the up to 3 extra words that the device can receive may be received (and ignored by the device as per the ATA standard). Looking at reads is instructive. In this case you would also expect that a host that does not crack the CDB would try to overflow (i.e. overread) bytes into the host buffer. Assume that the device is cracking the CDB. In SW or MW DMA the host has to drive the DMA process, so it has to figure out how many bytes to request. In practice it would just start a DMA burst, and continue with DMA bursts until once again the device refuses to participate in a DMA burst and instead signals the end of the command. With a fast DMA, the host could overread a word on the last DMA burst before it would see the device trying to terminate the command. But this can never happen with UDMA. Here it is the device that determines the number of words to transfer - it pushes words rather than having the host pull them. When the device runs out of words, it just stops sending them - no overflow can possibly occur on the ATA bus. So how can the host buffer overflow? Probably due to a host hardware/software problem that in this case no ATA action can affect. I cannot think of a good way for the device to screw up. And a good thing too, since the host not cracking the CDB would blow up completely unless the device was reliably doing its job. Jim -----Original Message----- From: Pat LaVarre [mailto:[EMAIL PROTECTED]] Sent: Monday, April 15, 2002 4:50 AM To: [EMAIL PROTECTED] Subject: [t13] on residue - to what can we all agree This message is from the T13 list server. [ BC [EMAIL PROTECTED] ] > From: Hale Landis > Date: Sunday - April 14, 2002 4:29 PM ... > > 3 "words" clocked In across the bus > Yes, 3 words (6 bytes) were moved > on the ATA interface. ... > > ... a kind of double-buffering, > > one kind among many. > Agree. Yes, thank you. 6 bytes were clocked across the bus as 3 "word"s. On the bus between host and device, T13 Atapi protocol doesn't tell us how many bytes actually were copied into memory on either side. > an ATA/ATAPI data transfer > is a stream of data > whose length is determine > soley by the command being executed. No. (More detail below.) > I assume Win98 and WinME > know to copy 5 bytes because: ... > a) that is what the application program's > SCSI CDB requested, or ... > b) via some parameter to the OS device driver stack > the driver(s) know the application > program's I/O buffer is only 5 bytes. Neither (a) nor (b), not in the real world. The true answer is: c) Of the N * 2 bytes clocked across the bus, T13 requires any AtapiPio device to tell the host how few bytes to copy In or how many bytes the device did copy Out. An Atapi Pio device asks the host to copy the sum of x1F5:1F4 ByteCount values offered with each INTRQ where BSY DRQ C/D = 0 1 d. > What is the point here? > You are talking about > OS driver stack implementation here. Yes I am consciously choosing to talk about the de facto executable definition of Atapi known as the Microsoft Atapi driver stacks. The de jure definition that we of T13 publish does influence Microsoft's quality of implementation. With the change to Atapi Dma from Pio, we of T13 have precluded Microsoft from properly supporting T10 over time. > You are trying to fix a problem ... > by getting T13 to do something inapropriate, I'd say I'm asking how enhance AtapiDma to include a traditional feature that forms a part of every other Scsi-over-whatever protocol that actually just plain works, such as AtapiPio. I'm also working to publish the fact that this feature exists, since noone before me seems to have bothered. > The information you seem to want > was never in any ATA DMA > data transfer protocol (SW, MW or UDMA). Sorry about that. I wasn't paying attention. Only recently did burst rates above 17e+6 byte/s begin to matter to me. > Nothing was removed by T13 > because nothing was there to remove. Eh? Atapi Pio includes in any bus trace the count of data bytes to copy which way. Atapi Dma does not. Somebody somewhere at some time didn't copy that feature to Dma from Pio. Sometimes the lack of this feature makes Pio work where Dma does not. > > UDma ... > I think you further issue is ... I'm voting to defer the UDma discussion til we understand each other more re copying odd counts of bytes. > an ATA/ATAPI data transfer > is a stream of data > whose length is determine > soley by the command being executed. No. 1) Context matters. 2) The defining English is (and will remain) in dispute. http://members.aol.com/plscsi/20020328/oddwinme.txt shows a host and two devices all disagreeing over whether the Cdb -x 12 0 0 0 05 0 copies in 5, 6, 8, or x0E bytes. The first device asks to copy 6 bytes In: BSY DRQ C/D I/O = 0 1 D I x1F5:1F4 ByteCount = x00:06 3 "words" clocked In across the bus The second device asks to copy 5 bytes In, like T10 claims all hosts and devices should: BSY DRQ C/D I/O = 0 1 D I x1F5:1F4 ByteCount = x00:05 3 "words" clocked In across the bus See the difference in the devices? The ByteCount from the first device is 6, from the second device it is 5. The Dma trace shows no ByteCount and no C/D I/O bits. oddwinme.txt also tells us the host here enters negotiation willing to accet as many as x0E bytes copied In. Furthermore, this host allocates x10 bytes of buffer, in case Windows actually copies in a little more than permitted. (I constructed the example here to make the traces short: personally in real life I more often allocate an extra 4KiB physical page.) > > Who above the level of T13 > > cares if we're using Pio or Dma? ... > Doesn't matter. In either case, PIO or DMA, > the OS device driver stack must know ... By the above, T13 Pio lets the device tell the OS, T13 Dma does not. > ... No matter how evil I am to want to support the illusion that Windows works, am I now at least coherent? Pat LaVarre
