SATA problems on MacBook Pro 11,1?

This change was made by a bot.

I found out, that if I start the laptopt without it being connected to the power supply, this errors do not occur. But once I plug it in, the errors start, and continue even after I plug it out.

It also happens after suspend and resuming

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v3.15 kernel[0].

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

If you are unable to test the mainline kernel, for example it will not boot, please add the tag: 'kernel-unable-to-test-upstream'.
Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.15-rc5-utopic/

I tested kernel 3.15-rc5 and the bug is still present there.

I found out, that this seems to be related to the SATA power management. If I use powertop and enable "Enable SATA link power Managmenet for host1", the errors stop.

Although, from time to time I still get messages like
[ 191.343588] ata1.00: status: { DRDY }
[ 191.343594] ata1: hard resetting link
[ 192.065491] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
[ 192.065923] ata1.00: unexpected _GTF length (8)
[ 192.066360] ata1.00: unexpected _GTF length (8)
[ 192.066366] ata1.00: configured for UDMA/33
[ 192.066488] ata1: EH complete
[ 208.447775] ata1.00: exception Emask 0x10 SAct 0x0 SErr 0x4040000 action 0xe frozen
[ 208.447779] ata1.00: irq_stat 0x80000040, connection status changed
[ 208.447781] ata1: SError: { CommWake DevExch }
[ 208.447783] ata1.00: failed command: READ DMA EXT
[ 208.447787] ata1.00: cmd 25/00:08:28:cd:51/00:00:10:00:00/e0 tag 0 dma 4096 in
[ 208.447787] res 50/00:00:00:00:00/00:00:00:00:00/a0 Emask 0x10 (ATA bus error)
[ 208.447789] ata1.00: status: { DRDY }
[ 208.447792] ata1: hard resetting link
[ 209.171406] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
[ 209.171868] ata1.00: unexpected _GTF length (8)
[ 209.172388] ata1.00: unexpected _GTF length (8)
[ 209.172394] ata1.00: configured for UDMA/33
[ 209.172549] ata1: EH complete

Thanks Markus, your powertop tip helped me with the error messages.

The only problem now is my ubuntu does not suspend and leaves the computer in lock screen.

Thank you for taking the time to file a bug report on this issue.

However, given the number of bugs that the Kernel Team receives during any development cycle it is impossible for us to review them all. Therefore, we occasionally resort to using automated bots to request further testing. This is such a request.

  With the recent release of this Ubuntu release, would like to confirm if this bug is still present. Please test again with the newer kernel and indicate in the bug if this issue still exists or not.

You can update to the latest development kernel by simply running the following commands in a terminal window:

    sudo apt-get update
    sudo apt-get dist-upgrade

If the bug still exists, change the bug status from Incomplete to Confirmed. If the bug no longer exists, change the bug status from Incomplete to Fix Released.

If you want this bot to quit automatically requesting kernel tests, add a tag named: bot-stop-nagging.

 Thank you for your help, we really do appreciate it.

I'm running the latest kernel from the Ubuntu repositories (3.13.0-27-generic) and this bug is still present for me.

I've also tested this on 3.16-rc1 (from http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.16-rc1-utopic/) and confirmed this bug is still present.

I just installed a fresh Xubuntu 14.04 on an iMac with Fusion drive. I split the Fusion drive to install the ubuntu on the SSD. I now get a lot of very similar errors:

[332951.343902] ata5: irq_stat 0x00400000, PHY RDY changed
[332951.343908] ata5: SError: { PHYRdyChg }
[332951.343916] ata5: hard resetting link
[332952.066052] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
[332952.066683] ata5.00: unexpected _GTF length (8)
[332952.067485] ata5.00: unexpected _GTF length (8)
[332952.067607] ata5.00: configured for UDMA/33
[332952.067726] ata5: EH complete
[332952.167737] ata5: exception Emask 0x10 SAct 0x0 SErr 0x10000 action 0xe frozen

