This message is from the T13 list server.
> SHALL NEVER, NEVER, NEVER To go and find something, there's nothing like shipping millions of chip programmed to look for it. The bInterfaceProtocol x50 class of Usb/IdePio bridges report if devices terminate data transfer prematurely without then cleanly reporting an error by reporting dCSWDataResidue nonzero with other than bCSWStatus = x01 Failed. I've been told the Windows driver software doesn't bother to complain of this when it occurs: Microsoft prefers to pretend you're reading back what you wrote. I've been told Apple is less tolerant. Dunno about Linux. I've been told the device giving up quietly most commonly occurs when a Pio device is separately powered e.g. plugged in via Pcmcia. The power cycle reset signature looks a lot like good status, lacking only an asserted INTRQ. But the example I like best of a device giving up quietly is the example of a bridge chip that corrupted command blocks just by clearing bits of the sector count, only when assaulted by the not-de-facto-standard timing of an Wintel alternative. The Ide inner child saw nothing wrong. It transferred the count of blocks it had been asked to transfer, and reported no error. Only a host able to compare the count of bytes transferred to the count intended would correctly report that an error occurred. Such is the difference between text and reality. Pat LaVarre >>> "Evans, Mark" <[EMAIL PROTECTED]> 11/26/01 12:57PM >>> This message is from the T13 list server. Hi Keith, The ATA protocol is very straightforward. A device may only terminate a command (ANY command) if a device-detected error occurs during execution of that command (see the definition for "command completion" in clause 3.1). A DEVICE SHALL NEVER, NEVER, NEVER TERMINATE A COMMAND UNDER ANY OTHER CIRCUMSTANCES. There are only three methods described in the ATA/ATAPI-6 standard for a host to terminate a command, "...by issuing a hardware or software reset or DEVICE RESET command if implemented by the device." The protocol for each of these is described in separate clauses. These concepts are so fundamental to the ATA protocol that I don't feel there is any need to add any further description for them in the Ultra DMA clauses. If you have any additional questions about Ultra DMA burst termination, please feel free to call or send an email to me. Regards, Mark Evans Maxtor Corporation 500 McCarthy Boulevard Milpitas, CA 95035 USA Tel: 408-894-5310 FAX: 408-324-7432 -----Original Message----- From: Keith Clausen [mailto:[EMAIL PROTECTED]] Sent: Monday, November 26, 2001 10:25 AM To: [EMAIL PROTECTED] Subject: Re: [t13] Command completion of an UDMA OUT burst ... This message is from the T13 list server. Hi Mark, Think you'll find that the second question relates to my questions earlier (~month ago) - it concerns the same product indeed! I think Stephane's second query may relate to who is responsible for the command termination (rather than burst termination) - *** the extract you gave clearly states there's a difference between burst and command termination, but doesn't give detail on how command termination actually differs (if at all). The command termination protocol should also be stated. *** I think(?) it was established that the host should give the device opportunity to terminate the command, rather than assume it (the host) knows best. Of course, the device and host should agree (... but the host can send 'extra' data if it likes). If the device doesn't terminate, then the host and device disagree and the ONLY recourse is a DEVICE RESET, s/w reset or h/w reset (which is sensible - after all the host and device disagree). Not sure how realistic this scenerio is, but ... assuming the host is very eager to terminate the command - terminating the final burst when all data is sent before the device has had time to realise all data has been sent (depending on device implementation) - is it possible a device may not do a command completion (interrupt flag etc) under these circumstances and is basically waiting for the next (empty!!) burst? This sounds a little unlikely (wrong) to me, but..... K On Nov 26, 9:22am, [EMAIL PROTECTED] wrote: > Subject: RE: [t13] Command completion of an UDMA OUT burst ... > This message is from the T13 list server. > > > Hi Hale, > > What exactly is it that you think is missing? Clause 6.6.2.3 in ATA/ATAPI-6 > provides an excellent overview of Ultra DMA burst termination phase rules > (even if I do say so myself). The content of this clause has been in every > A/A standard since the introduction of Ultra DMA. This clause reads: > > 1) Either a sender or a recipient may terminate an Ultra DMA burst. > 2) Ultra DMA burst termination is not the same as command completion. If an > Ultra DMA burst termination occurs before command completion, the command > shall be completed by initiation of a new Ultra DMA burst at some later time > or aborted by the host issuing a hardware or software reset or DEVICE RESET > command if implemented by the device. > 3) An Ultra DMA burst shall be paused before a recipient requests a > termination. > 4) A host requests a termination by asserting STOP. A device acknowledges a > termination request by negating DMARQ. > 5) A device requests a termination by negating DMARQ. A host acknowledges a > termination request by asserting STOP. > 6) Once a sender requests a termination, the sender shall not change the > state of STROBE until the recipient acknowledges the request. Then, if > STROBE is not in the asserted state, the sender shall return STROBE to the > asserted state. No data shall be transferred on this transition of STROBE. > 7) A sender shall return STROBE to the asserted state whenever the sender > detects a termination request from the recipient. No data shall be > transferred nor CRC calculated on this edge of DSTROBE. > 8) Once a recipient requests a termination, the responder shall not change > DMARDY from the negated state for the remainder of an Ultra DMA burst. > 9) A recipient shall ignore a STROBE edge when DMARQ is negated or STOP is > asserted. > > If this isn't sufficient, excruciating detail on exactly what is supposed to > happen in each specific case of Ultra DMA burst termination is provided in > clauses 9.13 and 10.2.4. > > If, after reading these clauses, you have any additional questions about > Ultra DMA burst termination, please feel free to call or send an email to > me. In addition, I have found that using the "find" function in Word or > Acrobat is most helpful when looking for specific details about something > like this in these documents. > > Regards, > > Mark Evans > Maxtor Corporation > 500 McCarthy Boulevard > Milpitas, CA 95035 USA > Tel: 408-894-5310 > Cell: 408-391-7805 > FAX: 408-324-7432 > email: [EMAIL PROTECTED] > > -----Original Message----- > From: Hale Landis [mailto:[EMAIL PROTECTED]] > Sent: Monday, November 26, 2001 7:51 AM > To: T13 List Server > Subject: Re: [t13] Command completion of an UDMA OUT burst ... > > This message is from the T13 list server. > > > On Fri, 23 Nov 2001 18:36:46 +0100, Stephane Cattaneo wrote: > >I have a question regarding the completion of a burst in udma out. > >Who has to do the termination protocol ? The device or the host ? > > Here again is an example of something that is missing from the > ATA/ATAPI-x documents. I have lost count of the number of times this > question has been posted to the T13 list server. Anyone want to > attempt to provide the missing information? Anyone know where the > missing information should go in the document? > > > *** Hale Landis *** [EMAIL PROTECTED] *** > *** Niwot, CO USA *** www.ata-atapi.com *** > > > Subscribe/Unsubscribe instructions can be found at www.t13.org. > Subscribe/Unsubscribe instructions can be found at www.t13.org. > >-- End of excerpt from [EMAIL PROTECTED] -- Keith Clausen, STMicroelectronics, Mail: 1000 Aztec West, Bristol BS32 4SQ, UK Email: [EMAIL PROTECTED] Phone: +44 1454 462457 Fax: +44 1454 617910 Subscribe/Unsubscribe instructions can be found at www.t13.org. Subscribe/Unsubscribe instructions can be found at www.t13.org. Subscribe/Unsubscribe instructions can be found at www.t13.org.
