mbp-2016-linux
mbp-2016-linux copied to clipboard
Dunedan
Linux cannot wake up after closing the lid
I successfully installed Ubuntu 16.04 on my MBP 13,1 and everything went on smoothly. However, I found that if I closed the lid while Linux is running, and I opened it again, nothing would show up. Completely black screen is the only result. This is quite annoying because every time I need to go somewhere else, I can only shut down Linux completely and start it up again somewhere else. Has anyone met the same problem as I have? Any help will be greatly appreciated. Thanks in advance.
Suspend & resume doesn't work. That's a known problem, I believe. In my case, my screen can go back on after waiting for a while, but the NVMe drive doesn't seem to power on properly.
Yes, this is a know problem, see: https://github.com/Dunedan/mbp-2016-linux#suspend--hibernation
While it's not a great solution, the workaround is to disable suspend on lid close. See HandleLidSwitch in man logind.conf.
...
If anybody has the time and inclination to work on this, one suggestion might be to use dtrace to trace the NVMe driver commands in MacOS while the laptop is being suspended and resumed. You'll have to first find appropriate functions to trace (using the fbt provider) and then analyze the commands sent - most likely the special commands are either vendor and/or power-management admin commands.
Another thing that might be easier to try is to modify the DSDT: the _PS3 method in the RP01 scope (search for Scope (RP01) and then scroll down for the _PS3 method) has an if (OSDW()) clause that looks like it powers down the SSD or something - it might be interesting to see if inverting that condition (i.e. if (!OSDW())) avoids the issue (though obviously it wouldn't be a permanent solution).
I did play around with dtrace a bit, but so far couldn't identify any suspicious function which gets called during suspend. :disappointed:
I fixed this issue for my 14,1 for suspend/resume. This is as simple as a setting in the PCI driver, for the nvme storage.
cat 0 > /sys/bus/pci/devices/0000\:01\:00.0/d3cold_allowed
This needs to be done as root, sudo won't allow access on Ubuntu 19.xx. I wrote a simple script and a systemd wrapper for startup - depends multiuser.
I suspect this may work for other modern MBP models, prior to T2-chip introduction. You'll want to use lspci to determine the correct pci device for your specific model.
These fixes work like a charm under Ubuntu/Pop_OS! 19.04 and 19.10 beta.
/etc/systemd/system/fix_sleep.service
# systemd oneshot service to set sleep boolean on Apple Macbook Pro disks
# Original by Pier Lim. Posted at https://kerpanic.wordpress.com/2018/03/13/apple-keyboard-get-function-keys-working-properly-in-ubuntu/
[Unit]
Description=Job that disables sleep from stopping nvme hardware on MBP
[Service]
ExecStart=/sbin/fixsleep
Type=oneshot
RemainAfterExit=yes
[Install]
WantedBy=multi-user.target
/sbin/fixsleep
#!/bin/bash
/bin/echo 0 > /sys/bus/pci/devices/0000\:01\:00.0/d3cold_allowed
@JeremiahCornelius unfortunately this fix doesn't seem to work on a MacBook9,1 :-(
Seems to work for me on a MacBookPro13,1. Maybe we could add that to the README?
Seems to work for me on a MacBookPro13,1. Maybe we could add that to the README?
Sure, just open a PR. :slightly_smiling_face: Would be interesting to see, if this also works for MacBook Pro's with Apple's own NVMe controller.
These fixes work like a charm under Ubuntu/Pop_OS! 19.04 and 19.10 beta.
/etc/systemd/system/fix_sleep.service
# systemd oneshot service to set sleep boolean on Apple Macbook Pro disks # Original by Pier Lim. Posted at https://kerpanic.wordpress.com/2018/03/13/apple-keyboard-get-function-keys-working-properly-in-ubuntu/ [Unit] Description=Job that disables sleep from stopping nvme hardware on MBP [Service] ExecStart=/sbin/fixsleep Type=oneshot RemainAfterExit=yes [Install] WantedBy=multi-user.target/sbin/fixsleep
#!/bin/bash /bin/echo 0 > /sys/bus/pci/devices/0000\:01\:00.0/d3cold_allowed
Works for my Macbook Pro 14,1 (13" 2017 without touchbar) running Ubuntu 19.10. However it takes about 10-20 seconds until the lockscreen shows up. Is there a fix for this behavior?
Works for my Macbook Pro 14,1 (13" 2017 without touchbar) running Ubuntu 19.10. However it takes about 10-20 seconds until the lockscreen shows up. Is there a fix for this behavior?
I haven't yet figured what takes resume so comparatively long to complete. As is, it's completely usable, turning Linux on this MBP from being a hobby-project, to a real tool.
any suggestion about how to do this when booting from usb ?
These fixes work like a charm under Ubuntu/Pop_OS! 19.04 and 19.10 beta. /etc/systemd/system/fix_sleep.service
# systemd oneshot service to set sleep boolean on Apple Macbook Pro disks # Original by Pier Lim. Posted at https://kerpanic.wordpress.com/2018/03/13/apple-keyboard-get-function-keys-working-properly-in-ubuntu/ [Unit] Description=Job that disables sleep from stopping nvme hardware on MBP [Service] ExecStart=/sbin/fixsleep Type=oneshot RemainAfterExit=yes [Install] WantedBy=multi-user.target/sbin/fixsleep
#!/bin/bash /bin/echo 0 > /sys/bus/pci/devices/0000\:01\:00.0/d3cold_allowedWorks for my Macbook Pro 14,1 (13" 2017 without touchbar) running Ubuntu 19.10. However it takes about 10-20 seconds until the lockscreen shows up. Is there a fix for this behavior?
any suggestion about how to do this when booting from usb ?
These fixes work like a charm under Ubuntu/Pop_OS! 19.04 and 19.10 beta.
If you are having this problem when booting USB, it MAY still be the NVMe. Even if you don't have a filesystem active on it, the PCI wakeups are going to happen, right? I'd look to the same fix.
If you find that the USB filesystem returns, but is mounted as write-protected, there will have to be a similar fix to my NVMe to be sorted. The difficulty with this is that USB information may be different between boots, if you attach to a different port, hub, etc. lsusb is going to be your friend here.
Seems to work for me on a MacBookPro13,1. Maybe we could add that to the README?
Sure, just open a PR. 🙂 Would be interesting to see, if this also works for MacBook Pro's with Apple's own NVMe controller.
I'm on a Mid-2017 13" - MPXQ2LL/A* - MacBookPro14,1 - A1708 - 3164. That's nearly as modern as they come, without moving to the Apple T2-chip machines, like 2018 MBPs and new MB Air.
You're the expert here, but I'm pretty sure my PCI fix isn't going to help those machines, because the T2 has all of its signing requirements to access devices it obscures.
However? I do have a 2018 MB Air, that was mfd in Feb 2019. I'll see what I can do with a USB boot on the 5.3 kernels, and poke around withlspciand do some spelunking through the /sys filesystem.
It won't be for a few days...
If you are having this problem when booting USB, it MAY still be the NVMe. Even if you don't have a filesystem active on it, the PCI wakeups are going to happen, right? I'd look to the same fix.
Not sure. The light on the usb drive (Samsung T5 SSD) is off and stays off when waking. Maybe I could try on the NVMe but seems doubtful. The usb drive doesn't have the same files in /sys/bus/usb as the NVMe drive.
Not sure. The light on the usb drive (Samsung T5 SSD) is off and stays off when waking. Maybe I could try on the NVMe but seems doubtful. The usb drive doesn't have the same files in /sys/bus/usb as the NVMe drive. That's why I refer to "spelunking." ;-)
Yes, I wouldn't expect the structure to be the same. It does sound like a similar issue to PCI NVMe, where the defaults for power state of devices on the bus inhibits their waking after suspend/resume.
I may have some time to look at this in the week ahead.
No worries I'll have a look. Right after I'm done with the S section of my dictionary
Great. Disabling d3cold for the NVMe controller as mentioned above fixes resume on my MacBookPro13,2 as well. It also takes 10-20 seconds to come back up, as others already reported, but it's at least some progress. :clap:
Great. Disabling
d3coldfor the NVMe controller as mentioned above fixes resume on my MacBookPro13,2 as well. It also takes 10-20 seconds to come back up, as others already reported, but it's at least some progress. clap
Wow. I'm pretty proud of solving this. FWIW, my 14,1 is faster after a coupe of weeks of this. I also went to a low-latency kernel - I wonder if this is related?
Resume is in the acceptable 4-5 second range.
Not really much further on my usb drive with same issue.
The device is identified as 6-1 but presumably this can change, though I can use a script to identify it. (Google being my friend)
/sys/bus/usb/devices/6-1$ ls -l
total 0
drwxr-xr-x 8 root root 0 Nov 11 07:16 6-1:1.0
-rw-r--r-- 1 root root 4096 Nov 11 07:17 authorized
-rw-r--r-- 1 root root 4096 Nov 11 07:17 avoid_reset_quirk
-r--r--r-- 1 root root 4096 Nov 11 07:16 bcdDevice
-rw-r--r-- 1 root root 4096 Nov 11 07:17 bConfigurationValue
-r--r--r-- 1 root root 4096 Nov 11 07:16 bDeviceClass
-r--r--r-- 1 root root 4096 Nov 11 07:17 bDeviceProtocol
-r--r--r-- 1 root root 4096 Nov 11 07:17 bDeviceSubClass
-r--r--r-- 1 root root 4096 Nov 11 07:17 bmAttributes
-r--r--r-- 1 root root 4096 Nov 11 07:17 bMaxPacketSize0
-r--r--r-- 1 root root 4096 Nov 11 07:17 bMaxPower
-r--r--r-- 1 root root 4096 Nov 11 07:17 bNumConfigurations
-r--r--r-- 1 root root 4096 Nov 11 07:17 bNumInterfaces
-r--r--r-- 1 root root 4096 Nov 11 07:17 busnum
-r--r--r-- 1 root root 4096 Nov 11 07:17 configuration
-r--r--r-- 1 root root 65553 Nov 11 07:16 descriptors
-r--r--r-- 1 root root 4096 Nov 11 07:17 dev
-r--r--r-- 1 root root 4096 Nov 11 07:17 devnum
-r--r--r-- 1 root root 4096 Nov 11 07:17 devpath
lrwxrwxrwx 1 root root 0 Nov 11 07:17 driver -> ../../../../../../../../bus/usb/drivers/usb
drwxr-xr-x 3 root root 0 Nov 11 07:17 ep_00
lrwxrwxrwx 1 root root 0 Nov 11 07:17 firmware_node -> ../../../../../../../LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:41/device:42/device:5f/device:60/device:61/device:62
-r--r--r-- 1 root root 4096 Nov 11 07:16 idProduct
-r--r--r-- 1 root root 4096 Nov 11 07:16 idVendor
-r--r--r-- 1 root root 4096 Nov 11 07:17 ltm_capable
-r--r--r-- 1 root root 4096 Nov 11 07:16 manufacturer
-r--r--r-- 1 root root 4096 Nov 11 07:17 maxchild
lrwxrwxrwx 1 root root 0 Nov 11 07:17 port -> ../6-0:1.0/usb6-port1
drwxr-xr-x 2 root root 0 Nov 11 07:17 power
-r--r--r-- 1 root root 4096 Nov 11 07:16 product
-r--r--r-- 1 root root 4096 Nov 11 07:17 quirks
-r--r--r-- 1 root root 4096 Nov 11 07:17 removable
--w------- 1 root root 4096 Nov 11 07:17 remove
-r--r--r-- 1 root root 4096 Nov 11 07:17 rx_lanes
-r--r--r-- 1 root root 4096 Nov 11 07:16 serial
-r--r--r-- 1 root root 4096 Nov 11 07:17 speed
lrwxrwxrwx 1 root root 0 Nov 11 07:16 subsystem -> ../../../../../../../../bus/usb
-r--r--r-- 1 root root 4096 Nov 11 07:17 tx_lanes
-rw-r--r-- 1 root root 4096 Nov 11 07:16 uevent
-r--r--r-- 1 root root 4096 Nov 11 07:17 urbnum
-r--r--r-- 1 root root 4096 Nov 11 07:17 version
I thought the power dir would be of interest but could not find anything in there:
/sys/bus/usb/devices/6-1$ ls ./power/
active_duration autosuspend connected_duration level runtime_active_kids runtime_enabled runtime_suspended_time usb3_hardware_lpm_u1
async autosuspend_delay_ms control persist runtime_active_time runtime_status runtime_usage usb3_hardware_lpm_u2
So maybe this is controlled somewhere else?
$ cat /proc/acpi/wakeup
Device S-state Status Sysfs node
PEG0 S3 *enabled pci:0000:00:01.0
GFX0 S3 *disabled pci:0000:01:00.0
PEG1 S3 *enabled pci:0000:00:01.1
XHC2 S3 *enabled pci:0000:07:00.0
PEG2 S3 *enabled pci:0000:00:01.2
XHC3 S3 *enabled pci:0000:7d:00.0
RP01 S3 *enabled pci:0000:00:1c.0
ARPT S3 *enabled pci:0000:03:00.0
RP17 S3 *enabled pci:0000:00:1b.0
EC S4 *disabled platform:PNP0C09:00
GMUX S3 *disabled pnp:00:02
SPIT S3 *enabled spi:spi-APP000D:00
BLTH S4 *disabled serial:serial1-0
XHC1 S3 *enabled pci:0000:00:14.0
PNIC S4 *disabled
WDOG S3 *disabled
ADP1 S4 *disabled platform:ACPI0003:00
LID0 S4 *enabled platform:PNP0C0D:00
Any idea if Debian has a systemd option that could simply disable sleeping the drive?
Any idea if Debian has a systemd option that could simply disable sleeping the drive?
I wish I'd more time to help you with this. For USB power management, my best guess is that ACPI parameters are set as kernel arguments for boot in the GRUB command line. It shouldn't be Debian specific.
The best starting resource for these inquiries is documentation on kernel.org: (https://www.kernel.org/doc/html/v4.16/driver-api/usb/power-management.html)
Any idea if Debian has a systemd option that could simply disable sleeping the drive?
I wish I'd more time to help you with this. For USB power management, my best guess is that ACPI parameters are set as kernel arguments for boot in the GRUB command line. It shouldn't be Debian specific.
The best starting resource for these inquiries is documentation on kernel.org: (https://www.kernel.org/doc/html/v4.16/driver-api/usb/power-management.html)
The more recent docs for 5.3 have references for USB persist during suspend: (https://www.kernel.org/doc/html/v5.3/driver-api/usb/persist.html)
Any idea if Debian has a systemd option that could simply disable sleeping the drive?
I wish I'd more time to help you with this. For USB power management, my best guess is that ACPI parameters are set as kernel arguments for boot in the GRUB command line. It shouldn't be Debian specific.
The best starting resource for these inquiries is documentation on kernel.org: (https://www.kernel.org/doc/html/v4.16/driver-api/usb/power-management.html)
Any idea how one passes the grub-type commands through ReFind?
Any idea if Debian has a systemd option that could simply disable sleeping the drive?
I wish I'd more time to help you with this. For USB power management, my best guess is that ACPI parameters are set as kernel arguments for boot in the GRUB command line. It shouldn't be Debian specific. The best starting resource for these inquiries is documentation on kernel.org: (https://www.kernel.org/doc/html/v4.16/driver-api/usb/power-management.html)
The more recent docs for 5.3 have references for USB persist during suspend: (https://www.kernel.org/doc/html/v5.3/driver-api/usb/persist.html)
Thanks will have a look at that. Looks interesting. I'm pretty sure I saw that too. EDIT: Yes indeed persist is already set to 1 automatically. So the problem must be related to the hub or even something else deeper. Maybe best to just install to the NVMe drive.
Any idea how one passes the grub-type commands through ReFind?
I am unsure about ReFind. Does it call GRUB? I have my machines booting natively from Mac firmware, mounting the HFS-plus EFI partition (/dev/nvme0n1p1), under /boot (/dev/nvme0n1p2). This simplifies things immensely, once you assemble the right bits for FS and "blessing" system at original install.
Any idea how one passes the grub-type commands through ReFind?
I am unsure about ReFind. Does it call GRUB?
ReFind doesn't call grub. It finds the initram files and boots directly
MBP 13,3 - Things work smoothly Ubuntu 20.04 Nightly
5.4.0-9-generic #12-Ubuntu SMP Mon Dec 16 22:34:19 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
So what's the status of suspend nowadays? Working for everybody or still something which causes troubles?
Hi, reviving the thread. Tried the echo 0 > /sys/bus/pci/devices/0000\:01\:00.0/d3cold_allowed line and resume works (around 10s to wake up) however there is no sound after wakeup. Am I missing anything?