Machine is usable and working fine, though. uname -a yields:
Linux XiMac 3.13.0-30-generic #55-Ubuntu SMP Fri Jul 4 21:40:53 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

I found the following workaround:

as root:

echo "min_power" > /sys/class/scsi_host/host4/link_power_management_policy

where host4 correspnds to my ata5 in the error message. Now the error messages have stopped. I hope this helps with debugging

Nils' workaround also works for me, as does setting the link_power_management_policy to "medium_power".

Further to my earlier comment, it seems that these settings don't entirely eliminate SATA errors. I've tried with both "medium_power" and "min_power" as settings for the link_power_management_policy, and still get some errors. They're slightly different, and also less regular; around 10 every 5 minutes as opposed to once a second on "max_performance". Here's a sample of the errors produced on "medium_power". I've added some line breaks to make the difference in timestamps easier to follow.

[367622.113130] ata1.00: exception Emask 0x10 SAct 0x0 SErr 0x4040000 action 0xe frozen
[367622.113134] ata1.00: irq_stat 0x80000040, connection status changed
[367622.113136] ata1: SError: { CommWake DevExch }
[367622.113139] ata1.00: failed command: WRITE DMA EXT
[367622.113143] ata1.00: cmd 35/00:08:80:7b:0d/00:00:16:00:00/e0 tag 24 dma 4096 out
[367622.113143] res 50/00:00:77:3f:ff/00:00:0f:00:00/ef Emask 0x10 (ATA bus error)
[367622.113145] ata1.00: status: { DRDY }
[367622.113148] ata1: hard resetting link
[367622.836250] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
[367622.836665] ata1.00: unexpected _GTF length (8)
[367622.837097] ata1.00: unexpected _GTF length (8)
[367622.837103] ata1.00: configured for UDMA/33
[367622.837188] ata1: EH complete

[367668.468555] ata1.00: exception Emask 0x10 SAct 0x0 SErr 0x4040000 action 0xe frozen
[367668.468565] ata1.00: irq_stat 0x80000040, connection status changed
[367668.468570] ata1: SError: { CommWake DevExch }
[367668.468578] ata1.00: failed command: READ DMA
[367668.468588] ata1.00: cmd c8/00:08:f8:e6:e0/00:00:00:00:00/ee tag 26 dma 4096 in
[367668.468588] res 50/00:00:a7:e1:4a/00:00:1b:00:00/e0 Emask 0x10 (ATA bus error)
[367668.468594] ata1.00: status: { DRDY }
[367668.468601] ata1: hard resetting link
[367669.192455] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
[367669.192953] ata1.00: unexpected _GTF length (8)
[367669.193458] ata1.00: unexpected _GTF length (8)
[367669.193462] ata1.00: configured for UDMA/33
[367669.193568] ata1: EH complete

[367676.039388] ata1.00: exception Emask 0x10 SAct 0x0 SErr 0x4040000 action 0xe frozen
[367676.039393] ata1.00: irq_stat 0x80000040, connection status changed
[367676.039396] ata1: SError: { CommWake DevExch }
[367676.039401] ata1.00: failed command: WRITE DMA EXT
[367676.039407] ata1.00: cmd 35/00:08:20:f2:fd/00:00:15:00:00/e0 tag 28 dma 4096 out
[367676.039407] res 50/00:00:07:e3:7d/00:00:12:00:00/e0 Emask 0x10 (ATA bus error)
[367676.039410] ata1.00: status: { DRDY }
[367676.039414] ata1: hard resetting link
[367676.762336] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
[367676.762813] ata1.00: unexpected _GTF length (8)
[367676.763339] ata1.00: unexpected _GTF length (8)
[367676.763342] ata1.00: configured for UDMA/33
[367676.763497] ata1: EH complete

