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 ++
