This message is from the T13 list server.
[ BC [EMAIL PROTECTED] ] Hale L: > > RE: [t13] on residue - to what can we all agree > > McGrath, Jim 04/15/02 08:25PM ... > Hale Landis 04/17/02 10:05AM > Yes, absolutely correct. Helpful, thank you. I think we progress: in Hale's last post, now we have Jim & Hale in clear & full & __written__ agreement. Here I present a carefully interleaved review of the last statements we have from Jim, Hale, and Pat. To my surprise, I see now Jim has as yet ducked all discussion of AtapiPio, and talked only about features Dma common to Ata and Atapi both. But I'm writing this post more to ask Hale to tell us specifically where Pat's paraphrase of Jim is inaccurate. If Hale sees no inaccuracy, then we know Hale agrees with Pat just as fully as Hale agrees with Jim, by the transitivity of agreeing over what English means. If Hale can identify any specific inaccuracies, then by assuming Jim is right we know we have nailed specifically how Hale or Pat is misunderstanding Jim. > > RE: [t13] on residue - to what can we all agree > > McGrath, Jim 04/15/02 08:25PM ... > Re: [t13] on residue - Jim M when D < H > Pat LaVarre 04/16/02 11:28AM RE: [t13] on residue - to what can we all agree Hale Landis 04/17/02 10:05AM )) Here you see Pat's quoting conventions for this email, including this further commentary from Pat. > > the host ... can only avoid [cracking the CDB] 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. > But let us suppose an Atapi host > rudely does ask to copy more bytes, > at a time when the Atapi device & host > do agree over which way to copy bytes. > > 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 > When copying data Out, the device can ask to stop the copy. > > 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 [for example] > > 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. > Yes when copying data Out, the device can ask to stop the copy. Again, I'll say YES but with the additional comment that is especially TRUE in DMA: For a write command the host SHALL program its DMA engine to transfer exactly the number of bytes the CDB indicates, perhaps plus a pad byte. If the host fails to do this then you have either a hang condition (host has less data) or a command that can end in an indeterminate condition (host sends to more data). )) Again we have Pat agreeing with Hale, though in different words. From http://members.aol.com/plscsi/cdbcomplete.html#plus I quote: )) People say "residue", or "residual count", to mean the count of bytes the host asked to copy that the device did not agree to copy ... )) Positive residue can be harmless if reported. Only the Scsi host can know if it meant to be imprecise in forecasting how many bytes to copy. )) Imprecision has small benefits. Some systems can only copy N * 8 bytes. To copy N * 8 - 7 bytes a system like that has to copy an extra 7 pad bytes. A host can allow for this by always allocating an extra few bytes. We recommend allocating an extra physical page (often 4KiB). )) Imprecision has large costs. Some systems hang if residue is positive. Others dramatically slow down. As I as yesterday, when defining U-DMA T13 made this an interdiminate condition because T13 did NOT want to require devices to detect excess data and report an error. )) Yep. Left that one out, ouch. Pio works, Dma doesn't. AtapiPio requires the device to help the host recognise this reasonably common situation. AtapiDma has no analogous mechanism. Whoops. A host that creates this indeterminate condition is a BROKEN host. )) Microsoft is. If the de jure standard doesn't allow the de facto Microsoft standard as an option, then the de jure standard is confusingly incomplete. > > 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). > When copying data Out via UDma, the device can ask > to stop the copy at any "word" boundary, but then > the host may send another X "word"s. T13 requires > the device to ignore these "word"s. YES, I do not disagree with Jim here... His description matches what should be expected on the ATA interface. The fact that the device had to ignore data sent by the host for a write command is a data integrity issue, perhaps even a data corruption issue. A host that creates this condition gets what it deserves: a command that ends in an indeterminate state. It is a BROKEN host. )) Again we have Pat agreeing with Hale, though in different words. )) Pat says here in UDma have an issue that grows larger as the burst rate increases. Pat says the issue also grows larger as block sizes grow less determinate. )) Pat's asking for an optional, utterly backwards compatible, FIX for this specific issue. )) Pat's asking, let the device report X. Why not? > > 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. > When copying data In, the device can ask to stop the copy. > > 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 > Yes when copying data In, the device can ask to stop the copy. > > 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 wouldsee the device trying to terminate > > the command. > When copying data via SwDma, > the device can ask to stop the copy at any "word" boundary. > > When copying data via MwDma, T13 allows the device asking > to stop the copy to be slow. This means our rude host ends > up copying X extra "word"s, where X may be 0 or 1. In > practice, people don't make many devices this slow. YES, but again the host must be prepared to receive all the data the device will send for the read command. )) Again we have Pat agreeing with Hale, though in different words. )) From http://members.aol.com/plscsi/cdbcomplete.html#plus I quote: )) No cases but the thin diagonal and the positive residue cases Should ever occur. The device and the host should at least agree over the max count of bytes to copy which way. Meanwhile, back in the real world ... Failing to accept all that data could result in a hang condition. )) Again we have Pat agreeing with Hale, though in different words. )) From http://members.aol.com/plscsi/cdbcomplete.html#plus I quote: )) Imprecision has large costs. Some systems hang if residue is positive. Others dramatically slow down. Yes, the device is allow to send less data for read commands. Counting the number of bytes the device sent to the host is a host problem. )) I'll return to this last. > > 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. > When copying data In via UDma, > the device can ask to stop the copy > at any "word" boundary. Here UDma is as precise > as SwDma and MwDma in practice, > and better than MwDma on paper. Yes, but if the host DMA engine is not programmed to accept at least the maximum number bytes for the read command then we have a possible hang condition. Again this is a data integrity issue. Again this could be a data corruption issue. Again this is a broken host. )) Again we have Pat agreeing with Hale, though in different words. )) From http://members.aol.com/plscsi/cdbcomplete.html#plus I quote: )) Imprecision has large costs. Some systems hang if residue is positive. Others dramatically slow down. > > [ no comment yet from Jim ] > When copying data via Pio, > the device can ask to stop > the copy at any "byte" boundary. Counting the number of bytes the device sent to the host is a host problem. )) T13 _requires_ an AtapiPio to help the transport-level driver of the host solve this problem. T13 defines no analogous mechanism for AtapiPio. From an old AtapiPio specification, I quote: )) Revision 18 )) 19 August 1998 )) ... )) Ata/Atapi 4 ... )) 8.21 PACKET ... A0h ... )) 8.21.5 Normal outputs ... )) 8.21.5.2 Data transmission ... )) ... )) 5) if the byte count is odd, the last valid byte transferred is )) on DD[7:0] and the data on DD[15:8] is a pad byte of )) undefined vaue; )) 6) if the last transfer of a command has a pad byte, the byte )) count shall be odd. )) ... )) I/O - Shall be cleared to zero if the transfer is to the device. )) Shall be set to one if the transfer is to the host. With all this context carefully copied into place, does my English grow any less muddy? ANY less muddy? Anyone want to bother to comment on the T13 specification I end by quoting? If it doesn't mean T13 requires a device to tell the host which way the device is copying data, if it doesn't mean T13 requires a device to count the pad bytes for the host, what does it mean? Pat LaVarre
