[MacbookPro12,1] Suspend resumes immediately due to xhci driver

[Michael Gratton]

On my MacbookPro12,1 with Wily and Linux 4.2, by default the kernel successfully suspends but then immediately resumes again. The problem seems to be the XHCI controller causing spurious ACPI wakeups.

Also, the Broadcom wifi module seems to have problems with suspend/resume, so I am also unloading the `brcmfmac` module prior to suspend and loading it again after resume.

WORKAROUND: Disable XHC1 prior to sleeping:
> # echo XHC1 > /proc/acpi/wakeup

ProblemType: Bug
DistroRelease: Ubuntu 15.10
Package: linux-image-4.2.0-16-generic 4.2.0-16.19
ProcVersionSignature: Ubuntu 4.2.0-16.19-generic 4.2.3
Uname: Linux 4.2.0-16-generic x86_64
ApportVersion: 2.19.1-0ubuntu2
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC1: mjg 1441 F.... pulseaudio
 /dev/snd/controlC0: mjg 1441 F.... pulseaudio
CurrentDesktop: GNOME
Date: Mon Oct 19 18:13:15 2015
HibernationDevice: RESUME=UUID=bc879a1f-ac27-48ae-82dd-3c81b7307dd0
InstallationDate: Installed on 2015-07-22 (89 days ago)
InstallationMedia: Ubuntu-GNOME 15.04 "Vivid Vervet" - Release amd64 (20150422)
Lsusb:
 Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
 Bus 001 Device 003: ID 05ac:0273 Apple, Inc.
 Bus 001 Device 002: ID 05ac:8290 Apple, Inc.
 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
MachineType: Apple Inc. MacBookPro12,1
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.2.0-16-generic root=/dev/mapper/ubuntu--gnome--vg-root ro quiet splash acpi_backlight=vendor vt.handoff=7
RelatedPackageVersions:
 linux-restricted-modules-4.2.0-16-generic N/A
 linux-backports-modules-4.2.0-16-generic N/A
 linux-firmware 1.149
RfKill:
 3: phy0: Wireless LAN
  Soft blocked: no
  Hard blocked: no
SourcePackage: linux
UdevLog: Error: [Errno 2] No such file or directory: '/var/log/udev'
UpgradeStatus: Upgraded to wily on 2015-08-27 (52 days ago)
dmi.bios.date: 06/05/2015
dmi.bios.vendor: Apple Inc.
dmi.bios.version: MBP121.88Z.0167.B07.1506051617
dmi.board.name: Mac-E43C1C25D4880AD6
dmi.board.vendor: Apple Inc.
dmi.board.version: MacBookPro12,1
dmi.chassis.type: 9
dmi.chassis.vendor: Apple Inc.
dmi.chassis.version: Mac-E43C1C25D4880AD6
dmi.modalias: dmi:bvnAppleInc.:bvrMBP121.88Z.0167.B07.1506051617:bd06/05/2015:svnAppleInc.:pnMacBookPro12,1:pvr1.0:rvnAppleInc.:rnMac-E43C1C25D4880AD6:rvrMacBookPro12,1:cvnAppleInc.:ct9:cvrMac-E43C1C25D4880AD6:
dmi.product.name: MacBookPro12,1
dmi.product.version: 1.0
dmi.sys.vendor: Apple Inc.

[Brad Figg (brad-figg)]

This change was made by a bot.

[penalvch (penalvch)]

Michael Gratton, thank you for reporting this and helping make Ubuntu better.

Could you please test the latest upstream kernel available from the very top line at the top of the page from http://kernel.ubuntu.com/~kernel-ppa/mainline/?C=N;O=D (the release names are irrelevant for testing, and please do not test the daily folder)? Install instructions are available at https://wiki.ubuntu.com/Kernel/MainlineBuilds . This will allow additional upstream developers to examine the issue.

