On 9/28/06, Jeff Garzik <jgarzik@xxxxxxxxx> wrote:
Given the minimal amount of problem reports, I'd rather hold off and
collect data. What devices are affected? Is it complaining because
it's in the middle of a reset when SRST is received? Is it just one
model of one device? Is this definitely reproducible on all SATA
controllers? etc.
Too many unknowns right now...
Jeff
I agree 100%. The specification states in section 13.1.1 of the 2.5
SATA specification covering Parallel ATA Emulation for Software Reset:
"Although host software is required to toggle the SRST bit no faster
than 5 us, devices may not rely on the inter-arrival time of received
Register – Host to Device FISes also meeting this timing. Because of
flow control, frame handshaking, and other protocol interlocks,
devices may effectively receive the resulting Register – Device to
Host FISes back-to-back."
Is it possible that the "set" of SRST hasn't actually occurred on the
bus when the "clear" of SRST is issued to the controller? If that's
the case, then the right answer should be using a mechanism to confirm
transmission of the HTD register FIS before generating the clear for
SRST. I'm guessing this is basically looking for R_OK from the
device.
Drive firmware has to cope with these latencies (as well as
collisions, especially in NCQ), so surely there's a safe way to do it
in the various controllers.
--eric
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
