This message is from the T13 list server.
[EMAIL PROTECTED] wrote: 1) Why was is necessary to add, in ATA-8 and not in SATA 1.x or ATA/ATAPI-7, the use of ICRC to report errors in PIO data transfer commands? If this is needed now, why was it not needed in SATA 1.x or in ATA/ATAPI-7? SATAIO should publish the proposal for this change/addition to the SATA specificaton. And SATAIO should publish the meeting minutes when this was discussed so that everyone can understand why this addition error reporting method is needed now, and why it was not previously included in SATA 1.x or ATA/ATAPI-7, and what the risks are when using older SATA hosts and devices that do not implement this new error reporting feature. <BMD> To clarify, the original request for updating the T13 material with the ICRC information specific to this did propose both ATA/8 changes AND errata material for ATA/7 - see doc e05133r0. As a matter of review and direction from T13, this proposal was updated to only make the changes in ATA/8. The review of this document was done in the June plenary meeting which has minutes associated with it. The updates are included in the latest ATA8-ACS document available from T13. This request for changes arose so that appropriate reference could be made in Serial ATA specifications assuming that ATA included the appropriate material. It was felt that this change was relevant to the ATA documentation, which could be referenced by the SATA. The appropriate reference is included in the Serial ATA Revision 2.5 Specification which is available on the SATA-IO website (http://www.sata-io.org/spec.asp). Regards, Brian Dees -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hale Landis Sent: Thursday, December 15, 2005 9:43 PM To: T13 List Server Subject: Re: [t13] SATA PIO data-out with Data FIS error This message is from the T13 list server. [EMAIL PROTECTED] wrote: > This message is from the T13 list server. > Yes, it's all a conspiracy. Get off your soapbox please. Answer the questions below and I'll be happy to go away. I don't understand why SATAIO is unable to answer basic questions about error detection and reporting. It makes me wonder what SATAIO is hidding from the public. I don't understand why you should be so defensive when someone attempts to talk about possible SATA technical issues. I would think a technical discussion of the issues would be best for everyone. > Where is the data integrity issues?? There is no cover up. What ever the reasons are, SATA has serious problems, corrupted commands and/or command parameters that have cause the wrong command to be executed by the device with no error indication or the wrong data to be read or written by the device with no error indication. > If there is a CRC error on a command FIS, it is retried. If it continues > to fail, the host obviously knows about it, nothing is 'hidden'. Then the SATA bus traces I have seen that show a corrupted command FIS received by a device with none of the retries you describe really never happens? > If a bus error occurs during data transfer, the device reports a CRC error > to the host whether it is DMA, PIO, or whatever. There is nothing in ATA/ATAPI-7 saying that the ICRC error is used by PIO data transfer commands. In ATA/ATAPI-7 ICRC is used only by DMA commands. SATAIO needs to explain how a CRC error in a PIO data transfer was detected and reported to the host before this recent change to the definition of ICRC in ATA-8. > The only issue is the > last data packet on a PIO transfer. The device cannot report the error to > the host since status goes out before the data. But, the host still knows > about it because the R_ERR is still seen by the host. Again nothing is > hidden. What if the host doesn't know about SATA devices and it doesn't know to look at the R_ERR bit? What if the host controller doesn't make the R_ERR available to the host? *** Here is the most important questions that need to be answered with respect to SATA error detection and reporting: 1) Why was is necessary to add, in ATA-8 and not in SATA 1.x or ATA/ATAPI-7, the use of ICRC to report errors in PIO data transfer commands? If this is needed now, why was it not needed in SATA 1.x or in ATA/ATAPI-7? SATAIO should publish the proposal for this change/addition to the SATA specificaton. And SATAIO should publish the meeting minutes when this was discussed so that everyone can understand why this addition error reporting method is needed now, and why it was not previously included in SATA 1.x or ATA/ATAPI-7, and what the risks are when using older SATA hosts and devices that do not implement this new error reporting feature. 2) Millions of SATA devices have been shipped that use SATA-to-PATA bridge devices. How do these SATA-to-PATA bridge devices handle corruption of command or data FIS on the SATA interface? How is an error on the SATA interface reported to the PATA interface side of the bridge device? Does the SATA side of the bridge report the error to the host or does the PATA device report the error to the host? Does any SATA-to-PATA bridge use the ICRC method of reporting an error on the SATA interface? 3) SATAIO should describe how all types of errors are detected and reported in all versions of the SATA specifications and all SATA implementations (with and without PATA/SATA bridge devices in the interface between host an device). SATAIO should describe how all types of errors are detected and reported by SATA host controllers that emulate the PATA programming interface. What SATA interface errors are not reported to a PATA host that thinks it is working with a PATA host and device hardware? *** > Unlike PATA, SATA has CRC checking on all transfers. Likewise, errors are > detected on both sides of the cable. Nothing is ever hidden. PATA does > not have this protection. Especially for PIO transfers. I would agree that SATA can offer better error detection and reporting than PATA. But millions of SATA hosts and devices have been shipped that fail to conform to the statement "errors are detected on both sides of the cable". > If there are data integrity issues with SATA, it has never, I repeat, never > been reported back to device manufacturers. This is odd, since such errors have been reported to me many times over the last 2 years. And I have been inside one manufacturer's test lab and seen SATA bus traces that show unreported data corruption of SATA packets resulting in the wrong data written to the device's media or the wrong data read from the device's media. And no, I'm not talking about data corruption caused by drive firmware errors - these are simple data corrutpion issues on the SATA interface cable. > Please discontinue your 'secret society' comments and slanderous assault on > an interface just because you personally were not invited to attend. These > types of comments belong on a Blog site, not this forum. Why do you think I care if I was or was not invited to attend the secret society meetings? I don't care, I never did care. If I had wanted to attend it seems that all I need to do was join the secret society. But that would have required me to sign away all my rights to discuss this I/O interface - not something I was willing to do. I happen to think that PATA and SATA data integrity issues are an appropriate topic to discuss on the T13 email list. Do you think data and system integrity are important topics that should be discussed? And I'm sorry, but what should we call an organization that holds its discussions in secret and under NDA and does not make the minutes of its meetings public or make most of its documents public? Why do you object to calling it a secret society? Hale -- ++ Hale Landis ++ www.ata-atapi.com ++
