This message is from the T13 list server.
> "Eschmann, Michael K" <[EMAIL PROTECTED]> > 12/14/01 04:28PM > under a variety of conditions), > the interrupt status is ok, > but the host doesn't know the exact transfer count. Then you do see what I see? When an Ide Dma receiver of clocks shuts the transfer down before the Ide Sender of clocks would have shut the transfer down, the host can't know how many bytes the device would have agreed to transfer, if only the device had as much control as Pio offers it. > no host should be attempting a mind-...game > by trying to set the drive up to write more to the [media] > than the host is really ready to do. > ... > Some folks have toyed with the idea of > sending the drive a "big" transfer, > then only setting up PRD's that represent a portion of it; > I suggest against doing this. Can you elaborate? Streaming more data per command than fits in physical memory is exactly what any bridge does if the people who buy the bridge are too cheap to pay for enough buffer to hold all the data of any command. (I think just enough buffer is 32MiB for 48-bit Ata at 0.5KiB/block: enough to be uncommon in devices.) Back when the host is a PC, isn't a stream larger than physical memory exactly what we want to, say, erase a whole disk, at max speed? Once upon a time Ata even included the command xE9 WriteSame to transfer the bytes of a block only once but then use them to erase a long series of Lba's? > When a drive is just not going to send any more > (ATAPI is the biggest offender, > with Mode Sense and Inquiry's being a big target, > as well as some data transfers ... Yes. > Some devices will terminate requests early, > but this is either flow control, > or completion when the drive interrupts. > When a drive completes in error, it tells us > (unless there is some "secret society" thing I don't know of) > via the status register of the error. This happens often enough to have inspired a tradition of checking for this in qualification tests ... I don't myself know of a shipping device that without error cuts block read/write short of its interpretation of the command block ... But I have seen the command block arrive corrupted. With the right kind of corruption, the host can wrongly think it saw a device cut a transfer short without error. > under a variety of conditions), > the interrupt status is ok, > but the host doesn't know the exact transfer count. > Either way, we can deal with the problem > in higher-level software that parses the data stream > to get the return data (in the Mode Sense and Inquiry cases). Ouch. Because some kinds of data includes enough redundancy to complain more or less gently of wrong byte counts, we shouldn't care that in AtapiDma we can't count bytes accurately? Pat LaVarre Subscribe/Unsubscribe instructions can be found at www.t13.org.
