This message is from the T13 list server.
After I read Hale's message I realized that your case may be one in which you are not sure if the DMA stopped for an error or another reason. Of course once a DMA burst is over you can always read STATUS yourself. Also, if interrupts are enabled you will get the interrupt for the end of the command. In either case you will not stall, but will see that the command in question ended on an error and proceed from there. Jim -----Original Message----- From: Pat LaVarre [mailto:[EMAIL PROTECTED]] Sent: Monday, December 17, 2001 8:54 AM To: [EMAIL PROTECTED] Subject: RE: [t13] a PIO example This message is from the T13 list server. > "Mcgrath, Jim" <[EMAIL PROTECTED]> 12/14/01 05:37PM > ... As ... I keep on pointing out, > you're trying ... something that just is not needed. Again I find your remarks consistently helpful, thank you again for your patience. Maybe I've been having trouble distinguishing a claim that noone should care from a claim that people can't reproduce my results. Please feel free to include technically redundant language to help me make this distinction. > If the host is sending you more bytes > than you should have for the command, > then it is a bad host (as Hale would say). I wonder if this English is slippery in exactly the right spot? Let's try the example Scsi Cdb of x 2A 0 00:00:00:00 0 00:12 0 i.e. a write of the x12 blocks at Lba 0. If, out of band, the host and device have mutually agreed that each block contains x200 bytes, then yes only a Bad Host will move out more than x12 * x200 = x2400 bytes. But now let's suppose the Bad Media refuses to let the device move more than 3 blocks. And let's suppose our device, in Pio/SwDmw/MwDma modes, accordingly moves just 4 * x200 = x800 bytes and then stops the transfer. If we change to use merely standard Atapi UDma, now we see a difference. Rather than x800 of x2400 bytes moving out, when connected at UDma33, we see as many as x804 bytes move out. To eliminate this difference, a device (here the receiver of clocks) can try to pause at block boundaries ... but unless the host cooperates, for example with a turnaround delay at block boundaries, in UDma more than x800 bytes will move out. Here we see Change. And Change Is Bad, for interoperability - for plug 'n play beyond the latest Windows, beyond the installed base of Windows, out into the wild world of the Windows to come and the things that aren't Windows. > "Mcgrath, Jim" <[EMAIL PROTECTED]> 12/14/01 05:37PM > Since our products don't suffer any of these problems, > I'll leave it to others to carry it on from there. Over Christmas I hope to work on vanity-publishing precisely how to demo how these issues arise with more and less direct Windows connections to an Ata hard drives. I agree an adequate workaround for not counting bytes accurately is to accompany any inaccurate count with an ERR and to agree out-of-band that the count of data moved with ERR doesn't matter. Pat LaVarre Subscribe/Unsubscribe instructions can be found at www.t13.org. Subscribe/Unsubscribe instructions can be found at www.t13.org.
