Power Off/Hibernation Patch

[berglh]

I don't know what the state of shutdown is, but the MBP 11,5 has this patch to apply to get suspend to RAM and power off during shutdown working: https://bugzilla.kernel.org/show_bug.cgi?id=103211#c306

Maybe it's a similar problem on the 2016 MBP?

[mhkabir]

@Dunedan @roadrunner2 Were you guys able to test this?

[Dunedan]

Yeah, I tried out a modified patch, but I'm still not sure if it does work or not, as the MacBook Pro 2016 has this odd "switch on whenever screen lid is open" "feature". So the shutdown and startup behavior feels still kind of random.

But if you got further ideas what to test I'm happy to try it out.

[mhkabir]

Haha, yes, the feature is rather disconcerting :P

I can confirm that shutdown works for me without any patches, but suspend does not (it goes into suspend but doesn't come back out).

I will give this a try and see if it helps with the suspend issue. Can you push up your modified patch somewhere @Dunedan?

Thanks!

[roadrunner2]

I had looked at the patch a while ago, but I don't think it'll do anything for MacBookPro13's, because 1) poweroff works fine on MacBookPro13's, 2) the quirk in the patch is limited to MacBookPro11's anyway, and 3) the laptop actually suspens and resumes - it's just the display that apparently stays dark (at least the logs indicate that it suspended and resumed). But there is that BAR move in that patch that could theoretically do something (after changing PCI_DEVFN(2, 0) to PCI_DEVFN(1, 0), at least on the 15inch models).

@Dunedan Are you saying you actually get your display back after resume? If so, that must then come down to the difference in display driver, intel vs amdgpu.

[Dunedan]

So, I spent some time to figure out how to properly disable the auto-boot feature, to not be annoyed by it anymore: https://github.com/Dunedan/mbp-2016-linux#disable-auto-boot

The modified patch I currently use is:

@@ -, +, @@ 
    quirk
--- a/drivers/pci/quirks.c
+++ a/drivers/pci/quirks.c
@@ -2775,6 +2775,18 @@ static void quirk_hotplug_bridge(struct pci_dev *dev)
 
 DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_HINT, 0x0020, quirk_hotplug_bridge);
 
+static void quirk_apple_mbp_poweroff(struct pci_dev *dev)
+{
+       if (dmi_match(DMI_BOARD_VENDOR, "Apple Inc.") &&
+           (dmi_match(DMI_PRODUCT_NAME, "MacBookPro11,4") ||
+            dmi_match(DMI_PRODUCT_NAME, "MacBookPro11,5") ||
+            dmi_match(DMI_PRODUCT_NAME, "MacBookPro13,1") ||
+            dmi_match(DMI_PRODUCT_NAME, "MacBookPro13,2")))
+               dev->is_hotplug_bridge = 0;
+}
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x8c10, quirk_apple_mbp_poweroff);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x9d10, quirk_apple_mbp_poweroff);
+
 /*
  * This is a quirk for the Ricoh MMC controller found as a part of
  * some mulifunction chips.
    relocate
--- a/drivers/pci/probe.c
+++ a/drivers/pci/probe.c
@@ -163,6 +163,14 @@ static inline unsigned long decode_bar(struct pci_dev *dev, u32 bar)
 
 #define PCI_COMMAND_DECODE_ENABLE      (PCI_COMMAND_MEMORY | PCI_COMMAND_IO)
 
+static u32 vga_addr;
+static int reloc(char *str)
+{
+       get_option(&str, &vga_addr);
+       return 0;
+}
+early_param("reloc", reloc);
+
 /**
  * pci_read_base - read a PCI BAR
  * @dev: the PCI device
@@ -180,6 +188,13 @@ int __pci_read_base(struct pci_dev *dev, enum pci_bar_type type,
        u16 orig_cmd;
        struct pci_bus_region region, inverted_region;
 
+       if (vga_addr && dev->bus->number == 0 &&
+           dev->devfn == PCI_DEVFN(2, 0) && pos == 0x10) {
+               dev_info(&dev->dev, "** relocating BAR 0 to %#010x\n",
+                        vga_addr);
+               pci_write_config_dword(dev, pos, vga_addr);
+       }
+
        mask = type ? PCI_ROM_ADDRESS_MASK : ~0;
 
        /* No printks while decoding is disabled! */

My main motivation for using this patch was to try out if it improves the shutdown behavior, which is pretty unreliable. But I can't say if the patch works, as so far I haven't noticed a change.

@roadrunner2: I had no success with suspend/resume so far at all! When I try to suspend I see proper messages in syslog indicating everything is fine, but the MBP doesn't properly shuts off and also won't come back again at all. Maybe I'm simply doing something wrong.

Regarding the BAR move I haven't tried the reloc option yet, but if my understanding is correct, that'd only help for getting the display back anyway, right?

[omnibrain]

@Dunedan have you seen the off-topic discussion of this MR?: cb22/macbook12-spi-driver#2

Might be the same problem as with the MBP 2016. In short: The NVMe controller seems to require some vendor specific command to shut down properly. Without this, the controller is in a state where it can't be woken up anymore, which of course makes resuming fail.

[Dunedan]

@omnibrain Thanks for pointing out that discussion. Definitely something to keep in mind when looking further into hibernation and shutdown.

[Dunedan]

cb22/macbook12-spi-driver#30 (comment) contains some updates regarding suspend/resume.

[Dunedan]

Aside from hibernation: Often my MacBookPro13,2 doesn't power off after shutdown and just keeps displaying the last image on the screen. My workaround is to long press the power button in this case, but I was wondering: Does somebody else face the same issue?

[roadrunner2]

I have this issue sometimes too. Mostly it's related to the dGPU (AMD) - things are not happy during shutdown when it's disabled (I run only on the iGPU), and even re-enabling it doesn't help much. But sometimes it can be something else that holds up the shutdown, and it can take several minutes. Try witching to the console during shutdown (in my case, Fedora, by hitting esc) and see where it hangs. Or are you saying it goes through the whole shutdown but then just doesn't power off at the very end? If so, that's not something I've seen.

[jaketame]

https://www.reddit.com/r/linux/comments/4rnufy/people_who_run_linux_on_macbooks_is_it_worth_it/
This links to an arch-linux custom kernel which apparently has the patch fixes.

[Dunedan]

I believe the shutdown problems are long fixed (at least for models without dGPU). For suspend related problems there is also #37. Therefore I'm closing this issue now. If there is any need for further discussion, please either create a more specific new Github issue or let me know and I can re-open this one any time.