[MacBookPro11,1] Won't suspend twice consecutively

[Albert]

I cannot make a MacBookPro 11,1 suspend. When putting the lid down, acpi_listen prints:
button/lid LID close
button/lid LID open

... so the lid is signalling correctly. Upon opening, the screensaver prompt is present, and typing in the password brings me back to the desktop. Nothing is found in dmesg.

When choosing "suspend" from the top-right power menu, the screen goes black and shortly lights up again, showing the screensaver login prompt. Typing in the password brings me back to the desktop as if nothing had happened.

To remark that the power menu in the System Settings shows sometimes "Suspend" as greyed out.

WORKAROUND: Disabling wakeup from USB (the XHC1 setting) resulted in multiple sleep/resume cycles working flawlessly.

---
ApportVersion: 2.14.1-0ubuntu3.6
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC1: albert 2149 F.... pulseaudio
 /dev/snd/controlC0: albert 2149 F.... pulseaudio
CurrentDesktop: Unity
DistroRelease: Ubuntu 14.04
EcryptfsInUse: Yes
InstallationDate: Installed on 2014-09-16 (86 days ago)
InstallationMedia: Ubuntu 14.04.1 LTS "Trusty Tahr" - Release amd64 (20140722.2)
MachineType: Apple Inc. MacBookPro11,1
NonfreeKernelModules: wl
Package: linux (not installed)
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.13.0-43-generic root=UUID=1fe82ec9-9c83-4e33-9506-2f7afb8d9d64 ro libata.force=noncq quiet splash vt.handoff=7
ProcVersionSignature: Ubuntu 3.13.0-43.72-generic 3.13.11.11
RelatedPackageVersions:
 linux-restricted-modules-3.13.0-43-generic N/A
 linux-backports-modules-3.13.0-43-generic N/A
 linux-firmware 1.127.10
Tags: trusty
Uname: Linux 3.13.0-43-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
_MarkForUpload: True
dmi.bios.date: 02/12/2014
dmi.bios.vendor: Apple Inc.
dmi.bios.version: MBP111.88Z.0138.B07.1402121134
dmi.board.asset.tag: Base Board Asset Tag#
dmi.board.name: Mac-189A3D4F975D5FFC
dmi.board.vendor: Apple Inc.
dmi.board.version: MacBookPro11,1
dmi.chassis.type: 10
dmi.chassis.vendor: Apple Inc.
dmi.chassis.version: Mac-189A3D4F975D5FFC
dmi.modalias: dmi:bvnAppleInc.:bvrMBP111.88Z.0138.B07.1402121134:bd02/12/2014:svnAppleInc.:pnMacBookPro11,1:pvr1.0:rvnAppleInc.:rnMac-189A3D4F975D5FFC:rvrMacBookPro11,1:cvnAppleInc.:ct10:cvrMac-189A3D4F975D5FFC:
dmi.product.name: MacBookPro11,1
dmi.product.version: 1.0
dmi.sys.vendor: Apple Inc.

[Albert (sapristi)]

Further info: turns out that the system is running without swap space:

$ sudo blkid
/dev/sda2: UUID="<the-UUID-here>" TYPE="ext4"

... lists only one, when it shoud list also the swap partition. So:

$ sudo swapon -a
swapon: /dev/mapper/cryptswap1: stat failed: No such file or directory

The /etc/fstab lists the swap partition under /dev/mapper/cryptswap1. While I never chose to encrypt swap, during the installation I did choose to encrypt my home directory. Perhaps the installer encrypted swap as well, and that is creating the problem with the lack of suspend and hibernate.

Attempting to run "sudo swapon -U <UUID>" fails as well. I used the UUID listed in a comment in fstab.

Any specific solutions to this problem? Perhaps this would solve the suspend/hibernate as well.

Thank you.

[Albert (sapristi)]

