This message is from the T13 list server.
> Earlier I mentioned that the sender could, > on the last DMA burst, sent out more data > than the command indicated > - but that is a broken sender, because ... > ... To my knowledge no device > ever does that as sender. I'll leave it to others > to comment on actual host sender behavior, > but I don't know of any cases > where the host would be broken in this manner either. Good to hear, thank you > People may be confusing this > with the case of the host a receiver > - in this case it is not uncommon > for the host software > to not program the DMA controller > with the command size, > counting on the device (as sender) > to always stop at the appropriate point. I hear such confusion is Often merited? I hear hosts often so badly lose track of the count of bytes they mean to move that they try moving whole physical pages - often 4KiB i.e. 8 of the 0.5KiB blocks. Untrue? True only when moving non-block data? True only of moving data in like a read, never of moving data out like a write? > This works as long as the device works, > but is clearly not good defensive programming. Classic understatement, thank you. > ... not uncommon for the host software > to not program the DMA controller with the command size, I'd love to hear such confusion is less common than reported. Quoting from a past post in this series: "1. If somehow magically the host & the device can establish that the sender of the data will never be so rude as to clock garbage, then both the host & the device can count byte pairs clocked. Then they both can know how many byte pairs the receiver moved." > Is this line of inquiry for understanding, > or because a real problem has been encountered? Yes both. Details appear in an earlier, separate post titled "[t13] UDma count well not - real issue??". > I've never seen a problem like this > with any shipping implementation of UDMA > - and it has been shipping for years now. Myself, I don't know of shipping Usb2/AtapiUDma bridges that successfully transport anything difficult. I hear block read/write works. I hear the Wintel flavours of op x12 Inquiry and op x25 Read Capacity work. I haven't heard of anything much beyond that working well ... I've heard specific reports of ops x3E/3F Read/Write Long, corresponding to "obsolete" Ata ops x23/33, not working well ... ... I haven't yet seen a bridge sample appear here that passes a simple-minded test of random terminations within a transfer (with our Pio history, we speak of this as "arbitrary DRQ") ... if anyone knows different, please do reply to tell me offline or online! Thanks in advance. Pat LaVarre Subscribe/Unsubscribe instructions can be found at www.t13.org.
