Macbook Pro Late 2013 Retina

cafebustelo · 2015-08-25 00:23:47

Hi all,

I've got my first arch install up and running on an 11,1. I've got everything working great, except for hangs caused by an issue with the SSD.

I've read though this whole thread, and I've seen that early on it was recommended that "libata=noncq" be appended to the grub (or refind) config, but then after a kernel update it seems some people now think it's ok to remove that string.

I've tried it both with and without that string, and I keep getting the same issue. I've also tried adding "acpi=off" and "noapic" (independently and together, also with and without the noncq string), neither of which worked.

I'm hoping someone here might be able to see something I'm not here.

Here's a snippet of the dmesg output:

[  277.480200] ata1.00: exception Emask 0x10 SAct 0x0 SErr 0x50000 action 0xe frozen
[  277.480204] ata1.00: irq_stat 0x00400000, PHY RDY changed
[  277.480206] ata1: SError: { PHYRdyChg CommWake }
[  277.480208] ata1.00: failed command: WRITE DMA
[  277.480211] ata1.00: cmd ca/00:08:d0:26:70/00:00:00:00:00/e7 tag 13 dma 4096 out
                        res 50/00:00:2f:7a:ac/00:00:07:00:00/e7 Emask 0x10 (ATA bus error)
[  277.480213] ata1.00: status: { DRDY }
[  277.480216] ata1: hard resetting link
[  278.200412] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
[  278.200811] ata1.00: unexpected _GTF length (8)
[  278.201203] ata1.00: unexpected _GTF length (8)
[  278.201206] ata1.00: configured for UDMA/33
[  278.201313] ata1: EH complete
[  288.998003] ata1.00: exception Emask 0x10 SAct 0x0 SErr 0x50000 action 0xe frozen
[  288.998018] ata1.00: irq_stat 0x00400000, PHY RDY changed
[  288.998020] ata1: SError: { PHYRdyChg CommWake }
[  288.998023] ata1.00: failed command: WRITE DMA
[  288.998027] ata1.00: cmd ca/00:08:88:aa:aa/00:00:00:00:00/e9 tag 1 dma 4096 out
                        res 50/00:00:00:00:00/00:00:00:00:00/a0 Emask 0x10 (ATA bus error)
[  288.998029] ata1.00: status: { DRDY }
[  288.998033] ata1: hard resetting link
[  289.718281] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
[  289.718760] ata1.00: unexpected _GTF length (8)
[  289.719321] ata1.00: unexpected _GTF length (8)
[  289.719325] ata1.00: configured for UDMA/33
[  289.719444] ata1: EH complete
[  300.182464] ata1.00: exception Emask 0x10 SAct 0x0 SErr 0x50000 action 0xe frozen
[  300.182474] ata1.00: irq_stat 0x00400000, PHY RDY changed
[  300.182480] ata1: SError: { PHYRdyChg CommWake }
[  300.182487] ata1.00: failed command: READ DMA
[  300.182497] ata1.00: cmd c8/00:08:48:ee:f0/00:00:00:00:00/ec tag 13 dma 4096 in
                        res 50/00:00:9f:a9:6a/00:00:0b:00:00/eb Emask 0x10 (ATA bus error)
[  300.182503] ata1.00: status: { DRDY }
[  300.182511] ata1: hard resetting link
[  300.902687] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
[  300.903343] ata1.00: unexpected _GTF length (8)
[  300.904013] ata1.00: unexpected _GTF length (8)
[  300.904026] ata1.00: configured for UDMA/33
[  300.904140] ata1: EH complete

Thanks for your help!

Edit: I should probably be more specific about what I'm hoping to learn. Is there some other string I can use to fix this issue that I'm leaving out? Currently I've just got the libata.force=noncq. I've seen that some people use others in addition to (or without) that one. Alternatively, is this an indicator of some other problem (a bad sector? something else?)?

Last edited by cafebustelo (2015-08-25 00:26:14)

frank604 · 2015-08-25 00:44:10

