This message is from the T13 list server.
On Mon, 28 Jan 2002 01:52:58 -0700, Pat LaVarre wrote: >This message is from the T13 list server. >A less clearly intuitive example is the extreme of UDma Data >Out, where a host can inadvertently overestimate the count of >bytes a device agrees to move by 2 * X + 1, where X rises with >burst rate. Pat please confirm that you understand these X "extra bytes" are present ONLY AT THE END OF THE LAST DMA DATA BURST FOR THE COMMAND. However... This is a BROKEN HOST. For example, if the host has prepared an "output" CDB that should move N bytes to the device but prepares a data buffer of M bytes where M>N then the host is confused and broken. What does the host think will happen to the bytes between N amd M? This is an example of a very bad data integrity problem! BAD HOST... BROKEN HOST! >I don't mean to be saying we should give the device new freedom >to disregard quietly a host's request to move N bytes. That would certainly be a gross violation of the SCSI command definition and execution protocols! >I'm trying to say instead we should let the device report if it >moved N bytes or something else, so that the host can know to >freak out when the device unexpectedly moved something else. No... This is not a device problem. This is a host side DMA engine problem. The solution is that we need (Hello Intel are you paying attention here?) ATA/ATAPI host adapters that report: a) for output commands the number of bytes (or words) that were sent to the devce (not the number fetched from system memory), and b) for input commands the number of bytes (or words) that were stored into system memory (not the number of bytes that came across the ATA interface). >I'm asking for Atapi UDma to count bytes moved as precisely as I >know Atapi Pio does ... as precisely as now I see Ata 0.5KiB >block read/rite does. But Pat there is no problem here... Assuming the same CDB and no other "mode changes" in the device, a command transfers exactly the same number of bytes in PIO as it does in DMA. U-DMA doesn't magically add "extra" bytes. The problem is NOT the "extra" bytes you keep talking about at the end of each U-DMA data burst. Those "extra" bytes are normal valid data bytes as requested by the current command. The only time there are "extra" bytes that are "discarded" are at the end of the last DMA data burst for the command. In this case there could be a pad byte that is unwanted/discarded. Or in the case of a BROKEN HOST there could be extra bytes that the host is failing to process correctly... BAD HOST... BROKEN HOST. Pat: Every example you have given, where you claim there are "extra" data bytes, are examples of a BROKEN HOST. *** Hale Landis *** www.ata-atapi.com *** Subscribe/Unsubscribe instructions can be found at www.t13.org.
