This message is from the T13 list server.
Pat, What bus trace? The data you posted earlier on what was in the host buffers after the commands? Before Hale burns you down on this, that's not an (ATA) bus trace. Once again, for UDMA I've never seen the device give the host an illegal number of words for a command. And for the host to device, this only happens when host software refuses to program a transfer count to begin with (as discussed earlier). Jim -----Original Message----- From: Pat LaVarre [mailto:[EMAIL PROTECTED]] Sent: Monday, April 15, 2002 3:22 PM To: [EMAIL PROTECTED] Subject: [t13] on residue - Hale on not cracking the Cdb This message is from the T13 list server. [ BC [EMAIL PROTECTED] ] >> Hale: Why do you need all 16-bits of the Byte Count registers to report a >residue value that can only be 0 or 1? >Pat: In UDma 2 this value is sometimes as high as 5. I know at length here before >I've failed to explain clearly why, but it's a fact. That is because it isn't a fact HELLO. It is on a BUS TRACE. Seen not only by my eyes but by eyes across the Usa and abroad. It is a fact. The issue can only be that I'm not explaining myself clearly. Trust me, I'm trying. > The command, be it an ATA hard disk command or an ATAPI/SCSI CDB, absolutely and without question determines the data direction and the amount of data. A host must have every expection that the device will properly execute the command or indicate error status. Yes. > This is one of the most basic concepts of computer I/O? Yes. > Why are we talking about this here? Because You're not listening? Certainly you're not hearing me. (((Granted, I'm not hearing you well enough to echo back to you what you say in a form you can swallow, but like you I am trying as hard as I can to listen. I haven't phoned you today only because I missed the end-of-business deadline you shared offline. I have acquired the AAA battery needed to make my pager work. You do have my phone number.))) Yes the "command" must indicate how many bytes to copy which way, however that is encoded, yes certainly. Your error here is to think the Cdb is the whole "command". Viewed in the light of the most basic precepts of computer i/o, it isn't the WHOLE command. To a classically trained programmer, what's bizarre about many Scsi-over-whatever protocols, and T13 Atapi protocol in particular, is that these protocols do not include in the "command" a plain indication of how many bytes to copy which way. As a device, all you get is the Cdb, in place of what you need. So you're stuck patching up life afterwards. Yea, sure, on paper you can say that what you have must be what you need. Well, it isn't. Welcome to the real world. Ask yourself. Why is the common core of Scsi Api's across platforms: int ...(void const * cdb, int cdbLength, void * data, int dataLength, boolean pleaseIn) That common core is not just: void const * cdb, void * data That common core does not just return pass/fail, but also positive residue. Why is this? Because "everyone knows" the Cdb does not plainly indicate how many bytes to copy which way. Take the now familiar example of Cdb -x 12 0 0 0 05 0. In unambiguous English, Ansi T10 claims this Cdb means copy between 0 and 5 bytes In. But the trivially repeatable trace http://members.aol.com/plscsi/20020328/oddwinme.txt shows that Windows often decides instead to copy In 8 or 6 bytes, not just 5. Hello, EIGHT. If as a host you were to claim that this Cdb copied In only 5 bytes you would arrange for the device to ask to copy MORE bytes than the host asks. You'll hang if you're lucky, crash if you're not. I didn't construct this trace artificially. I took the two Atapi devices I had nearest at hand, devices I use in office work, and I sent an Inquiry to sample the additionalLength at offset 4 that by T10 tells me whether the device makes more bytes available or not. This is a simple basic elemental start-of-life thing to do ... it's one of the first things I tried on reading the Scsi spec in 1994 ... and in Atapi it doesn't work. (In eight-bit parallel Scsi, it worked fine.) All that pretty fiction published by Ansi T10 has no place in something as real and essential as an Ansi T13 specification. Ansi T13 AtapiPio tells a device how to ask to copy an arbitrary count of bytes either way - no matter what how many bytes Ansi T10 thinks the device should have asked to copy whichever way. T13 AtapiDma should be equally arbitrary, equally free of T10 entanglement. x4402 Pat LaVarre [EMAIL PROTECTED] http://members.aol.com/plscsi/ >>> Re: [t13] Proposal to 'fix' ATAPI DMA >>> Hale Landis 04/15/02 02:41PM >>> This message is from the T13 list server. On Mon, 15 Apr 2002 14:16:00 -0600, Pat LaVarre wrote: >This message is from the T13 list server. >> Hale: Why do you need all 16-bits of the Byte Count registers to report a >residue value that can only be 0 or 1? >Pat: In UDma 2 this value is sometimes as high as 5. I know at length here before >I've failed to explain clearly why, but it's a fact. That is because it isn't a fact. Here again we are back to what I can only describe as a failure to understand how ATA/ATAPI data transfers are performed and especially how UltraDMA transfers are performed. I have posted several examples in an attempt to clear up this misconception. Apparently you keep ignoring them because you think they are not "real world" enough, yet they demostrate many of the very basic issues that we keeping commenting on here without resolution. >In practice my fix for getting direction straight was (d) to write x1F3 with >x80 In or x00 Out before o x1F7 xA0 Packet, to let the device see the >direction the host wanted. This has never been necessary to my knowledge in 10+ years of ATA or 8+ years of ATAPI. Why now? The direction of data movement and the amount of data moved by a command is not open for negotiation. The command, be it an ATA hard disk command or an ATAPI/SCSI CDB, absolutely and without question determines the data direction and the amount of data. A host must have every expection that the device will properly execute the command or indicate error status. Why are we talking about this here? This is one of the most basic concepts of computer I/O? *** Hale Landis *** www.ata-atapi.com ***
