Confirmed suspend fix for non-T2 MacBookPro13,1

[garymeyerca]

System

• Omarchy: 4.0.0-1 (Quattro)
• Kernel: 7.1.8-arch1-3
• Hardware: Apple MacBookPro13,1 (non-T2, Intel Skylake/Iris 540)
• Internal storage: Apple S3X NVMe at 0000:01:00.0

Problem

Closing the lid consistently hard-hung the machine during suspend. The display went black and the machine never resumed, requiring a forced power-off.

The journal from every failed attempt ended at suspend entry, with no matching exit:

systemd-logind: Lid closed.
systemd-logind: Suspending...
kernel: PM: suspend entry (deep)

Forcing s2idle alone did not help; that attempt ended the same way:

kernel: PM: suspend entry (s2idle)

Omarchy's existing omarchy-nvme-suspend-fix.service was present but disabled. Enabling it set the intended NVMe value:

/sys/bus/pci/devices/0000:01:00.0/d3cold_allowed = 0

The NVMe workaround plus s2idle alone still did not resolve the hang.

The kernel staged pm_test=devices test returned successfully, suggesting that the failure occurred later, near actual low-power entry.

Confirmed working configuration

I applied all non-T2-relevant parts of the workaround described in #1840:

# /etc/systemd/logind.conf.d/30-omarchy-mac-lid.conf
[Login]
HandleLidSwitch=sleep
HandleLidSwitchExternalPower=sleep

# /etc/systemd/sleep.conf.d/30-omarchy-mac-sleep.conf
[Sleep]
SuspendState=freeze
MemorySleepMode=s2idle

Kernel parameters:

intel_iommu=on iommu=pt pcie_ports=compat mem_sleep_default=s2idle

The existing Omarchy NVMe workaround was also enabled so that d3cold_allowed=0 is applied at boot.

After rebooting with the complete configuration, lid close/open completed normally:

12:21:50 systemd-logind: Lid closed.
12:21:50 systemd-logind: Suspending...
12:21:51 kernel: PM: suspend entry (s2idle)
12:22:06 systemd-logind: Lid opened.
12:22:07 kernel: PM: suspend exit
12:22:07 systemd-sleep: System returned from sleep operation 'suspend'.
12:22:07 systemd-logind: Operation 'suspend' finished.

Networking, NVMe, Hyprland, and the user session all recovered. There were no failed system or user units after resume.

One non-fatal message appeared during resume:

xhci_hcd 0000:07:00.0: PM: failed to resume async: error -19

That controller is behind the Thunderbolt bridge, but the system otherwise resumed and operated normally.

Upstreaming question

Would the maintainers accept a focused installer fix and migration for MacBookPro13,1, or should this first be tested across the other non-T2 models currently covered by fix-suspend-nvme.sh (MacBookPro13,[123], MacBookPro14,[123], and MacBook 8,1/9,1/10,1)?

If the desired model scope is confirmed, I am happy to prepare an atomic PR that adds the systemd drop-ins, Limine parameters, enables the existing NVMe service, and migrates existing installations.