I have fixed the problem with swap space by editing the file /etc/crypttab to use the device directly (e.g. /dev/sda4) rather than the UUID (which did not exist under /dev/disk/by-uuid.

While swap space is now operational, suspend and hibernate still fail as reported. Would appreciate advice in addressing this issue.

Thank you.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Albert (sapristi)]

I have found a workaround to this bug. In other words, suspend now works in MaxBookPro 11,1 if you do:

1. Push e.g. control+alt+fn+F1 to go to a tty.
2. Close the laptop lid.

After about 3 seconds, the laptop sleeps. Hurray!

Upon resume, the tty had this message, which is also present in dmesg:

[ 2705.633359] [drm:hsw_unclaimed_reg_clear] *ERROR* Unknown unclaimed register
before writing to 203c

For context, the dmesg around it says:

[ 2705.632613] PM: Entering mem sleep
[ 2705.632648] Suspending console(s) (use no_console_suspend to debug)
[ 2705.633049] sd 1:0:0:0: [sda] Synchronizing SCSI cache
[ 2705.633286] mei_me 0000:00:16.0: H_RDY is not cleared 0x80141418
[ 2705.633359] [drm:hsw_unclaimed_reg_clear] *ERROR* Unknown unclaimed register
before writing to 203c
[ 2706.807381] sd 1:0:0:0: [sda] Stopping disk
[ 2706.838212] PM: suspend of devices complete after 1206.641 msecs
[ 2706.854177] PM: late suspend of devices complete after 15.978 msecs

Note that directly closing the lid from Unity results in a suspend immediately followed by a resume.

Note that this workaround did not work a few days ago. So perhaps a combination of having swap enabled (with the workaround reported earlier, above) and a package that got updated or installed new resulted in the ability to run the above suspend workaround.

Also, the very nature of the workaround suggests that it is related to the graphics card, or the unity desktop itself, somehow interfering with the suspend sequence.

[Albert (sapristi)]

Turns out, the work around doesn't work anymore in the MacBookPro 11,1, but works consistently well in another model, the MacBookPro 8,3. Different chips, different graphics cards, same Ubuntu 14.04.

[Albert (sapristi)]

Update: finally figured out the pattern.

With the thunderbolt ethernet adapter plugged in, the MacBookPro 11,1 laptop won't suspend at all.

Without it, the laptop suspends every time.

Given that the thunderbolt ethernet adapter cannot be hotplugged, best is to leave it unused for now. A USB ethernet adapter works just fine and does not interfere with suspend or resume.

Therefore a permanent workaround has been found for this issue. The MacBookPro 11,1 can now suspend and resume flawlessly, simply by closing and opening the lid.

Hibernate, though, still doesn't work.

[Albert (sapristi)]

To add here that if the USB ethernet adapter is plugged in and the laptop lid is closed, and then the adapter is unplugged, the laptop will wake up within 20 seconds or so. Closing the lid again suspends it without issue.

In other words, remove the USB ethernet adapter prior to putting the laptop to sleep.

[Nils Fredrik Gjerull (nfg)]

The issue with thunderbolt might be fixed in the upcoming kernel release (3.18)
See: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/?id=refs/tags/v3.18-rc4&qt=grep&q=thunderbolt

[Albert (sapristi)]

While I'd love to try out the new kernel, I do not know how to install the proprietary wireless driver Broadcomm 802.11 along with that kernel. Is there perhaps a guide somewhere that details all the necessary commands? Thanks in advance.

[Albert (sapristi)]

apport information

[Albert (sapristi)]

apport information

[Albert (sapristi)]

apport information

[Albert (sapristi)]

apport information

[Albert (sapristi)]

apport information

[Albert (sapristi)]

apport information

[Albert (sapristi)]

apport information

[Albert (sapristi)]

apport information

[Albert (sapristi)]

apport information

[Albert (sapristi)]

apport information

[Albert (sapristi)]

apport information

[Albert (sapristi)]

apport information

[Albert (sapristi)]

apport information

[Albert (sapristi)]

apport information

[Albert (sapristi)]

apport information

[Albert (sapristi)]

apport information

