Hello, Russell. On Mon, Aug 24, 2015 at 11:55:01AM +0100, Russell King - ARM Linux wrote: > I've no idea how this is happening, but it appears that it's possible > to read corrupted data over an eSATA link. > > The setup is a Solid-run Cubox-i4pro connected to an external eSATA 2.5" > enclosure with a Corsair Neutron 128GB SSD. > > While the issue seems to be the generally poor quality of eSATA cables > (I have two eSATA enclosures, the other enclosure's eSATA cable > interferes with a Logitech wireless receiver - I've had to wrap the > cable in aluminium foil.) However, it shouldn't be possible to > successfully read faulty data in that condition - and this is what I > find most worrying. > > What I've noticed is that at boot, the the SSD is sometimes properly > detected, other times it isn't: ... > ata1.00: ATA-8: Corsair Neutron SSD, M311, max UDMA/133 > ata1.00: 250069680 sectors, multi 1: LBA48 NCQ (depth 31/32) ... > ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) > ata1.00: ATA-8: , , max UDMA/133 > ata1.00: 250069680 sectors, multi 1: LBA48 ... It'd be interesting to see the ID data being returned. "libata.force=dump_id" should do it but bit flips during transfer or outright incorrect DMA won't lead to the above result. Looks more like the firmware on the drive side getting terminally confused. ... > How does SATA ensure command and data integrity over the link? I'd > assume that there's a CRC present on the data, like UDMA on PATA. How > are CRC errors supposed to be reported? Is it possible that ahci_imx > and other layers are not properly checking for CRC errors? IIRC, the 8/10b encoding does running parity and there's per-frame (packet) CRC too. Link and frame integrity is always checked by hardware. Reporting and handling can be different depending on which party detects the error tho. > Any ideas what to look at? > > Anyone got any suggestions on where to get a good quality, but not > stupidly expensive eSATA cable from? > > I'm waiting for it to happen again, and I'll dump out more of the drive's > "contents" when the cable is bad. If it is the drive's firmware, it > should contain the manufacturer name/model somewhere in the image. I highly doubt this is something happening on the controller / link side. Looks like a messed up drive firmware to me. Thanks. -- tejun -- 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