@cafebustelo, do you have tlp? or other power savings on? if tlp you can disable sata link power.
edit: I should write the fix here. edit /usr/sbin/tlp and comment out :

# set_sata_link_power $1

Last edited by frank604 (2015-08-25 01:56:42)

cafebustelo · 2015-08-25 01:37:50

That fixed it! Thanks frank604.

regulament · 2015-09-14 09:18:16

Here comes a weird problem, if any of you have any tips, please share.

Yesterday, I reinstalled my system, this time with DM-Crypt and LVM on LUKS. All nice and good. Config files were saved from my old install and carefully copied onto the new system.

Weird thing is all Qt5 applications( qutebrowser, otter-browser both confirmed, all other apps and GTK apps were working without any problems, so I guess Qt5 is at fault) were lagging. Lagging as in if the application was focused( I am running bspwm), it was barely usable, with huge lag, if it was even working. As soon as I focused on another window, the queue of commands to the Qt5 app were all happening very fast.

After some hours of anger I saw that some pixels( a small line of lie 12 pixels -which is small as heck) was not updating. It was stuck for a while and after some time it was finally "redrawn". Also, weirdly enough, when I was running something on either screen( I have an external monitor connected) that was actively refreshing( a YouTube video for example) qutebrowser and otter-browser ran without any problems.

I had some powersaving options on ( "options i915 enable_rc6=1 enable_fbc=1 lvds_downclock=1"), disabled them, ran mkinitcpio and all my problems are gone. Weird thing is, I also had those powersaving options before and everything was working.

Any ideas why is this happening? Can somebody test this to confirm is not just my machine?

regulament · 2015-10-02 18:51:27

Beware, the latest version of broadcom-wl-dkms causes kernel panics as soon as you try to use the wireless internet.

hrod · 2015-10-03 05:42:35

regulament wrote:

Beware, the latest version of broadcom-wl-dkms causes kernel panics as soon as you try to use the wireless internet.

Hi. The broadcom-wl package is also having problems, and the maintainer has not updated it yet. A patch has been made to fix compatibility with linux 4.2, here is a fork with the patch applied.

masq · 2015-10-05 13:30:30

I'm considering getting the 11,3 (the 15" model with the Nvidia card) very soon and would like to ask anyone who has it if they could chime in with some feedback on how well graphics switching works under linux and what the battery life is like (and also if there are any other issues like suspend, etc...). My apologies if this information is already in teh thread but I'm under some time pressure to decide if I want it (as it may be sold soon) so I need to decide quickly between the 15" model with and without the GPU (incidentally a GPU is useful for me for development purposes).

thanks

cormacc · 2015-10-21 09:53:58

I'd go with the Intel-only model, based on my own experience with the version with discrete graphics.
I have managed to enable the integrated intel adapter, but not to successfully disable nvidia at the same time, and driver switching is a pain in the ****
Particularly annoying as no tty available when nvidia active at boot, so need to reset to recover from a lot of failures starting X etc.

Experience otherwise fine -- but battery life not great.

May be missing something, but haven't come across anyone reporting a complete success with disabling nvidia / using intel on an 11.3 to date.

novcn · 2016-03-19 02:57:48

Same issue as @gofvonx where sometimes boot takes a long time, somewhere between 30 seconds - 5 minutes. With potential related logs from dmesg:

[    5.578654] xhci_hcd 0000:00:14.0: Command completion event does not match command
[    5.578657] xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
[    7.059262] IPv6: ADDRCONF(NETDEV_CHANGE): wlp3s0: link becomes ready
[   10.592116] xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
[   10.592129] usb 1-3: hub failed to enable device, error -62
[   15.605518] xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
[   15.765523] usb 1-3: new full-speed USB device number 3 using xhci_hcd
[   15.808840] usb 2-3: device not accepting address 2, error -62

