Thread (2 messages) 2 messages, 2 authors, 2015-08-24

ahci_imx: can read corrupted data successfully

From: tj@kernel.org (Tejun Heo)
Date: 2015-08-24 19:24:53
Also in: linux-ide

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help