If the latest kernel did not allow you to test to the issue (ex. you couldn't boot into the OS) please make a comment in your report about this, and continue to test the next most recent kernel version until you can test to the issue. Once you've tested the upstream kernel, please comment on which kernel version specifically you tested. If this issue is fixed in the mainline kernel, please add the following tags by clicking on the yellow circle with a black pencil icon, next to the word Tags, located at the bottom of the report description:
kernel-fixed-upstream
kernel-fixed-upstream-X.Y-rcZ

Where X, Y, and Z are numbers corresponding to the kernel version.

If the mainline kernel does not fix the issue, please add the following tags:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-X.Y-rcZ

Please note, an error to install the kernel does not fit the criteria of kernel-bug-exists-upstream.

Once testing of the latest upstream kernel is complete, please mark this report's Status as Confirmed. Please let us know your results.

Thank you for your understanding.

[Michael Gratton (mjog)]

I just tried reproducing this with the most recent from the link above (v4.3-rc6-unstable) and couldn't, then went back to the current wily kernel (4.2.0-16-generic) and still can't reproduce it.

So now I am wondering if the updated firmware for the BCM43602 wifi card in linux-firmware 1.149 fixed the underlying cause?

I'll see if the problem reappears over the next few days and if not, will try reverting linux-firmware to 1.148 to see if the problem comes back.

[Michael Gratton (mjog)]

Just to confirm, using kernel 4.2.0-16-generic, downgrading linux-firmware to 1.148 caused the problem to reappear then upgrading it back to 1.149 caused the problem to go away again.

So it seems this issue was caused by the Broadcom's firmware, rather than the kernel.

[Michael Gratton (mjog)]

I'm re-opening this because I am intermittently seeing the same behaviour per the description again. Likewise, disabling the XHCI in /proc/acpi/wakeup remains a usable workaround.

This is using linux-generic 4.2.0.16.18 and linux-firmware 1.149.

[Brad Figg (brad-figg)]

This change was made by a bot.

[Michael Gratton (mjog)]

I'm not sure what you mean - it's the firmware hasn't changed, it's the same version that appeared to have fixed the problem in the first place.

[penalvch (penalvch)]

Michael Gratton, could you please test http://cdimage.ubuntu.com/daily-live/current/ and advise to the results?

[Michael Gratton (mjog)]

Quick update, after installing 4.4-rc2 from the mainline kernel PPA, the problem has gone away again. Will report back after some use if that seems to be persisting.

[Michael Gratton (mjog)]

Hmm, no it hasn't. I think there is either a controller or device initialisation problem, and it might be a race. On power-on, one of two different things will happen after the Mac startup chime:

1. Usually, there will be along pause (30sec? 1min?), some random display corruption, then boot proceeds normally.
2. Boot proceeds immediately.

In the case of #1, the following is printed to kern.log:

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

Also, when case #1 occurs, then this suspend/resume issue manifests itself.

When case #2 occurs, those messages are not printed in kern.log, and this suspend/resume issue does not occur. I have just had both occur in quick succession with both the current 4.2 kernel in wily, and 4.4-rc2 from the mainline kernel PPA.

[Ricardo Salveti (rsalveti)]

Tested latest daily (4.4.0-rc5 based) and this is still an issue:

[ 524.598918] PM: suspend of devices complete after 206.893 msecs
[ 524.618522] PM: late suspend of devices complete after 19.604 msecs
[ 524.618686] thunderbolt 0000:07:00.0: suspending...
[ 524.618901] thunderbolt 0000:07:00.0: stopping RX ring 0
[ 524.618905] thunderbolt 0000:07:00.0: disabling interrupt at register 0x38200 bit 12 (0x1001 -> 0x1)
[ 524.618909] thunderbolt 0000:07:00.0: stopping TX ring 0
[ 524.618911] thunderbolt 0000:07:00.0: disabling interrupt at register 0x38200 bit 0 (0x1 -> 0x0)
[ 524.618914] thunderbolt 0000:07:00.0: control channel stopped
[ 524.618915] thunderbolt 0000:07:00.0: suspend finished
[ 524.619320] xhci_hcd 0000:00:14.0: System wakeup enabled by ACPI
[ 524.658498] PM: noirq suspend of devices complete after 39.977 msecs
[ 524.658754] ACPI: Preparing to enter system sleep state S3
[ 524.794534] ACPI : EC: EC stopped
[ 524.794534] PM: Saving platform NVS memory
[ 524.794536] Disabling non-boot CPUs ...
[ 524.795725] smpboot: CPU 1 is now offline
[ 524.807921] smpboot: CPU 2 is now offline
[ 524.819911] smpboot: CPU 3 is now offline
[ 524.832530] ACPI: Low-level resume complete
[ 524.832603] ACPI : EC: EC started
[ 524.832603] PM: Restoring platform NVS memory
[ 524.833028] Enabling non-boot CPUs ...
[ 524.852834] x86: Booting SMP configuration:
[ 524.852835] smpboot: Booting Node 0 Processor 1 APIC 0x2
[ 524.863122] cache: parent cpu1 should not be sleeping
[ 524.863910] CPU1 is up
[ 524.880888] smpboot: Booting Node 0 Processor 2 APIC 0x1
[ 524.884775] cache: parent cpu2 should not be sleeping
[ 524.884864] CPU2 is up
[ 524.908765] smpboot: Booting Node 0 Processor 3 APIC 0x3
[ 524.916146] cache: parent cpu3 should not be sleeping
[ 524.916490] CPU3 is up
[ 524.920386] ACPI: Waking up from system sleep state S3
[ 525.008898] xhci_hcd 0000:00:14.0: System wakeup disabled by ACPI
[ 525.024860] thunderbolt 0000:07:00.0: resuming...
[ 525.024862] thunderbolt 0000:07:00.0: control channel starting...
[ 525.024863] thunderbolt 0000:07:00.0: starting TX ring 0
[ 525.024867] thunderbolt 0000:07:00.0: enabling interrupt at register 0x38200 bit 0 (0x0 -> 0x1)
[ 525.024868] thunderbolt 0000:07:00.0: starting RX ring 0
[ 525.024872] thunderbolt 0000:07:00.0: enabling interrupt at register 0x38200 bit 12 (0x1 -> 0x1001)
[ 525.024875] thunderbolt 0000:07:00.0: resetting switch at 0
[ 525.025439] thunderbolt 0000:07:00.0: 0: resuming switch
[ 525.061153] thunderbolt 0000:07:00.0: resume finished
[ 525.061160] PM: noirq resume of devices complete after 52.395 msecs
[ 525.066725] PM: early resume of devices complete after 5.518 msecs
[ 525.096662] sd 1:0:0:0: [sdb] Starting disk
[ 525.126085] thunderbolt 0000:07:00.0: resetting error on 0:b.
[ 525.126097] thunderbolt 0000:07:00.0: 0:b: hotplug: scanning
[ 525.126098] thunderbolt 0000:07:00.0: resetting error on 0:c.
[ 525.126099] thunderbolt 0000:07:00.0: 0:b: hotplug: no switch found
[ 525.126103] thunderbolt 0000:07:00.0: 0:c: hotplug: scanning
[ 525.126103] thunderbolt 0000:07:00.0: 0:c: hotplug: no switch found
[ 525.149090] usb 1-3: ep 0x86 - ...

[penalvch (penalvch)]

Michael Gratton, could you please test the latest mainline kernel (4.4) and advise to the results?

[Michael Gratton (mjog)]

Still happens with: 4.4.0-040400rc8-generic from the mainline PPA (there is a non RC 4.4 there, but it's older than RC8 so I used that instead).

These errors are reported now:

> [ 11.924171] usb 2-3: device not accepting address 2, error -62
> [ 16.832609] usb 1-3: device descriptor read/64, error -110

Also, I worked out how to reliably reproduce the related issues - the long pause at boot, the errors above, and suspend immediately resuming if wakeups from XHCI are not disabled: Just do a cold boot, i.e. from power on. Warm boot show none of these symptoms.

[penalvch (penalvch)]

Michael Gratton, 4.4 is not older than 4.4-rc8. Its time stamp is earlier because of changes made to the folder, not due to chronology.

[Michael Gratton (mjog)]

No change with it regardless:

> $ uname -a
> Linux payens 4.4.0-040400-generic #201601101930 SMP Mon Jan 11 00:32:41 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

Full dmesg is attached. Note this ~4s pause:

> [ 2.809149] clocksource: Switched to clocksource tsc
> [ 6.505235] xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command

This ~5s pause:

> [ 6.637271] usb 1-5: new full-speed USB device number 3 using xhci_hcd
> [ 11.721541] xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command

And this ~6s pause:

> [ 11.925569] usb 2-3: device not accepting address 2, error -62
> [ 18.395816] NET: Registered protocol family 38

[penalvch (penalvch)]

Michael Gratton, the issue you are reporting is an upstream one. Could you please report this problem following the instructions verbatim at https://wiki.ubuntu.com/Bugs/Upstream/kernel to the appropriate mailing list (TO Mathias Nyman CC linux-usb)?

Please provide a direct URL to your post to the mailing list when it becomes available so that it may be tracked.

Thank you for your understanding.

[Johannah Sprinz (neothethird)]

The same issue seems to be present on Macbook Pro 11: http://askubuntu.com/questions/895849/macbook-screen-turns-back-on-after-suspend

[Kai-Heng Feng (kaihengfeng)]

Hi NeoTheThird,

First, does this happen on latest mainline kernel?
If yes, then please do the following -
Find all devices under XHCI hub by issueing `lsusb -t`, here's what on my laptop:
$ lsusb -t
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/11p, 480M
    |__ Port 3: Dev 2, If 0, Class=Wireless, Driver=btusb, 12M
    |__ Port 3: Dev 2, If 1, Class=Wireless, Driver=btusb, 12M
    |__ Port 4: Dev 3, If 0, Class=Human Interface Device, Driver=usbhid, 12M
    |__ Port 5: Dev 10, If 0, Class=Video, Driver=uvcvideo, 480M
    |__ Port 5: Dev 10, If 1, Class=Video, Driver=uvcvideo, 480M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/3p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/8p, 480M

There are two modules under 'xchi_hcd', 'btusb' and 'uvcvideo'.

Please execute `sudo modprobe -r X`, replace X with modules under xhci_hcd, 'btusb' & 'uvcvideo' in my case.

Suspend and check if this issue persists.

[Selwyn (siilwyn-deactivatedaccount)]

Still happens on Ubuntu 18.10 (kernel 4.18.0-13) using a MacBook Pro 2015.

[penalvch (penalvch)]

Selwyn (siilwyn), it will help immensely if you use Ubuntu with the computer the problem is reproducible with and file a new report via a terminal to provide necessary debugging logs:
ubuntu-bug linux

Please feel free to subscribe me to it.

[penalvch (penalvch)]

Michael Gratton:

1) To keep this relevant to upstream, one would want to periodically check for, and test the latest mainline kernel (now 5.0-rc2) as it is released. Could you please advise to the results?

2) Did you contact upstream as noted in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1507472/comments/19 ?