[MacBookPro11,1] Laptop wakes up while lid closed

[Erlenmayr]

Same behavior when using pm-suspend. It is hard to notice whether the laptop wakes up, especially because that does not always happen immediately. Getting to sleep takes up to 30 seconds. Hardware damage may be a result of waking up while lid is closed, for example if laptop is transported in a bag. I suspect that the problem comes from the Intel video driver. See extract from kern.log.

WORKAROUND: Disable XHC1 in /proc/acpi/wakeup.

ProblemType: Bug
DistroRelease: Ubuntu 14.10
Package: linux-image-3.16.0-24-generic 3.16.0-24.32
ProcVersionSignature: Ubuntu 3.16.0-24.32-generic 3.16.4
Uname: Linux 3.16.0-24-generic x86_64
NonfreeKernelModules: wl
ApportVersion: 2.14.7-0ubuntu8
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: stephan 2266 F.... pulseaudio
 /dev/snd/controlC1: stephan 2266 F.... pulseaudio
CurrentDesktop: Unity
CurrentDmesg: Error: command ['sh', '-c', 'dmesg | comm -13 --nocheck-order /var/log/dmesg -'] failed with exit code 1: comm: /var/log/dmesg: Permission denied
Date: Tue Nov 11 12:11:02 2014
EcryptfsInUse: Yes
InstallationDate: Installed on 2014-10-08 (33 days ago)
InstallationMedia: Ubuntu 14.04.1 LTS "Trusty Tahr" - Release amd64 (20140722.2)
Lsusb:
 Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
 Bus 001 Device 003: ID 05ac:0259 Apple, Inc.
 Bus 001 Device 006: ID 05ac:8289 Apple, Inc.
 Bus 001 Device 002: ID 0a5c:4500 Broadcom Corp. BCM2046B1 USB 2.0 Hub (part of BCM2046 Bluetooth)
 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
MachineType: Apple Inc. MacBookPro11,1
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.16.0-24-generic.efi.signed root=UUID=d3ef8cca-2c30-46c5-88cc-a5f523abf8ac ro quiet splash vt.handoff=7
SourcePackage: linux
UpgradeStatus: Upgraded to utopic on 2014-10-17 (24 days ago)
WifiSyslog:

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.
---
ApportVersion: 2.14.7-0ubuntu8
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/pcmC1D0p: stephan 2266 F...m pulseaudio
 /dev/snd/controlC0: stephan 2266 F.... pulseaudio
 /dev/snd/controlC1: stephan 2266 F.... pulseaudio