[penalvch (penalvch)]

Albert, could you please test the latest upstream kernel available from the very top line at the top of the page (the release names are irrelevant for testing, and please do not test the daily folder) following https://wiki.ubuntu.com/KernelMainlineBuilds ? It will allow additional upstream developers to examine the issue.

If the test 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 bug is fixed in the mainline kernel, please add the following tags:
kernel-fixed-upstream
kernel-fixed-upstream-VERSION-NUMBER

where VERSION-NUMBER is the version number of the kernel you tested exactly shown as:
kernel-fixed-upstream-3.18

This can be done by clicking on the yellow circle with a black pencil icon next to the word Tags located at the bottom of the bug description.

If the mainline kernel does not fix this bug, please add the following tags:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-VERSION-NUMBER

Once testing of the upstream kernel is complete, please mark this bug's Status as Confirmed. Please let us know your results. Thank you for your understanding.

[Albert (sapristi)]

Hi Christopher,

I installed 3.18-vivid from http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.18-vivid/, and the results are concerning:

First I rebooted and booted fine into 3.18. I run "uname -a" just to be sure, and listed 3.18 as the current kernel.

Of course I didn't have wifi with 3.18, so I wanted to reboot to go back to 3.13.43. Upon reboot I pushed "del" to make grub show its menu, chose 3.43 and then it got stuck with a blinking cursor.

So I shut down the machine, booted again and letting it go into 3.18: this time it dit NOT boot, to my surprise. I would appreciate help in understanding what had changed.

Upon reboot using the "failsafe" option, I saw that the booting process got stuck at SMP #1. So I shutdown, rebooted and edited the grub kernel options to include the "nosmp" flag, and that booted into 3.18 just fine--from which I am writing this (via USB-ethernet).

Haven't tested yet if the thunderbolt ethernet and suspend work.

Before I engage into further reboots that could get stuck, I would appreciate assistance in understanding why the second time 3.18 needed the "nosmp" flag, and how can this be addressed.

Additionally I would appreciate help in understanding why grub cannot boot the old 3.13.43 kernel when chosen from the grub menu. I recall this issue when I first installed Ubuntu into thhis macbook pro 11,1: only the default menu option would boot from grub; choosing from the list of available kernels did not work, likely because of the SMP issue.

Thanks in advance for your insight.

[Albert (sapristi)]

To add here that the only way I know to go back to a working multi-CPU ubuntu is to remove the 3.18 kernel and let the default be the prior 3.13.43. So I "sudo apt-get remove" the 3.18, and at the end of the command, which executes successfully, I see:

The link /vmlinuz is a damaged link
Removing symbolic link vmlinuz
 you may need to re-run your boot loader[grub]
The link /initrd.img is a damaged link
Removing symbolic link initrd.img
 you may need to re-run your boot loader[grub]

So I re-run "sudo update-grub", which runs successfully and without error messages.

Perhaps this was part of the boot issue.

[Albert (sapristi)]

Christopher, I have not been able to perform all tests--this laptop is my main work computer. I hope to be able to do so (with thunderbolt ethernet adapter, etc) over the Christmas break.

In the meanwhile, I need to resolve the boot issue with grub, to more easily be able to switch between kernels. Would installing rEFInd help? Can it be done once grub is in place, replacing grub? Any advice here would be very helpful.

[Albert (sapristi)]

Christopher,

with 3.18-vivid (3.18.0-031800_3.18.0-031800.201412071935):

The good news is that thunderbold-ethernet is plug and play (no longer needs to reboot with thunderbold plugged in). Unplugging it and plugging it again works too: fully plug and play.

The bad news is that the computer cannot suspend at all:

A. When using the top-right power button and choosing suspend, the screen goes dark but quickly brightens.
B. When closing the lid, the screen remains dark but it is actually not suspended (can been seen in dmesg).

All 4 CPUs are recognized after the first reboot--but this was the case before too. Don't know what will happen in the next reboot.

