SATA issues with 3.10 kernel

Autonomous Machines Jetson & Embedded Systems Jetson TK1
1

Hi all,

Not sure where to report this issue to, however…

Using a Jetson TK1 here, and when I attempt to use a Crucial MX100 256GB SSD, the SATA driver in 3.10 does not like it at all, and claims that there isn’t enough power - even when plugging the SSD in via an external power brick.

I’ve tested the mainline u-boot and kernel with the SATA patches from Mikko Perttunen applied, and that kernel (linux-next base) works with the MX100, so it definitely seems something in the 3.10 SATA implementation is at fault.

The 3.10 kernel shows:

ubuntu@tegra-ubuntu:~$ dmesg | grep ata
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
[    0.000000] Memory policy: ECC disabled, Data cache writealloc
[    0.000000]       .data : 0xc0b30000 - 0xc0c6f57c   (1278 kB)
[    0.525974] libata version 3.00 loaded.
[    1.268793] sysedp_create_consumer: unable to create pwm-backlight, no consumer_data for pwm-backlight found
[    3.711285] tegra-sata tegra-sata.0: version 1.0
[    3.711981] tegra-sata tegra-sata.0: AHCI 0001.0301 32 slots 2 ports 3 Gbps 0x1 impl TEGRA-SATA mode
[    3.711994] tegra-sata tegra-sata.0: flags: 64bit ncq sntf pm led pio slum part sadm sds apst 
[    3.713211] scsi0 : tegra-sata
[    3.713600] scsi1 : tegra-sata
[    3.713817] ata1: SATA max UDMA/133 irq 55
[    3.713821] ata2: DUMMY
[    3.811258] sysedp_create_consumer: unable to create sdhci-tegra.3, no consumer_data for sdhci-tegra.3 found
[    3.843239] sysedp_create_consumer: unable to create sdhci-tegra.2, no consumer_data for sdhci-tegra.2 found
[    4.020262] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[    4.020619] ata1.00: supports DRM functions and may not be fully accessible
[    4.020678] ata1.00: ATA-9: Crucial_CT256MX100SSD1, MU01, max UDMA/133
[    4.020685] ata1.00: 500118192 sectors, multi 16: LBA48 NCQ (depth 31/32), AA
[    4.025350] ata1.00: supports DRM functions and may not be fully accessible
[    4.029733] ata1.00: configured for UDMA/133
[    4.795099] sysedp_create_consumer: unable to create speaker, no consumer_data for speaker found
[   34.745267] ata1.00: exception Emask 0x0 SAct 0x1 SErr 0x1990000 action 0x6 frozen
[   34.766101] ata1: SError: { PHYRdyChg 10B8B Dispar LinkSeq TrStaTrns }
[   34.784994] ata1.00: failed command: READ FPDMA QUEUED
[   34.802643] ata1.00: cmd 60/08:00:00:00:00/00:00:00:00:00/40 tag 0 ncq 4096 in
[   34.842949] ata1.00: status: { DRDY }
[   34.859590] ata1: hard resetting link
[   35.181242] ata1: SATA link down (SStatus 0 SControl 300)
[   40.199495] ata1: hard resetting link
[   40.521240] ata1: SATA link down (SStatus 0 SControl 300)
[   40.540165] ata1: limiting SATA link speed to 1.5 Gbps
[   45.539505] ata1: hard resetting link
[   45.861241] ata1: SATA link down (SStatus 0 SControl 310)
[   45.880545] ata1.00: disabled
[   45.897312] ata1.00: device reported invalid CHS sector 0
[   45.987661] Descriptor sense data with sense descriptors (in hex):
[   46.174824] ata1: EH complete
[   46.192262] ata1.00: detaching (SCSI 0:0:0:0)
[   46.385087] sd 0:0:0:0: [sda] Truncating mode parameter data from 8309 to 512 bytes
[   46.528710] EXT4-fs (mmcblk0p1): mounted filesystem with ordered data mode. Opts: (null)
[   66.180807] ata1.00: qc timeout (cmd 0xef)
[   66.180862] ata1.00: failed to disable DEVSLP
[   66.180932] ata1: hard resetting link
[   66.485406] ata1: SATA link down (SStatus 0 SControl 310)
[   66.496304] ata1: EH complete

And the 3.16/3.17 kernel shows:

[    3.873398] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[    5.514259] ata1.00: supports DRM functions and may not be fully accessible
[    5.521349] ata1.00: ATA-9: Crucial_CT256MX100SSD1, MU01, max UDMA/133
[    5.528000] ata1.00: 500118192 sectors, multi 16: LBA48 NCQ (depth 31/32)
[    5.539774] ata1.00: supports DRM functions and may not be fully accessible
[    5.555588] ata1.00: configured for UDMA/133
[    5.564725] scsi 0:0:0:0: Direct-Access     ATA      Crucial_CT256MX1 MU01 PQ: 0 ANSI: 5
[    5.579236] sd 0:0:0:0: [sda] 500118192 512-byte logical blocks: (256 GB/238 GiB)
[    5.591411] sd 0:0:0:0: [sda] 4096-byte physical blocks
[    5.601628] sd 0:0:0:0: [sda] Write Protect is off
[    5.610952] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[    5.611099] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[    5.626860]  sda:
[    5.634638] sd 0:0:0:0: [sda] Attached SCSI disk

If someone could pass this up to wherever it needs to go, or knows where a bug report like this goes against the 3.10 kernel, that would be great.

Thanks!

2

Still occurs with 19.3 release of L4T.

3

Still occurs with 21.2 release of L4T.

Is this a problem specific to the MX100, or is the SATA port on the Jetson generally worthless?

4

I have a regular old-tech SATA2 hard drive on this port that works fine. It is also powered by the Jetson’s MOLEX connector…this adds a slight noise into audio but is otherwise fine. So SATA does work, this is very likely specific to the SSD.

5

The major selling point for me of Jetson vs. other ARM dev platforms is the SATA port means real storage possibilities, meaning I can run CI builds without burning through an SD card every 3 weeks.

A sufficiently broken ATA driver that a bog standard consumer disk doesn’t work is a Problem™.

6

The case of a specific SSD having an issue isn’t generally just a Jetson issue…SSD drivers are still evolving on all o/s. Being that Tegra K1 is intended for many mobile devices it is likely nVidia will look at this…the trick is that one has to know the specific SSD has an issue and then to have the actual SSD to work on it. I believe it is just a matter of patience.

7

It’s a 5 month old thread.

8

True, but this isn’t the L4T bug email address…this is mostly an end-user forum. At this point I believe there is more “breathing room” for specific SSD issues to be looked at compared to when Jetson first came out…nobody can work on the issue without having the specific SSD so it becomes less likely another end-user capable of working on this bug actually has the specific SSD. Even nVidia probably can’t work on this without the actual drive to work on. Since the thread was just re-opened give it some time.

It’s hard to find but here is an email address which might be helpful:
linux-tegra-bugs@nvidia.com

9

Just as another data point, I have not had any trouble with a 250GB Samsung 840 SSD. However, this has worked for me on L4T 19.3 and 21.X

10

Same here with the 840, no problems.

But all my Crucial SSD (M4, 500, MX100) did have problems working in 19.2-21.2.
Requires an extra reboot or two before it get picked up.

11

I’ve mailed that bug list.

Crucial are the 6th biggest SSD manufacturer in the world, so it’s not as if they’re a minor player.

12

The issue discussed in this thread is expected to be fixed in the next Linux for Tegra release.