This message is from the T13 list server.
> this was not a problem > with the old ISA bus DMA engines... > Those maintained an accurate "residual byte count" > so a host could determine how many bytes were transferred. In that famous phone call that clued me in I think I remember I was told this actually was a problem with MwDma devices that didn't turn around DMARQ fast enough to let the host controller observe the residue accurately. Those devices changed to make this not a problem. > ... problem ... (ATAPI DMA) and > it is a problem for both today's x86/PCI hosts > and for X-to-ATAPI bridges Funny how often bridge problems resemble host problems. > ... generally only when the SCSI command > might transfer a variable number of blocks. > > ... except for a device with truely variable block sizes ... > the solutions are: > 1) use PIO, or > 2) fully understand the SCSI CDB and act accordingly. Or 3) teach the device to report the accurate residue that by definition no UDma controller can observe. Just as Jim reminded us Scsi folk chose to do via their IgnoreWideResidue message past the end of the data transfer. (1) is best whenever feasible, sure. The nice thing about (3) is you only have to do it once. This turns into a savings in dollars when you find you can reapply your same solution broadly. (3) is also nice when the block-size-of-the-moment is hard to determine, as it is with Cd-rw. If you try (2) you can never know when you're done. Somebody somewhere out there can always come up with a newly creative interpretation of the Scsi spec. You're forced to pay for reprogrammability - and then requalification every time you change something. Yeeuck. Pat LaVarre Subscribe/Unsubscribe instructions can be found at www.t13.org.