The dmesg (attached) contains, in this order, the normal boot sequence, one attempt to suspend from the power menu, and one attempt to suspend by closing the lid, and the plug-and-play action of the thunderbold-ethernet adapter.

The relevant part of dmesg from the point in time when I initiated the suspend sequence by lowering the lid (notice the ERROR):

[ 114.901412] PM: Syncing filesystems ... done.
[ 114.907053] PM: Preparing system for mem sleep
[ 114.907164] Freezing user space processes ... (elapsed 0.617 seconds) done.
[ 115.523970] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
[ 115.525235] PM: Entering mem sleep
[ 115.525263] Suspending console(s) (use no_console_suspend to debug)
[ 115.525651] [drm:intel_uncore_check_errors] *ERROR* Unclaimed register before interrupt
[ 115.525743] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[ 116.700502] sd 0:0:0:0: [sda] Stopping disk
[ 116.730544] PM: suspend of devices complete after 1206.337 msecs
[ 116.778370] PM: late suspend of devices complete after 47.867 msecs
[ 116.778609] thunderbolt 0000:07:00.0: suspending...
[ 116.779236] xhci_hcd 0000:00:14.0: System wakeup enabled by ACPI
[ 116.779247] thunderbolt 0000:07:00.0: stopping RX ring 0
[ 116.779251] thunderbolt 0000:07:00.0: disabling interrupt at register 0x38200 bit 12 (0x1001 -> 0x1)
[ 116.779256] thunderbolt 0000:07:00.0: stopping TX ring 0
[ 116.779259] thunderbolt 0000:07:00.0: disabling interrupt at register 0x38200 bit 0 (0x1 -> 0x0)
[ 116.779262] thunderbolt 0000:07:00.0: control channel stopped
[ 116.779263] thunderbolt 0000:07:00.0: suspend finished
[ 116.794430] PM: noirq suspend of devices complete after 16.074 msecs
[ 116.794701] ACPI: Preparing to enter system sleep state S3
[ 116.826297] PM: Saving platform NVS memory
[ 116.826298] Disabling non-boot CPUs ...
[ 116.826331] intel_pstate CPU 1 exiting
[ 116.827460] kvm: disabling virtualization on CPU1
[ 116.827464] smpboot: CPU 1 is now offline
[ 116.827752] intel_pstate CPU 2 exiting
[ 116.828885] kvm: disabling virtualization on CPU2
[ 116.828892] smpboot: CPU 2 is now offline
[ 116.829180] intel_pstate CPU 3 exiting
[ 116.830278] kvm: disabling virtualization on CPU3
[ 116.830288] smpboot: CPU 3 is now offline
[ 116.831978] ACPI: Low-level resume complete
[ 116.832042] PM: Restoring platform NVS memory
[ 116.832448] Enabling non-boot CPUs ...
[ 116.832496] x86: Booting SMP configuration:
[ 116.832497] smpboot: Booting Node 0 Processor 1 APIC 0x2
[ 116.84...

[Albert (sapristi)]

As anticipated, the second reboot fails, and needs a third reboot where I add the option "nosmp". The fact that the same kernel can boot well (all 4 CPUs working) or not boot (fails at SMP) depending on the prior boot is incomprehensible to me.

[Albert (sapristi)]

Christopher, thanks for your help so far. Would love to try 3.19 but considering how involved that is given the disfunctional grub, until I find a tutorial on how to address the booting issues I rather not commit more time to this issue.

[Nathan J. Brauer (nathanbrauer)]

Confirm the same problem with MacBookPro11,2

[penalvch (penalvch)]

Nathan J. Brauer, thank you for your comment. So your issue may be dealt with as soon as possible, and so your hardware may be tracked by having necessary debugging information automatically attached, could you please file a new report with Ubuntu by executing the following in a terminal while booted into the default Ubuntu repository kernel via:
ubuntu-bug linux

For more on why this is most helpful, please read the official Ubuntu documentation from the respective Ubuntu developer groups, and triage teams:
Ubuntu Bug Control and Ubuntu Bug Squad: https://wiki.ubuntu.com/Bugs/BestPractices
Ubuntu Kernel Team: https://wiki.ubuntu.com/KernelTeam/KernelTeamBugPolicies
https://wiki.ubuntu.com/Kernel/Policies/DuplicateBugs
Ubuntu Community: https://help.ubuntu.com/community/ReportingBugs

When opening up the new report, please feel free to subscribe me to it.

Thank you for your understanding.

[Albert (sapristi)]

Hi Christopher,
I've tested 3.19.0-rc6-vivid and it works "well", as in:

1) Wifi does not work.
2) All cores are recognized without incident.
3) Sleep works, but just like 3.13.43:
   a) immediately after having booted, suspend works.
   b) after resume from suspend, suspend seems to work but fails after about 20 seconds and then, if one lifts the lid slightly (enough to light up the screen) and immediately closes it, then suspend works.