CurrentDesktop: Unity
CurrentDmesg: Error: command ['sh', '-c', 'dmesg | comm -13 --nocheck-order /var/log/dmesg -'] failed with exit code 1: comm: /var/log/dmesg: Permission denied
DistroRelease: Ubuntu 14.10
EcryptfsInUse: Yes
InstallationDate: Installed on 2014-10-08 (34 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.16.0-24-generic.efi.signed root=UUID=d3ef8cca-2c30-46c5-88cc-a5f523abf8ac ro quiet splash vt.handoff=7
ProcVersionSignature: Ubuntu 3.16.0-24.32-generic 3.16.4
Tags: utopic
Uname: Linux 3.16.0-24-generic x86_64
UpgradeStatus: Upgraded to utopic on 2014-10-17 (24 days ago)
UserGroups: sudo
WifiSyslog:

_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.

[Erlenmayr (erlenmayr)]

It happens with kernels 3.16.0-24 and -25, as well as with current stable version "2:2.99.914-1~exp1ubuntu4" as well as in "proposed" version "2:2.99.914-1~exp1ubuntu4.1".

It does not happen deterministically, some times sleeping works. But it seems to wake up with closed lid much more often now than for example one month ago.

[Erlenmayr (erlenmayr)]

With "2:2.99.914-1~exp1ubuntu4" and "2:2.99.914-1~exp1ubuntu4.1" I mean the xserver-xorg-video-intel package.

[Brad Figg (brad-figg)]

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 1391476

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[Erlenmayr (erlenmayr)]

apport information

[Erlenmayr (erlenmayr)]

apport information

[Erlenmayr (erlenmayr)]

apport information

[Erlenmayr (erlenmayr)]

apport information

[Erlenmayr (erlenmayr)]

apport information

[Erlenmayr (erlenmayr)]

apport information

[Erlenmayr (erlenmayr)]

apport information

[Erlenmayr (erlenmayr)]

apport information

[Erlenmayr (erlenmayr)]

apport information

[Erlenmayr (erlenmayr)]

apport information

[Erlenmayr (erlenmayr)]

apport information

[Erlenmayr (erlenmayr)]

apport information

[Erlenmayr (erlenmayr)]

apport information

[Erlenmayr (erlenmayr)]

apport information

[penalvch (penalvch)]

Erlenmayr, thank you for reporting this and helping make Ubuntu better. Could you please return your computer to the defaults (ex. no PPAs, etc.) and then test the latest upstream kernel available from the very top line at the top of the page (the release names are irrelevant for testing in your release) 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-rc4

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.

[Erlenmayr (erlenmayr)]

I have no PPA etc. installed. But upstream kernel builds are not easy to test as Macbook users depend on the restricted Broadcom Wifi driver which (from repos) does not work with the mainline builds.

Also it is very unpleasant to install unsigned kernel packages from a HTTP server on a production system.

But the biggest problem is that it isn't a deterministic bug. Some times it works, some times it does not. I think that it works most of the time with the versions if proposed updates are decativated. With the versions from proposed updates, it seems to work almost never. I think that the update of xserver-xorg-video-intel is also relevant.

The other issue, why it is hard to test, is kind of a separate bug. Even if suspend works, it takes half a minute until sleep state is actually reached (indicated by the keyboard backlight turning off). This is a problem, because you notice the failure of the suspend operation half a minute later. On today's super silent laptops you cannot even tell from the outside with closed lid whether it is running or sleeping. You only may see after many minutes that the computer is getting very warm.

For regular users this hell. They close their lid, everything seems fine. They put it into their bag, everything seems fine. After hours they notive that their computer is hot and battery dead.

[Joseph Salisbury (jsalisbury)]

Did this issue start happening after an update/upgrade? Was there a kernel version where you were not having this particular problem? This will help determine if the problem you are seeing is the result of a regression, and when this regression was introduced. If this is a regression, we can perform a kernel bisect to identify the commit that introduced the problem.

[bJXjLjEHIaWT0tFd (bjxjljehiawt0tfd-deactivatedaccount)]

I may be seeing the same issue. My laptop suspends fine and also wakes up without a problem – however it occasionally wakes up even if the lid remains closed. There are no ethernet cable or external input devices attached. I'll try to attach log information via apport.

[bJXjLjEHIaWT0tFd (bjxjljehiawt0tfd-deactivatedaccount)]

As per the apport-collect recommendation, instead of appending my information here, I created duplicate report #1392067.

[penalvch (penalvch)]

Niels Ganser, while it is appreciated that you didn't apport-collect to a report you are not the original reporter of, and instead filed a new report, it is not considered a duplicate of this one at this time. Please make all future comments in the report you filed so your issue is dealt with as quickly as possible.

Thank you for your understanding.

Helpful bug reporting tips:
https://wiki.ubuntu.com/ReportingBugs

[Erlenmayr (erlenmayr)]

Have you noticed my file sleepfail.log which was attached by myself, not by apport?

[Erlenmayr (erlenmayr)]

@Joseph: The only thing I am pretty sure of is that it did not happen in Trusty. But that would not help to perform a kernel bisect.

I think that the it happens less often with 3.16.0-24 than with 3.16.0-25, but I have no real data because it happens nondeterministically. On -24 it only seems to happen if the last suspend was a short time (less than half an hour) ago, while it seems to work mostly if last suspend is long ago. With 3.16.0-25 (from proposed updates repository) it seems to work almost never, but some single times it worked.

Btw. there are no freezes on wake-up, the only problem are unplanned wake-ups.

BTW: Did the kernel team backport the new Thunderbolt behavior for Apple devices from kernel 3.17?

[Erlenmayr (erlenmayr)]

Nov 18 19:44:12 jeltz kernel: [ 4289.690714] ACPI: Preparing to enter system sleep state S3
Nov 18 19:44:12 jeltz kernel: [ 4292.103988] [drm:hsw_unclaimed_reg_clear] *ERROR* Unknown unclaimed register before writing to c7204
Nov 18 19:44:12 jeltz kernel: [ 4292.103989] [drm:hsw_unclaimed_reg_check] *ERROR* Unclaimed write to c7204
Nov 18 19:44:12 jeltz kernel: [ 4329.649997] PM: Saving platform NVS memory

I see this in my /var/log/kern.log every single time. I still think DRM/Video is the problem.

[Erlenmayr (erlenmayr)]

Some updates.

First:
I tried mainline now, and the issue is the same with 3.17.1-utopic. (BTW I tested that kernel without bcmwl proprietary driver.)

Second:
I took a look at /proc/acpi/wakeup. It turned out that LID0 and XHC1 were able to wake up the computer. I disabled XHC1 now, and after that the computer never woke up on its own again. Power button and lid opening still work to wake up the computer.

Here I want to rise a question: Why is USB allowed to wake up a laptop with closed lid in the first place? You should disable it by default (or add an option to the settings menu).

from /proc/acpi/wakeup:
XHC1 S3 *disabled pci:0000:00:14.0

from lspci:
00:14.0 USB controller: Intel Corporation 8 Series USB xHCI HC (rev 04)

[penalvch (penalvch)]

Erlenmayr, could you please test the latest mainline kernel (3.18-rc5) and advise to the results?

[Erlenmayr (erlenmayr)]

@Chris:

With the 3.18 kernels, the "suspending takes almost a minute" issue disappeared. This means that after invoking pm-suspend, the computer is actually sleeping within a second or two.

The issue of "waking up while lid is closed" is still the same. You only see it happen earlier now and don't have to wait for a minute to test it. (With XHC1 wakeup disabled, everything is fine.)

[Erlenmayr (erlenmayr)]

@Chris:

"generic" 3.18.0-rc5 and 3.18.0-rc6 from here:

http://kernel.ubuntu.com/~kernel-ppa/mainline/

[penalvch (penalvch)]

Erlenmayr, the next step is to fully commit bisect from kernel 3.13 to 3.16 in order to identify the last good kernel commit, followed immediately by the first bad one. This will allow for a more expedited analysis of the root cause of your issue. Could you please do this following https://wiki.ubuntu.com/Kernel/KernelBisection ? Please note, finding adjacent kernel versions is not fully commit bisecting.

Thank you for your understanding.

Helpful bug reporting tips:
https://wiki.ubuntu.com/ReportingBugs

[Bertails (bertails)]

I have the very same problem.

I am still on Ubuntu 13.10, very standard installation. I can't remember when it started to behave like that, I just know that it used to work some time ago. Now I get the super-hot-laptop-in-bag-issue as well :-/

$ uname -r
3.13.0-031300rc8-generic

[penalvch (penalvch)]

Bertails, thank you for your comment. Saucy is EoL as of July 17, 2014. For more on this please see https://wiki.ubuntu.com/Releases . If you have this issue in a supported release, and so your hardware and problem may be tracked, could you please file a new report with Ubuntu by executing the following in a terminal while booted into the default Ubuntu kernel (not a mainline one) via:
ubuntu-bug linux

For more on this, please read the official Ubuntu documentation:
Ubuntu Bug Control and Ubuntu Bug Squad: https://wiki.ubuntu.com/Bugs/BestPractices#X.2BAC8-Reporting.Focus_on_One_Issue
Ubuntu Kernel Team: https://wiki.ubuntu.com/KernelTeam/KernelTeamBugPolicies#Filing_Kernel_Bug_reports
https://wiki.ubuntu.com/Kernel/Policies/DuplicateBugs
Ubuntu Community: https://help.ubuntu.com/community/ReportingBugs#Bug_reporting_etiquette

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

As well, please do not announce in this report you created a new bug report.

Thank you for your understanding.

Helpful bug reporting tips:
https://wiki.ubuntu.com/ReportingBugs

[Erlenmayr (erlenmayr)]

@Bertrails:

As a quick first solution, try to figure out what devices are allowed to wake up the system:

# cat /proc/acpi/wakeup Device S-state Status Sysfs node
P0P2 S3 *disabled
EC S3 *disabled platform:PNP0C09:00
HDEF S3 *disabled pci:0000:00:1b.0
RP01 S3 *disabled pci:0000:00:1c.0
RP02 S3 *disabled pci:0000:00:1c.1
RP03 S4 *disabled pci:0000:00:1c.2
ARPT S4 *disabled pci:0000:03:00.0
RP05 S3 *disabled pci:0000:00:1c.4
RP06 S3 *disabled pci:0000:00:1c.5
XHC1 S3 *disabled pci:0000:00:14.0
ADP1 S3 *disabled platform:ACPI0003:00
LID0 S3 *enabled platform:PNP0C0D:00

Disable everything except LID. For example I deactivated XHC1 (which is USB3) with this command:
# echo XHC1 > /proc/acpi/wakeup

[Bertails (bertails)]

@Erlenmayr looks like your trick works. Thank you so much.

Looks like this is related to our problem [1].

[1] http://apple.stackexchange.com/questions/105970/macbook-pro-wakes-immediately-after-sleeping

[penalvch (penalvch)]

Bertails, please again see https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1391476/comments/35 .

[Bertails (bertails)]

@penalvch, as stated by @erlenmayr, the bug is the same in 14.04.01.

[Erlenmayr (erlenmayr)]

Now I have edited /proc/acpi/wakeup for four weeks and it did not happen again a single time. It really is the XHC1 (USB3) interface waking up the computer.

My still unanswered question again: Why is this b***** enabled by default in the first place? A decade before this bug I already considered it annoying that sleeping computers could be woken up by key strokes. And now in times of laptops, this is a way to kill hardware. People close their lid and put the computer into a case or bag. It should never wake up. An unintended wakeup is a thousand times worse than a failing wakeup.

[penalvch (penalvch)]

Erlenmayr, the general issue of resuming from suspend while a closed laptop is in a jostling bag is one that wouldn't be unique to Ubuntu, as it affects all hardware and operating systems. I've dealt with folks who have caused hardware failure to a brand new computer due to this. What I've done myself, and suggest to others is hibernate instead of suspend.

However, the disabling keyboard wakeup from suspend would be a fundamental, large scale change that would need to originate upstream, given the implementation would be hardware dependent, and may require a hardware quirk list.

This would appear to be a similar, but distinctly different issue then the one scoped to this report, how you said this is not reproducible in Trusty. If this still remains true, a bisect would still need to occur as previously advised.

[Launchpad Janitor (janitor)]

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

[Martin Klapetek (martin-klapetek)]

I can confirm this bug is still present on MacBook Pro 11,1 and latest mainline kernel 4.5.0,
tested on wily.

Disabling the XHC1 in /proc/acpi/wakeup does seem to prevent the immediate wakeups
but this at the same time disables waking up on opening the lid for me (and LID0 is still
enabled in /proc/acpi/wakeup).

[Martin Klapetek (martin-klapetek)]

Fwiw, there appears to be an upstream bug report at https://bugzilla.kernel.org/show_bug.cgi?id=101681

[Erlenmayr (erlenmayr)]

Still the same problem in 16.04.

Note that this is critical. This can and will cause hardware damage to users, if they have their laptop in a bag and it wakes up. Why is /proc/acpi/wakeup not set to a proper default?

[solitone (solitone)]

This happens also on debian stretch, on a MacBookPro12,1

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
solitone@alan:~$ uname -a
Linux alan 4.9.0-1-amd64 #1 SMP Debian 4.9.6-3 (2017-01-28) x86_64 GNU/Linux
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

WORKAROUND: Disable both XHC1 and LID0 in /proc/acpi/wakeup--XHC1 alone is not enough.

[Erlenmayr (erlenmayr)]

In Ubuntu 17.04, this stopped happening.

[Leo Iannacone (l3on)]

> #49 In Ubuntu 17.04, this stopped happening.

Not true with my MacBookPro12,1.

[Kai-Heng Feng (kaihengfeng)]

Can you guys try mainline again?

[Launchpad Janitor (janitor)]

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

[penalvch (penalvch)]

Erlenmayr, I am closing this report because as per https://bugs.launchpad.net/debian/+bug/1391476/comments/49 the bug has been fixed in the latest development version of Ubuntu.