[368192.378495] ata1.00: exception Emask 0x10 SAct 0x0 SErr 0x4040000 action 0xe frozen
[368192.378505] ata1.00: irq_stat 0x80000040, connection status changed
[368192.378510] ata1: SError: { CommWake DevExch }
[368192.378517] ata1.00: failed command: WRITE DMA
[368192.378528] ata1.00: cmd ca/00:80:10:d9:6a/00:00:00:00:00/ee tag 15 dma 65536 out
[36819...

I'm getting these errors in Xubuntu 14.04 amd64 with nvidia binaries on a Lenovo Thinkpad W510. I only noticed them because several times over the past couple of months since installing Xubuntu 14.04, the machine has suddenly, and quite randomly, remounted the filesystem to read only. When that happens, I can't even shut down normally. I can't even log in via a TTY to issue a shutdown command. When I installed Xubuntu 14.04, I also upgraded from a hard drive to a Crucial MX100 SSD, but it seems likelier the problem is software, not hardware. I don't have any buffer I/O errors or anything like that in kern.log or syslog.

I have tested the 3.17-rc4 (3.17.0-031700rc4-generic) kernel and I still see these errors.

Similar to other user experiences here, the errors seem show up when waking from suspend (opening the lid) and when connecting the power cable.

Just to clarify, it seems the "hard resetting link" and "SError: { CommWake DevExch }" errors I was seeing had to do with me connecting/disconnecting an external bus-powered portable eSATA drive (ata6) that sometimes isn't correctly detected for some reason. The sudden, random remounting of my main drive (ata1) in read-only mode may well be a different problem, and one that leaves no trace in the logs because, of course, the drive is in read-only mode.

i have this problem too :(

please fix that...

I heard that some SSHD devices may cause this issue on current kernel of trusty.
`sudo hdparm -I /dev/sda | grep Model` can be used to get the disk model name.
Using the kernel parameter 'libata.noacpi=1' may be able to solve this problem.

I was able to recreate this same problem on an ASrock Z87E-ITX with an mSATA SSD and both Ubuntu 12.04.5 and 14.04.1. Same series of errors in dmesg. I did manage to get a full install done - not sure how - but when the system boots it's prone to frequent lockups (also, occasionally, at boot, it claims it can't find /tmp).

In fact, I've found that if I boot the system into a live environment and just try mounting the SSD, I can see the same errors in dmesg. I can even get into gparted and create an empty ext4 partition on the drive, and see the errors. Even rebooting and trying to mount the empty partition causes the errors.

All of the "help" I"ve seen directs users to try different SATA cables or ports, but I can't put the mSATA SSD anywhere else, except in another system (where it works just fine). I did see one reference to disabling an ASMEDIA controller on a different ASrock motherboard, but the one I have doesn't include such a controller - it's just the Intel ICH.

For S&G I installed the Windows 8.1 trial on this system, on the mSATA SSD, and it runs without issue. No stutters, no lockups, no drive errors, no SMART errors, nothing.

The really strange thing: now that I've installed Windows on it, I have the system sitting in an Ubuntu live environment, with the windows install mounted., I've even written a few files to it, and I'm not seeing any errors at all.

I'm attaching output from lspci, lsusb, lshw-short and dmesg on the system - this dmesg output comes after I mounted the windows partition and wrote a file with some random text in it to the drive (this was enough to cause the errors previously). Unfortunately I didn't think to capture a dmesg prior to installing Windows 8.1 - it didn't occur to me that the problem might go away by doing so.

I'm going to try to install Ubuntu on the drive again and see what happens, however, if I can't duplicate the error, I'm going to be kicking myself for not getting a dmesg from before for comparison.

So, I used gparted to format the drive with a single ext4 partition, rebooted the system, mounted it, and the errors came back.

It's not a hardware issue. It's some combination of the OS, chipset, file system in use, and maybe (?) drive type. I can use the same drive on a Gigabyte board that uses the B85 chipset and have zero issues, so it doesn't seem to be the entire lynx point chipset family. The Z87 on this board is the revised C2 stepping.

Anecdotal evidence from web searches might indicate some relation to ASrock Z87 boards in particular, but then, user reports of the error go back several years, and earlier reports were oftentimes hardware issues. And obviously, in the case of the initial bug report here, it was a Macbook Pro.

I'm attaching dmesg output from the same system, this is from a fresh boot to a live environment and mounting the drive by clicking it in nautilus. The errors were back, just as they were before.

After reinstalling the Windows 8 Trial on the system, it's back to working without any errors in a live ubuntu environment. Not really sure what to make of this, aside from it not being a hardware problem.

Hi Matt,
did you try the workaround that I suggested in the bugreport? Does it work? I still need to do it on my machine, but it mitigates the problem.

Cheers,
Nils

> Gesendet: Dienstag, 13. Januar 2015 um 08:50 Uhr
> Von: "Matt Hanyok" <email address hidden>
> An: <email address hidden>
> Betreff: [Bug 1318218] Re: SATA problems on MacBook Pro 11,1?
>
> So, I used gparted to format the drive with a single ext4 partition,
> rebooted the system, mounted it, and the errors came back.
>
> It's not a hardware issue. It's some combination of the OS, chipset,
> file system in use, and maybe (?) drive type. I can use the same drive
> on a Gigabyte board that uses the B85 chipset and have zero issues, so
> it doesn't seem to be the entire lynx point chipset family. The Z87 on
> this board is the revised C2 stepping.
>
> Anecdotal evidence from web searches might indicate some relation to
> ASrock Z87 boards in particular, but then, user reports of the error go
> back several years, and earlier reports were oftentimes hardware issues.
> And obviously, in the case of the initial bug report here, it was a
> Macbook Pro.
>
> I'm attaching dmesg output from the same system, this is from a fresh
> boot to a live environment and mounting the drive by clicking it in
> nautilus. The errors were back, just as they were before.
>
> After reinstalling the Windows 8 Trial on the system, it's back to
> working without any errors in a live ubuntu environment. Not really sure
> what to make of this, aside from it not being a hardware problem.
>
> ** Attachment added: "dmesg-errors.txt"
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1318218/+attachment/4296899/+files/dmesg-errors.txt
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1318218
>
> Title:
> SATA problems on MacBook Pro 11,1?
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1318218/+subscriptions
>

I have the same issue on my desktop computer that is configured to suspend when inactive. There have two SATA disks and 1 PATA disk on this box and only one disk seems to have issues while suspending. Desktop hangs while suspending and needs a hard reset. Kernel message before hang:

Apr 11 18:34:00 phoebe kernel: [46916.180338] ata3: exception Emask 0x40 SAct 0x0 SErr 0x800 action 0x7
Apr 11 18:34:00 phoebe kernel: [46916.180352] ata3: SError: { HostInt }
Apr 11 18:34:00 phoebe kernel: [46916.180363] ata3: hard resetting link
Apr 11 18:34:00 phoebe kernel: [46916.671824] ata3: softreset failed (device not ready)
Apr 11 18:34:00 phoebe kernel: [46916.671830] ata3: applying PMP SRST workaround and retrying
Apr 11 18:34:00 phoebe kernel: [46916.843775] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
Apr 11 18:34:00 phoebe kernel: [46916.854172] ata3.00: configured for UDMA/133
Apr 11 18:34:00 phoebe kernel: [46916.867797] ata3: EH complete
Apr 11 20:12:15 phoebe kernel: [ 0.000000] Initializing cgroup subsys cpuset

Disk having issues:
 *-disk
       description: ATA Disk
       product: WDC WD10EZEX-07Z
       vendor: Western Digital
       physical id: 0.0.0
       bus info: scsi@2:0.0.0
       logical name: /dev/sdb
       version: 80.0
       serial: WD-WCC1S0911072
       size: 931GiB (1TB)
       capabilities: gpt-1.00 partitioned partitioned:gpt
       configuration: ansiversion=5 guid=af7b25e8-6b9d-0363-6045-bd10f7b3f818 sectorsize=4096

Kernel version: Linux phoebe 3.13.0-49-generic #81-Ubuntu SMP Tue Mar 24 19:29:48 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

Setting min_power in /sys/class/scsi_host/host3/link_power_management_policy
seems to work.