[penalvch (penalvch)]

Albert, just to clarify:
>"1) Wifi does not work."

It won't, as the proprietary wifi driver wl is not supported with the mainline kernel.

>"3) Sleep works, but just like 3.13.43: a) immediately after having booted, suspend works. b) after resume from suspend, suspend seems to work but fails after about 20 seconds and then, if one lifts the lid slightly (enough to light up the screen) and immediately closes it, then suspend works."

I don't understand what you mean here. Could you please re-word?

[Albert (sapristi)]

Christopher,

1. Boot
2. Do some work
3. Lower the lid to suspend: works
4. Lift the lid to resume
5. Do some work
6. Lower the lid to suspend: fails, taking a few seconds to light up the apple to show that it failed.
7. Lift the lid a bit and quickly lower it: suspends as it should.

So suspend can work, but there are issues. It's not like it works only every other time: to make suspen work beyond the first time, one has to do the fast lid up/down sequence.

[penalvch (penalvch)]

Albert, just to clarify, the first suspend always resumes fine, but the second attempt always fails correct?

[Albert (sapristi)]

Christopher: that is correct.

[penalvch (penalvch)]

Albert, could you please provide the missing information from https://wiki.ubuntu.com/DebuggingKernelSuspend ?

[Albert (sapristi)]

A note: this page

  https://lists.ubuntu.com/archives/kernel-team/2014-January/037052.html

... claims that there is wakeup bug in ACPI for Haswell machines from vendor HP. That bug could be the same as this, given that this macbook 11,1 also has a Haswell chipset.

And out of the blue I received an email from someone reading this bug thread suggesting a potential solution to this issue.

Verbatim:

#####
I googled around and found a solution which worked for me:
echo XHC1 >/proc/acpi/wakeup

To verify the change just type:
cat /proc/acpi/wakeup

And now this machine sleeps until the lid is opened!

You may also need to disable the wakeup of usb devices like this:
for usb in /sys/bus/usb/devices/*/power/wakeup;
do
       echo disabled > $usb;
done
#####

I have not tried it yet as I would like to learn more about /proc/acpi/wakeup
So far I haven't found the manual page yet.

[Albert (sapristi)]

Additionally the following bug seems related to this:

  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1391476

Christopher, you also replied to that bug. Do you think it's the same?

What is the XHC1 under /proc/acpi/wakeup ? Google seems to not find a manual page for wakeup.

Bug 1391476 claims it's a USB wakeup issue. I tend to agree from incidental observations, e.g. plugging/unplugging USB devices to a sleeping computer (my macbook pro 11,1) should not wake it up, but it does.

[Albert (sapristi)]

Christopher, I am almost ready to close this bug: disabling wakeup from USB (the XHC1 setting) resulted in multiple sleep/resume cycles working flawlessly.

[penalvch (penalvch)]

Albert, when providing the information requested in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1371159/comments/45 please ensure you are using 3.19-rc7 (not rc6).

[Launchpad Janitor (janitor)]

[Expired for linux (Ubuntu) because there has been no activity for 60 days.]