This message is from the T13 list server.
Hale Landis wrote:
I don't think this is a spec issue. It could be an nIEN=1 problem with a
SATA host controller or SATA device (see my other email).
libata (Linux SATA driver) uses nIEN=1 for PIO data xfer on all
non-FIS-based controllers.
I definitely see multiple problems, on multiple SATA controllers, due to
this. I've learned that if you bang these "SATA emulating PATA"
controllers too hard -- the ATA shadow registers are simulated, after
all -- you can sometimes catch them in edge transitions between states.
The OS drivers really do need to treat PATA and SATA controllers a bit
differently. Soon, I hope to change libata to be interrupt-driven on
the "SATA emulating PATA" set of controllers... latency and context
switches will increase, but interrupt-driven behavior is far more like a
native SATA FIS, which reduces problems.
The best solution for hardware vendors is to stop this
SATA-pretends-its-PATA emulation nonsense, and produce a FIS-based
controller like the open AHCI standard (from Intel), or Silicon Image's
3124. Looking at the road maps mobo makers have made public, it does
look like FIS-based controllers will be the future. Thankfully.
Jeff
