This message is from the T13 list server.
Pat, I think the problem here is that you keep on saying that when using PIO the ATAPI interface is transferring an odd number of bytes under certain circumstances. Hale, Harlan, and myself keep repeating that this is physically impossible at the interface level covered by ATA/ATAPI. If you put a logic analyzer on the ATA bus, and then look at the result, you always see an even number of bytes transferred - just looking at that level, there is simply no such thing as an odd byte transfer. Note that this is very unlike PCI or various CPU buses, where there are often 8 bit transfer modes still available (in PCI this is done via the byte lane signals). Just accept that for the moment. I think your concern is at the level of things like DMA controllers, or interfaces between various levels of the software stack (as Hale points out). In general people on this list are not experts in these areas, since those interfaces are not covered by the ATA/ATAPI standards (i.e. the things T13 works on). As I mentioned in the last email, I certainly understand that SOMETHING in the software stack ultimately decides that that last byte the device transferred in your example should be dropped or ignored. But as Hale says, that is not covered by ATA/ATAPI - instead it is covered by the higher levels of the driver stacks in the system. I assume that the agent that does this knows the command issued (otherwise it could not know the transfer length provided), but otherwise I know fairly little about the details of how this works. All we know is that it does work today. Perhaps someone in BIOS or driver land can shed some light on the details of this issue. But it's my thinking that the byte transfer values in the command registers supplied by the drive (which are present in PIO and not in DMA) have nothing to do with any of this. I could be wrong, but it seems clear to me that the primary reason for those values is to allow the host, which paces transfers for DATA IN PIO operations, to know how many bytes the device wishes to send (not how many the host wants to get) per DRQ. In UDMA this is simply not needed (the device paces the data transfer itself). It has nothing to do with the odd byte residue at the end of the command. For that higher level host software is parsing the returned data and applying the initial allocation length value to the entire data stream. The key thing here is that you cannot show it is a problem just by citing that PIO and UDMA behave differently at the ATAPI interface level, since logically they SHOULD behave differently (i.e. you keep on seeing a problem, and we keep on seeing a solution). It's only by bringing in data from other interface levels in the software stack that a problem can be identified. I'm not seeing a problem, but if one exists the issue is that I'm not knowledgeable enough about those layers of software to see the problem. That's where you can help us out. Just like we've been citing the ATA/ATAPI standards and the like, we need you to do something similar for the layer of software where you are looking. Otherwise we literally don't know what you are talking about. Jim Jim -----Original Message----- From: Pat LaVarre [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 03, 2002 3:08 PM To: [EMAIL PROTECTED] Subject: RE: [t13] AtapiDma byte counts how imprecise? This message is from the T13 list server. > > One byte count that matters > > is the count of bytes written or read that the OS reports to the app. > > ... > > Another byte count that matters > > is the count of bytes actually written or read. > > ... > > iocb x 12 0 0 0 FF 0 /i x1000 > > > > Now suppose the device under test > > makes x91 bytes of Inquiry data available. > > With an AtapiPio device we see the host copies in x91 bytes. > > With an AtapiDma device we see the host copies in x92 bytes. > "Mcgrath, Jim" <[EMAIL PROTECTED]> 01/03/02 02:04PM > Your latest covers the same ground we have already covered before. > ... this is incorrect. At the ATA interface level > you always see 92 bytes, whether it is PIO or DMA. > It is up to something else on the host If we can't agree something as plainly broken as this is a problem ... ... I give up. I don't know how to make a more clear demo that changing from AtapiPio to AtapiDma is not a transparent change. Byte counts moved and reported are the very stuff of which plug 'n play failures are made. I don't see how this can be in dispute. Does everyone out there really think we don't care precisely how many bytes the host copies per command? Really??? > Basically, can you provide data that shows an actual problem here? I thought I had, repeatedly in many variations, sorry. Thanks for reading and for trying so long to talk. Curious that we can so persistently fail to communicate. Pat LaVarre Subscribe/Unsubscribe instructions can be found at www.t13.org. Subscribe/Unsubscribe instructions can be found at www.t13.org.