This is using rEFInd (so it's clearly not an issue with the boot loader) since @gofvonx uses grub. My coworker - who's also running Arch on a MBP has the same issues.

Anyone else experience this or have ideas no how it can be fixed?

chrismacp · 2016-04-28 20:13:28

I'm having the exact same issue as you novcn, it's so annoying. Was working fine and then all of a sudden it starts happening. Didn't update anything. Did you find a solution?

novcn · 2016-04-30 23:12:15

Hi chrismacp,

Unfortunately no.. One condition that I have experience however is that this issue seems to be tied with the state at which the computer was at when it was shut off.

- Systemctl poweroff: Reports ~"Stop job waiting to finish", takes 90 seconds, no hang at reboot
- Hard poweroff: Hang at reboot
- Reboot from OSX: Hang at reboot

Hopefully soon I'll get some time to look into it. Will update.

asbachb · 2016-07-17 21:51:40

Do you experience still problems with poweroff? I'm on a 11,1 with a fresh install, but don't have any issues with poweroff.

My problem: Firstly the suspend on lid close worked quite fine after disabling some gpe and the XHC1 wakeup. But now it takes about 1-2 minutes to suspend after the lid is closed. Is there anyone who can confirms this problem?

Sound also sounds a little bit different than on OSX, it seems there's a missbalance between bass and stereo speakers.

willd · 2016-12-25 18:19:58

As with @novcn and @gofvonx I've had these issues for a while. They have now somewhat escalated by actually killing the hub, thereby also killing the keyboard on my 11,1..

 kernel: xhci_hcd 0000:00:14.0: xHCI host not responding to stop endpoint command.
 xhci_hcd 0000:00:14.0: Assuming host is dying, halting host.
 kernel: xhci_hcd 0000:00:14.0: HC died; cleaning up
 kernel: bcm5974 1-5:1.2: could not read from device

I've seen this on kernel 4.7, 4.8 and now 4.9.. Anyone seeing the same?

novcn wrote:

Same issue as @gofvonx where sometimes boot takes a long time, somewhere between 30 seconds - 5 minutes. With potential related logs from dmesg:
[    5.578654] xhci_hcd 0000:00:14.0: Command completion event does not match command
[    5.578657] xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
[    7.059262] IPv6: ADDRCONF(NETDEV_CHANGE): wlp3s0: link becomes ready
[   10.592116] xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
[   10.592129] usb 1-3: hub failed to enable device, error -62
[   15.605518] xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
[   15.765523] usb 1-3: new full-speed USB device number 3 using xhci_hcd
[   15.808840] usb 2-3: device not accepting address 2, error -62
This is using rEFInd (so it's clearly not an issue with the boot loader) since @gofvonx uses grub. My coworker - who's also running Arch on a MBP has the same issues.
Anyone else experience this or have ideas no how it can be fixed?

novcn · 2016-12-31 18:44:23

Yes @willd I am seeing this issue - HC died; cleaning up - too, since updating to 4.8.11, which I had hopes to fix an issue with external monitor intermittently blacking out, the bug and potential fix detailed here: https://bugs.freedesktop.org/show_bug.cgi?id=94605
It only happens when I have my usb keyboard plugged in while booting. If I boot up and then plug it in to login every thing is normal.

As far as the slow boot issue, I switched from using rEFInd to bootctl/systemd-boot and still see the same issue so it's definitely boot loader agnostic. I haven't tested this, and am not willing, but my guess is that if you were to wipe Linux off your MBP and just run MacOS you would see the same issue, since it happens before the kernel is even loaded.

vesath · 2017-02-16 05:03:32

@willd: I've found a workaround for the "HC died" issue is to add "usbcore.old_scheme_first=1" as boot kernel parameter.

My best guess is that it's a misbehavior of how MBP's firmware powers up USB devices which is bad enough that the new kernel device initialization scheme just gives up. I'm hoping Apple will release firmware updates that fix this, but there aren't any for my MPB12,1 yet.

alexyakushev · 2017-02-16 09:03:58

vesath wrote:

@willd: I've found a workaround for the "HC died" issue is to add "usbcore.old_scheme_first=1" as boot kernel parameter.

Friend, thank you so much, you've just saved me a day of work.

I had this problem a week ago for the first time. Had to reinstall Arch anew, and the problem didn't manifest until today. I thought I had to do the reinstallation again, but the workaround worked. I'm on Macbook Pro 2015, running Arch with the latest kernel (4.9.8-1). Here's what I did: pressed F12 during boot (I'm using systemd-boot), pressed e with Arch Linux selected, inserted usbcore.old_scheme_first=1 after the initrd=... sequence and pressed Enter.

Last edited by alexyakushev (2017-02-16 09:06:05)

vesath · 2017-03-06 18:08:17

@willd, @alexyakushev. Lately my "usbcore.old_scheme_first=1" workaround has not been working consistently for me: on average, half the time I booted my MBP I still had the "xhci_hcd: HC died; cleaning up" error and after that my keyboard was dead.
But I noticed that a few seconds before that error was actually printed on screen, my keyboard did work, implying that HC was in fact not (entirely?) dead and did not deserve cleaning up.
So I wrote this simple-minded patch which just works: https://fenua.org/gaetan/tmp/undead.patch

It simply removes the cleaning-up code. You can compile your own kernel with it, boot it with no special parameter, and it works like pre-4.8 kernels did.
As a side note, other distros have apparently upgraded their kernels and some users are reporting this bug quite vocally: https://bugs.launchpad.net/ubuntu/+sour … ug/1668105

ddalex · 2017-03-15 13:29:41

vesath wrote:

@willd: I've found a workaround for the "HC died" issue is to add "usbcore.old_scheme_first=1" as boot kernel parameter.

Thank you, I've been having this problem for ages with a Macbook 12,1 - will try this to see if it makes things better.
The slow boot is definitely related to the USB hardware - the xHCI dying during bootup is always related to slow boot where the keyboard isn't working in Grub.

Reboots don't reset the hardware for me, there has to be a full poweroff for maybe 30 seconds for the hardware to be completely reset and the USB start working again.

Will try this setting and will report back if it makes the HW behave better.

Kisuke-CZE · 2017-03-16 07:53:41

vesath wrote:

@willd, @alexyakushev.
So I wrote this simple-minded patch which just works: https://fenua.org/gaetan/tmp/undead.patch
It simply removes the cleaning-up code. You can compile your own kernel with it, boot it with no special parameter, and it works like pre-4.8 kernels did.
As a side note, other distros have apparently upgraded their kernels and some users are reporting this bug quite vocally: https://bugs.launchpad.net/ubuntu/+sour … ug/1668105

Guys, you just saved me a lot of work. Thanks. I was experiencing this "HC died; cleaning up" randomly for a week. I was even considering going back to MacOS (yes, it was that bad).
Unfortunately, usbcore.old_scheme_first=1 did not helped for me.
But patch posted by vesath seems to resolved this issue and I can finally use my computer.

I have Macbook Pro 11,1 (Mid 2014), firmware BIOS MBP111.88Z.0138.B21.1612221936 12/22/2016 (this version is not even listed on Apple's website, there is only older version). There was that long (~ 20 sec) delay before OS started booting also when I run OSX. But OSX never disconnected my keyboard and touchpad (and all external USB peripherals) like Linux.

Kisuke-CZE · 2017-03-19 18:29:04

Any chance that this commit to 4.10.4 can help us solve this issue?

commit a062cb39594667bd3953f71cbcf7e0b276998f56
Author: Guenter Roeck <linux@roeck-us.net>
Date:   Thu Mar 9 15:39:37 2017 +0200

    usb: host: xhci-plat: Fix timeout on removal of hot pluggable xhci controllers
    
    commit dcc7620cad5ad1326a78f4031a7bf4f0e5b42984 upstream.
    
    Upstream commit 98d74f9ceaef ("xhci: fix 10 second timeout on removal of
    PCI hotpluggable xhci controllers") fixes a problem with hot pluggable PCI
    xhci controllers which can result in excessive timeouts, to the point where
    the system reports a deadlock.
    
    The same problem is seen with hot pluggable xhci controllers using the
    xhci-plat driver, such as the driver used for Type-C ports on rk3399.
    Similar to hot-pluggable PCI controllers, the driver for this chip
    removes the xhci controller from the system when the Type-C cable is
    disconnected.
    
    The solution for PCI devices works just as well for non-PCI devices
    and avoids the problem.

EDIT:
Seems issue was fixed in 4.12.4, commit a54408d0a004757789863d74e29c2297edae0b4d
See changelog
I do not experience this issue anymore. But not using Arch as main OS now, but I will try to switch on it again.

Last edited by Kisuke-CZE (2017-08-13 12:38:20)

plech.d · 2018-03-10 20:23:57

Hi all.

I have a problem with suspend / resume, suddenly it's taking eons to wake up (at least about a minute and a half). I thought it was somehow related to my setup, but I tried it directly on the 1st of March live USB (typed in systemctl suspend), waited for the fans to stop, pressed the power button, then had to wait for at least a minute.

Anyone else experiencing the problem? In the meantime, I'll try it on two older live USB's (Jan, Feb 2018), just to verify.

(By the way, I also use apple_set_os.efi + gpu-switch + outb's in grub menuentry + program to shut down gpu, and if and when I run the program to shut down the gpu and then suspend, wakeup doesn't happen at all after that, ever. However, I don't want to relate that necessarily to what I wrote above, because this is a specific hack. What I wrote above applies generally, like I said, even right off the live USB.)

Thanks for any comments!

plech.d · 2018-03-10 20:30:55

plech.d wrote:

Hi all.
I have a problem with suspend / resume, suddenly it's taking eons to wake up (at least about a minute and a half). I thought it was somehow related to my setup, but I tried it directly on the 1st of March live USB (typed in systemctl suspend), waited for the fans to stop, pressed the power button, then had to wait for at least a minute.
Anyone else experiencing the problem? In the meantime, I'll try it on two older live USB's (Jan, Feb 2018), just to verify.
(By the way, I also use apple_set_os.efi + gpu-switch + outb's in grub menuentry + program to shut down gpu, and if and when I run the program to shut down the gpu and then suspend, wakeup doesn't happen at all after that, ever. However, I don't want to relate that necessarily to what I wrote above, because this is a specific hack. What I wrote above applies generally, like I said, even right off the live USB.)
Thanks for any comments!

Just popping in to confirm that it indeed works fine off the live USB from Feb 2018 (kernel 4.14.15.1) (systemctl suspend, wait a moment, then press power button, wakeup is immediate).

plech.d · 2018-03-10 23:33:35

plech.d wrote:

plech.d wrote:
Hi all.
I have a problem with suspend / resume, suddenly it's taking eons to wake up (at least about a minute and a half). I thought it was somehow related to my setup, but I tried it directly on the 1st of March live USB (typed in systemctl suspend), waited for the fans to stop, pressed the power button, then had to wait for at least a minute.
Anyone else experiencing the problem? In the meantime, I'll try it on two older live USB's (Jan, Feb 2018), just to verify.
(By the way, I also use apple_set_os.efi + gpu-switch + outb's in grub menuentry + program to shut down gpu, and if and when I run the program to shut down the gpu and then suspend, wakeup doesn't happen at all after that, ever. However, I don't want to relate that necessarily to what I wrote above, because this is a specific hack. What I wrote above applies generally, like I said, even right off the live USB.)
Thanks for any comments!
Just popping in to confirm that it indeed works fine off the live USB from Feb 2018 (kernel 4.14.15.1) (systemctl suspend, wait a moment, then press power button, wakeup is immediate).

So I did some experiments on a clean installation without X (just after following installation guide and rebooting). Here are suspend/resume times in between kernel upgrades under the same conditions each time. I closed the lid and opened it again immediately after the logo light went off. The times are in between the last and the first entries in journalctl:

4.14.15: around 22 secs
4.15.1: around 30 secs
4.15.2: around 45 secs.

Downgrading the kernel back to the previous versions restored the same, faster resume times.

I don’t know what happened, but it sucks, because in the newest kernels resume is almost unusably slow.

funji · 2018-04-09 15:45:18

Hi all,

I've been using Arch on my MBP for about 6 months and never had xhci_hcd timeout issue until a about two weeks ago. Since then the MBP erratically has a long pre-bootloader lag (~20 secs; I'm using systemd) and then there is no mouse or keyboard input and a few seconds latermy SDDM screen will freeze. I can change into another shell and reboot. Although shutting down tends to get a better chance of correctly booting.
When the pre-boot lags, I will get the following errors in dmesg.

xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
usb 2-3: device not accepting address 4, error -62

I'm using 4.15.15-1-ARCH .
The latest changes I made, was attaching an external HDMI monitor and an USB hub for mouse, keyboard and wifi.

Is anybody else seeing these issues?

Thanks in advance

gianluca.pettinello · 2018-06-25 20:04:31

Hi all,

I recently upgraded to kernel 4.17.2-1.
I use to have "acpi_osi=" kernel parameter following wiki page. And up to 4.17 kernel it was effective to reduce power consumption.
With the upgrade to kernel 4.17 the acpi power got broken and I was not able to get battery recognized by the system.
Deleting "acpi_osi=" kernel parameter fixes the issue but the power consumption goes up.
Anybody had the same problem? If so did anybody found a solution?
Thanks
Ciao
Gianluca

Arch Linux

#376 2015-08-25 00:23:47

Re: Macbook Pro Late 2013 Retina

#377 2015-08-25 00:44:10

Re: Macbook Pro Late 2013 Retina

#378 2015-08-25 01:37:50

Re: Macbook Pro Late 2013 Retina

#379 2015-09-14 09:18:16

Re: Macbook Pro Late 2013 Retina

#380 2015-10-02 18:51:27

Re: Macbook Pro Late 2013 Retina

#381 2015-10-03 05:42:35

Re: Macbook Pro Late 2013 Retina

#382 2015-10-05 13:30:30

Re: Macbook Pro Late 2013 Retina

#383 2015-10-21 09:53:58

Re: Macbook Pro Late 2013 Retina

#384 2016-03-19 02:57:48

Re: Macbook Pro Late 2013 Retina

#385 2016-04-28 20:13:28

Re: Macbook Pro Late 2013 Retina

#386 2016-04-30 23:12:15

Re: Macbook Pro Late 2013 Retina

#387 2016-07-17 21:51:40

Re: Macbook Pro Late 2013 Retina

#388 2016-12-25 18:19:58

Re: Macbook Pro Late 2013 Retina

#389 2016-12-31 18:44:23

Re: Macbook Pro Late 2013 Retina

#390 2017-02-16 05:03:32

Re: Macbook Pro Late 2013 Retina

#391 2017-02-16 09:03:58

Re: Macbook Pro Late 2013 Retina

#392 2017-03-06 18:08:17

Re: Macbook Pro Late 2013 Retina

#393 2017-03-15 13:29:41

Re: Macbook Pro Late 2013 Retina

#394 2017-03-16 07:53:41

Re: Macbook Pro Late 2013 Retina

#395 2017-03-19 18:29:04

Re: Macbook Pro Late 2013 Retina

#396 2018-03-10 20:23:57

Re: Macbook Pro Late 2013 Retina

#397 2018-03-10 20:30:55

Re: Macbook Pro Late 2013 Retina

#398 2018-03-10 23:33:35

Re: Macbook Pro Late 2013 Retina

#399 2018-04-09 15:45:18

Re: Macbook Pro Late 2013 Retina

#400 2018-06-25 20:04:31

Re: Macbook Pro Late 2013 Retina

Board footer