Omarchy lid/sleep/suspend issue on MacBook (bug + solution to be tested)

[nunix]

System details

Macbook T2 13" 2020 with touchbar

What's wrong?

As many other owners of Intel MacBooks, I'm facing a "sleep/suspend" issue with Omarchy.
Once installed, when I close the lid or choose suspend from the system menu, my session either freezes or it reboots without loading the touchbar drivers.

I need to perform another reboot to have a session working as intended.

Discoveries

After (quite) long debugging sessions, I found the following:

• By default, Omarchy (and Archlinux) trigger the suspend action and not sleep
• The suspend action has an impact on the usb devices by being unable to unbind correctly the devices
  • This can be seen by running for dev in "dev-tiny_dfr_display.device dev-tiny_dfr_backlight.device dev-tiny_dfr_display_backlight.device"; do systemctl status $dev; done after a suspend. Some devices will appear as dead status and when trying to run sudo systemctl restart tiny-dfr, it will fail stating that the device doesn't exist or is actually busy (either way, it's an improper state)
• According to the Archlinux wiki, the suspend action has different modes and the one by default in Omarchy is set to deep.
  • However, this seems to not work as intended and s2idle should be the one selected by default (see solution to be tested below)
• The solution provided in T2Linux.org suspend workaround brings some stabilization as to be able to come out of suspend, however the touchbar doesn't work anymore and a reboot is needed

Solution to be tested

Based on the discoveries above and on the different documentation found a bit everywhere, I could reach a first step of "normal sleep behavior" with the following configuration changes:

/etc/systemd/logind.conf

[Login]
#NAutoVTs=6
#ReserveVT=6
#KillUserProcesses=no
#KillOnlyUsers=
#KillExcludeUsers=root
#InhibitDelayMaxSec=5
#UserStopDelaySec=10
#SleepOperation=suspend
HandlePowerKey=ignore
#HandlePowerKeyLongPress=ignore
#HandleRebootKey=reboot
#HandleRebootKeyLongPress=poweroff
#HandleSuspendKey=suspend
#HandleSuspendKeyLongPress=suspend
#HandleHibernateKey=hibernate
#HandleHibernateKeyLongPress=ignore
HandleLidSwitch=sleep
HandleLidSwitchExternalPower=sleep
#HandleLidSwitchDocked=ignore
#HandleSecureAttentionKey=secure-attention-key
#PowerKeyIgnoreInhibited=no
#SuspendKeyIgnoreInhibited=no
#HibernateKeyIgnoreInhibited=no
#LidSwitchIgnoreInhibited=yes
#RebootKeyIgnoreInhibited=no
#HoldoffTimeoutSec=30s
#IdleAction=ignore
#IdleActionSec=30min
#RuntimeDirectorySize=10%
#RuntimeDirectoryInodesMax=
#RemoveIPC=yes
#InhibitorsMax=8192
#SessionsMax=8192
#StopIdleSessionSec=infinity
#DesignatedMaintenanceTime=

Description
The important settings here are:

HandleLidSwitch=sleep
HandleLidSwitchExternalPower=sleep

This will switch the suspend action to the sleep action when the lid is close, both on battery and external power.

Tip
The option HandlePowerKey=ignore allows the power button to display the Omarchy system menu directly. It can be seen as a small quality of life modification.

/etc/systemd/sleep.conf

[Sleep]
#AllowSuspend=yes
#AllowHibernation=yes
#AllowSuspendThenHibernate=yes
#AllowHybridSleep=yes
SuspendState=freeze
#HibernateMode=platform shutdown
MemorySleepMode=s2idle
#HibernateDelaySec=
#HibernateOnACPower=yes
#SuspendEstimationSec=60min

Description
This file is a first part of the solution and might need some adjustments, and even have the changes transferred as a drop-in in /etc/systemd/sleep.conf.d/ directory.
As stated before, the major change here is to set MemorySleepMode=s2idle for changing the way the power management is handled and be compatible with the MacBook hardware (at least, that's how I understand it).
The other option SuspendState=freeze is a requirement to s2idle based on the Archlinux documentation link above).

Note
While the documentation clearly states that this file is the way to change the power management, I faced another issue that the settings were not correctly applied (don't know the reason).
More concretely, even with the file modified, a sudo systemctl daemon-reload applied, once I rebooted, when running cat /sys/power/mem_sleep, I had the result s2idle [deep], meaning deep was the power management method selected and not s2idle.

To change this behavior permanently, I had to change the kernel command line directly as described below.

/etc/default/limine

TARGET_OS_NAME="Omarchy"

ESP_PATH="/boot"

KERNEL_CMDLINE[default]="cryptdevice=PARTUUID=c782d706-2a06-463d-bfdf-d41247dde676:root root=/dev/mapper/root zswap.enabled=0 rootflags=subvol=@ rw rootfstype=btrfs"
KERNEL_CMDLINE[default]+="quiet splash intel_iommu=on iommu=pt pcie_ports=compat mem_sleep_default=s2idle"

ENABLE_UKI=yes

ENABLE_LIMINE_FALLBACK=yes

# Find and add other bootloaders
FIND_BOOTLOADERS=yes

BOOT_ORDER="*, *fallback, Snapshots"

MAX_SNAPSHOT_ENTRIES=5

SNAPSHOT_FORMAT_CHOICE=5

Description
The important modification here is the line:
KERNEL_CMDLINE[default]+="quiet splash intel_iommu=on iommu=pt pcie_ports=compat mem_sleep_default=s2idle"

Due to another potential issue with the kernel command line drop-in not being loaded (/etc/limine-entry-tool.d/t2-mac.conf), I added its content directly to this file and added the option mem_sleep_default=s2idle at the end.
This allowed the power management method to be permanently changed as intended.

/etc/systemd/system/suspend-t2.service

[Unit]
Description=Disable and Re-Enable Apple BCE Module (and Wi-Fi)
Before=sleep.target
StopWhenUnneeded=yes

[Service]
User=root
Type=oneshot
RemainAfterExit=yes

#ExecStart=/usr/bin/modprobe -r brcmfmac_wcc
#ExecStart=/usr/bin/modprobe -r brcmfmac
ExecStart=/usr/bin/systemctl stop tiny-dfr
#ExecStart=/usr/bin/rmmod -f appletbdrm
#ExecStart=/usr/bin/rmmod -f hid_appletb_kbd
#ExecStart=/usr/bin/rmmod -f hid_appletb_bl
#ExecStart=/usr/bin/rmmod -f apple-bce

#ExecStop=/usr/bin/modprobe apple-bce
#ExecStop=/usr/bin/modprobe hid_appletb_bl
#ExecStop=/usr/bin/modprobe hid_appletb_kbd
#ExecStop=/usr/bin/modprobe appletbdrm
ExecStop=/usr/bin/systemctl start tiny-dfr
#ExecStop=/usr/bin/modprobe brcmfmac
#ExecStop=/usr/bin/modprobe brcmfmac_wcc

[Install]
WantedBy=sleep.target

Description
The last file modified is a modified service file from the T2Linux.org suspend file (link above), which I only kept the stop and start of the tiny-dfr service.
For testing purpose, I kept commented all the kernel modules used by the apple components (keyboard/touchbar/wifi).
They should not be needed normally, as the sleep method doesn't seem to unbind the devices like suspend does.

Call to help

As said initially, this could be the begin of a solution but it's not perfect and I only have 1 MacBook, so I'm not sure if other models will behave the same and if this solution is actually applicable to them.
So in order to help the Omarchy amazing maintainers, please try to apply the changes to the files above, reboot, and see how your system behaves when picking Suspend from the Omarchy system menu and when closing the lid.

Please note that it might take few seconds before seeing something appearing on the screen when trying to wake-up and in my case, I have to always click the power button to resume from sleep.

Hope this helps finding a solution and I didn't perform any battery drain testing, so hopefully the sleep method will not have a huge impact.

Last but not least, you can find me in the Omarchy Discord (same alias, Nunix) if you have any questions or feedback.

The sleep rabbit hole Corsair 🏴‍☠️

[davidguttman]

I made the changes, but when I close the lid and then try to resume (also have to press power button), the touchbar will come back but not the screen. The touch bar does respond to the fn key though. I have to hard power off and power back on. 2019 MacBookPro16,1

Thanks for working on this!

[scottdavis]

i have an A2141 2019, 16 inch tried these changes and mine will not wake from sleep at all :( I guess the hardware is different enough between those model years :(

[Zesko]

Due to another potential issue with the kernel command line drop-in not being loaded (/etc/limine-entry-tool.d/t2-mac.conf),

Because you use KERNEL_CMDLINE[default]= in /etc/default/limine, it overwrites any drop-in config

You should change all KERNEL_CMDLINE[default]= entries to KERNEL_CMDLINE[default]+= in /etc/default/limine. This way, the cmdline options from drop-in configs will be added instead of replaced.

[RecklezzNexus]

I have a Macbook T2 13" 2020 with touchbar as well. I performed the changes you described on my system. I can report that for me it works the first time I test it but if I close the lid a second time it doesn't.

Upon opening the lid the second time and hitting the power button, I am unable to type in my password for some reason. I am presented with the prompt to enter my password but I am unable to type anything. I will dig in a bit more this weekend and see what I can figure out.

Thank you for your work on this.

[MountVesuvius]

I have the "MacBook Pro 13-inch (2018, four Thunderbolt 3 ports) – Model: A1989" with the touchbar.

I followed the file changes and I can now suspend the laptop after a restart and it will wake back up. However, if I then suspend the laptop again it won't come back and will hard shut down. Additionally, closing the lid will act the same as the initial suspend except it also stops the wifi from working (then on second suspend it doesn't work at all).

Will also take a further look, but thank you for starting this off.

[fbreuer]

Thank you very much! I am on 2017 MacBook (not air, not pro), which has neither a T1 nor T2 chip as far as I know. Nevertheless, same disk issues upon suspend.

Edited logins.conf, sleep.conf, and limine as described. I did not bother with the T2 related change. I did however have to run sudo limine-update for the changes to take effect.

After this, I see /sys/power/mem_sleep set to s2idle and I can close and open the lid without disk issues.

[erzz]

I have followed pretty much everything in this thread and still stuck on s2idle deep with no wake at all usually and then sometimes the (otherwise dead) touchbar comes to life 🤷🏻‍♂️

2019 MBP

[skeptomai]

Omarchy 3.17, MacBook Pro 15,3 A1990. Same problem as @erzz and my TouchBar sometimes works, sometimes does not. Running sudo tiny-dfr manually at the terminal just faults.

[DerFuchs]

2019 MacBook Pro 13" (MacBookPro15,2 1.0)
Omarchy 3.1.7

No wake up at all. I have to kill it with a long press of the power button to perform a fresh boot. After that, the touch bar does not come up.

running tiny-dfr just leads to errors

[fbermel]

Hi, I just did a fresh install on a MacBook Pro 13-inch Model: A1989 and am running into the same issues. When I close the lid the Mac freezes and touchbar stops working.

[kstarrSCW]

Hi All, I have the same issues with a fresh install of 3.2.0 on a MacBook Pro model A1708, this unit has no touchbar.

[drakmail]

Thank you! For my MBP 2015 A1398 (without touchbar) worked perfectly changes you described for:

1. /etc/systemd/logind.conf
2. /etc/systemd/sleep.conf
3. /etc/default/limine

I don't touched the /etc/systemd/system/suspend-t2.service file.

PS. Also, I did limine-update after changing /etc/default/limine

[rasbml]

Same issue here. Tried the solution. Updated all the files as per instructions. No effect.
My Mac is - Macbook Pro 2019 16.1
Omarchy is latest 3.2 version

Behavior is that it goes black, does not come back from sleep and if you leave it like that then eventually it will just shutdown like halt with fans doing a quick loud sound (like when in Mac you have a serious issues, probably kernel panic in Linux)

[rmtew]

Omarchy 3.2
Macbook Pro 2019 16

Did not fix the problem for me.
I was unable to get it to change from s2idle [deep] to s2idle despite doing all changes listed which possibly contributed, but who knows.

Suspend would sit there with fans wiring either:

• No resume at all with black screen.
• Resume with lock screen and non-responsive trackpad/keyboard.

The suspend workaround was a net improvement even just removing and probing the bce module, the touchbar only ever worked first Omarchy boot post-install and never again. With the bce rmmod and modprobe it came back. After installing the service it is present on boot.

Now suspend sits there with fans wiring. But now keyboard and trackpad enable and I can re-enter desktop.

[jzimdars]

I've hit this, too on a MacBookAir9,1 (2020 Intel) — linux-t2 6.17.7. Closing the lid would result in the machine appearing to shut down rather than suspend. After some digging, I applied three fixes and lid-close suspend now works reliably.

Root cause: /sys/power/mem_sleep defaults to deep (S3), which T2 firmware doesn't support. Suspend would crash/reboot the system.

Fix 1 — Force freeze (s2idle) as the suspend mode:

  sudo mkdir -p /etc/systemd/sleep.conf.d
  printf '[Sleep]\nSuspendState=freeze\n' | sudo tee /etc/systemd/sleep.conf.d/t2-suspend.conf

Fix 2 — Add mem_sleep_default=s2idle to kernel cmdline (belt-and-suspenders — add to the existing t2-mac.conf limine entry):

KERNEL_CMDLINE[default]+="intel_iommu=on iommu=pt pcie_ports=compat mem_sleep_default=s2idle"

Then append the param directly to the cmdline: line in /boot/limine.conf for the current boot (the drop-in only takes effect on kernel reinstall).

Fix 3 — Manage apple-bce around suspend (prevents dead keyboard/trackpad on resume) in /etc/systemd/system/suspend-t2.service

[Unit]
Description=Manage apple-bce module around suspend (T2 Mac)
Before=sleep.target
StopWhenUnneeded=yes

[Service]
User=root
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/bin/rmmod -f apple-bce
ExecStop=/usr/bin/modprobe apple-bce

[Install]
WantedBy=sleep.target

Then:

sudo systemctl enable suspend-t2.service

The keyboard getting re-connected on resume still is hit-or-miss but the computer is much more useable now.

[NicolasDorier]

About drop-in not being applied, this should fix it #5114

[jzimdars]

Good find, @NicolasDorier! That helped.

Since then I've been using Claude to troubleshoot and got a pretty functional setup. Having it read the system logs to determine what happened was the key to making progress. Every time sleep/resume failed, I'd have it look. And when it seemed to work, I'd have it confirm.

[jzimdars]

For those following along, I'm having a very good experience with this setup and so I've opened #5129

[jjohnson]

Great discussion. I went deep on this for a MacBookPro15,4 and wanted to share what I found.

The core problem most people are hitting is that rmmod apple-bce fails — ALSA pins the module through aaudio. You need to unbind the PCI device first. After that, rmmod apple-bce works. And importantly, we don't use -f (force) — with proper unbind and correct dependency ordering, a clean unload succeeds.

But apple-bce isn't the only module — appletbdrm, hid_appletb_kbd, hid_appletb_bl all depend on it and need to be unloaded in the right order first. We also unload brcmfmac_wcc and brcmfmac separately (they handle Wi-Fi, not T2 dependencies but the Broadcom Wi-Fi chip doesn't handle D3 correctly on T2 Macs, causing timeouts/wake storms.).

The other root cause is a kernel bug: PLAYBACK uses dev_timestamp (T2 clock domain) which gets out of sync after module re-probe, causing a wild position → XRUN → scheduling while atomic crash. Fix is using os_timestamp for PLAYBACK — one line in audio/pcm.c.

I've got a full solution in PR #5998 that handles the complete lifecycle (unbind → stop tiny-dfr → unload deps in order → suspend → reload), plus the kernel timestamp patch.

@jzimdars — your PR #5129 is on the right track but the aaudio unbind and proper dep ordering are essential for reliable second-suspend. The rmmod -f apple-bce won't work if PipeWire has the audio device open.

[TopperH]

T2 MacBook Air (MacBookAir9,1) — no TouchBar — sequential suspend fix

Kernel: 7.0.11-arch1-Watanare-T2-1-t2

Root cause: The Intel JHL7540 Thunderbolt 3 xHCI controller (06:00.0) fails to resume after s2idle with -19 (ENODEV). This corrupts the PM state, causing the second suspend attempt to hang during userspace freeze (never reaches PM: suspend entry).

Fix — two parts:

1. Kernel cmdline (/etc/limine-entry-tool.d/t2-mac.conf or equivalent):

   intel_iommu=on iommu=pt pm_async=off mem_sleep_default=s2idle
   

   pm_async=off is critical — without it, even the first suspend may not wake.

2. systemd-sleep hook to unbind the broken xHCI before sleep and rebind after wake:
   /usr/lib/systemd/system-sleep/tb-xhci-unbind.sh:

   #!/bin/bash
   case "$1" in
     pre)
       echo "0000:06:00.0" > /sys/bus/pci/drivers/xhci_hcd/unbind 2>/dev/null || true
       ;;
     post)
       echo "0000:06:00.0" > /sys/bus/pci/drivers/xhci_hcd/bind 2>/dev/null || true
       ;;
   esac

   Mark executable: chmod +x /usr/lib/systemd/system-sleep/tb-xhci-unbind.sh.

Result: Two consecutive systemctl suspend cycles work. The Thunderbolt port is briefly unavailable during sleep, but that's invisible on an Air with nothing plugged in.

[TopperH]

Update — fan keeps running during suspend on T2 MacBook Air (no TouchBar)

The t2fanrd daemon sets the fan to manual PWM mode. When userspace freezes during s2idle, the hardware keeps spinning at whatever speed t2fanrd last wrote. The SMC would normally stop the fan in auto mode, but it can't because the daemon locked it to manual.

Fix — systemd-sleep hook at /usr/lib/systemd/system-sleep/t2-fan.sh:

#!/bin/bash
SMC_FAN=/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:85/APP0001:00
case "$1" in
  pre)
    systemctl stop t2fanrd
    echo 0 > "$SMC_FAN/fan1_manual"
    ;;
  post)
    echo 1 > "$SMC_FAN/fan1_manual" 2>/dev/null || true
    systemctl start t2fanrd
    ;;
esac

Make executable and that's it. Verified working on MacBookAir9,1.

Combined fix summary for the Air:

1. Kernel cmdline: intel_iommu=on iommu=pt pm_async=off mem_sleep_default=s2idle
2. Unbind the Thunderbolt xHCI pre-suspend (see previous post for tb-xhci-unbind.sh)
3. This fan hook above

All three together give working sequential suspend/resume with a silent (stopped) fan during sleep.

[jjohnson]

@TopperH — nice finds on the xHCI and fan issues. You're running s2idle with mem_sleep_default=s2idle, but deep is the default on these machines and the real question is whether it works with proper module management.

PR #5998 keeps deep mode and manages the T2 module lifecycle, plus a kernel patch fixing the audio dev_timestamp bug after module re-probe. No s2idle, no xHCI unbinding needed on MBP.

Would you be willing to try it on your MacBookAir9,1? Drop mem_sleep_default=s2idle and pm_async=off, enable the service, and see if deep works. Could make the xHCI workaround unnecessary.

[TopperH]

@jjohnson — thanks a lot for this! I tested PR #5998 on my MacBookAir8,1 (I mistyped it as 9,1 in earlier posts — it's the 2018 Retina Air, still T2) and at a first glance everything seems perfectly working.
Here's what I did:

1. Cloned your add-t2-suspend branch and ran the migration script
2. Cleaned up my kernel cmdline — removed pm_async=off and mem_sleep_default=s2idle, kept only pcie_port_pm=off
3. Rebooted and tested two consecutive systemctl suspend cycles
   Results:

• Both suspend cycles used deep (S3) as active mode
• The t2-suspend service ran correctly both times: aaudio unbound, apple_bce and T2 modules unloaded in order before sleep, all reloaded cleanly after resume
• No Thunderbolt D3hot errors
• No audio XRUNs or scheduling while atomic
• No brcmfmac timeouts
• Wi-Fi reconnected, keyboard/trackpad responsive, USB-C data and charging working

The only thing I noticed is AppleFailedBootVolumeUUID being set on resume, probably harmless.
No xHCI unbind hack, no acpi_osi tricks needed. Your module lifecycle approach solves it properly. Thanks again for putting this together — really appreciate it.

[jjohnson]

@TopperH — great to hear it works! Would you mind adding a comment on PR #5998 confirming it's tested on MacBookAir8,1 with your kernel (7.0.11-arch1-Watanare-T2-1-t2) and deep sleep? Would be great to have that test recorded on the PR itself.

[TopperH]

Just commented the PR, thank you again. I've been using it for a while now and works flawlessly. I might not have tested everything but it seems like that the hardware is 100% functional (exept of course for the fingerprint reader).

[andyhoops]

I dug into this on a MacBookPro16,2 and believe I found a root cause that explains the hard-hang for the T2 machines here (the ones that freeze the instant they suspend and need a forced power-off).

It's an asynchronous device-suspend race, not a specific dead driver. On these T2 Macs the kernel default of suspending devices in parallel (/sys/power/pm_async=1) intermittently deadlocks on suspend entry. pm_trace localises the hang to the async suspend core (drivers/base/power/main.c), not to any one device — which is why the usual suspects don't pan out: in my testing, switching deep↔s2idle, unloading brcmfmac, unloading apple-bce, and disabling PCI D3cold on the T2 complex all still hung.

The fix is to force synchronous device suspend:

echo 0 | sudo tee /sys/power/pm_async

On my 16,2 that gave 5/5 clean suspend/resume cycles (incl. lid close/reopen), where the default hung 5/5. It's independent of suspend mode, and reverts on reboot so it's safe to try.

I've opened a PR that applies this automatically on T2 Macs (detects via lspci 106b:180[12], installs a small oneshot service, plus a migration for existing installs): #6149.

Could folks on other affected models help confirm breadth? If you're on a 13"/15"/other-16" T2 MacBook that hangs on suspend, please try the one-liner above and then systemctl suspend a few times, and report your model + result. The more models we can confirm, the more confident the maintainers can be in merging. 🙏

(Note: the older fix-suspend-nvme.sh doesn't cover these machines — it excludes 16,x/15,x and targets a discrete NVMe at 0000:01:00.0, whereas this storage is the T2-bridged ANS2 at e6:00.0. This is a separate, complementary fix.)

[ghrubi]

I tried this on my 2019 MacBook 16,1. It resumes reliably (albeit very slow to resume), but my touchbar is in an unusual state when resumed. My tiny-dfr service will not restart due to missing dependencies. Once I resolve, I'll report back. Thanks for this!

[andyhoops]

I had the same issue as it turns out. So: for those seeing the Touch Bar dead after resume (tiny-dfr won't start /
faults when run manually): that's a separate bug from the suspend hard-hang
discussed here (that one is the async-suspend race → pm_async=0), and it's
not a tiny-dfr or Omarchy problem. On T2 kernels ≥7.0.1 the Touch Bar display
device fails to re-enumerate on resume (bce-vhci: [00] URB failed: 3, device
left unconfigured), so tiny-dfr's display genuinely isn't there — and once
wedged it's unrecoverable without a reboot.

Working fix, tested on a MacBookPro16,2 @ 7.0.12-...-t2 (multiple clean
cycles, zero URB failures): a systemd-sleep hook that unloads
hid-appletb-kbd before suspend and — critically — waits for the display to
re-enumerate (~3 s after resume) before reloading it. Reloading immediately
at resume re-wedges the device; that timing detail is what makes the known
workaround from CachyOS/linux-cachyos#824 actually automatable.

Script + details: https://github.com/andyhoops/omarchymacbookhelper/blob/main/contrib/t2-touchbar-suspend-fix.sh
Fuller write-up on the CachyOS issue: CachyOS/linux-cachyos#824

Two warnings for 16,x from testing: do NOT tear down apple_bce pre-suspend
(it's pinned by the T2 sound card; unloading it hangs suspend entry), and
post-resume recovery attempts (bConfigurationValue writes, module reloads)
are futile once the wedge has happened — prevention is the only option.

Point your favourite AI helper at this thread and tell it to treat both issues as independent issues and you should be good. I used Claude Code. Interestingly Opus4.8 couldn't fix it - Fable 5 did.

[jjohnson]

Update from testing and the work in #5998 and #6149:

There appear to be multiple independent suspend/resume problems on T2 Macs.

1. Suspend ordering. Fix intermittent suspend hang on T2 MacBooks (force synchronous device suspend) #6149 forces synchronous device power management with pm_async=0. On my MacBookPro15,4 using the legacy apple_bce stack, this appeared to eliminate the need to cycle apple_bce. Subsequent testing on a MacBookPro16,1 showed that the reduced path did not reliably restore the BCE/VHCI and Touch Bar state, so it was reverted.

2. Chipset-specific Wi-Fi handling. On my BCM4377b machine, unloading brcmfmac/brcmfmac_wcc before suspend remains mandatory with either pm_async=1 or pm_async=0. If Wi-Fi stays bound, brcmf_pcie_pm_enter_D3 times out and pci_pm_suspend() returns -5. The kernel aborts both the deep and fallback s2idle attempts, producing a suspend/wake loop before systemd reports Failed to start System Suspend. This is visible in journalctl -b. With Wi-Fi unloaded, the machine enters deep sleep normally.

   This behavior is chipset-specific. Testing on the BCM4364-equipped MacBookPro16,1 found the opposite: brcmfmac must remain bound so kernel PCI PM can manage D3cold correctly. Add suspend/resume recovery for T2 Macs (using legacy apple_bce) #5998 detects PCI ID 14e4:4464 and preserves that distinction.

3. Peripheral recovery. Even with pm_async=0, the Touch Bar still requires targeted module recovery, and Bluetooth requires its hci_bcm4377 cycle as well; this has now been validated on additional machines.

The current #5998 branch does not set pm_async=0. It retains the complete legacy recovery sequence because that is the version tested across the additional machines reported on the PR. Its apple_bce unload also differs from a plain rmmod: it first unbinds aaudio, releasing the ALSA references pinning the module, and unloads dependent modules in order. A reduced recovery path for pm_async=0 was subsequently tested on a MacBookPro16,1. It did not reliably restore the legacy BCE/VHCI and Touch Bar state and was reverted. #5998 therefore always uses the complete legacy recovery sequence, regardless of pm_async. Because that sequence reloads apple_bce, legacy kernels require the PLAYBACK os_timestamp fix from t2linux/apple-bce-drv#30 for clean audio recovery.

There has also been a major upstream change: T2 Linux replaced the legacy apple_bce implementation with the new t2bce (https://github.com/deqrocks/t2bce) stack through linux-t2-patches#51 (t2linux/linux-t2-patches#51). It coordinates PM across BCE core, audio, and VHCI and may eliminate the BCE/audio and possibly Touch Bar portions of these workarounds. #5998 is now explicitly scoped to legacy apple_bce kernels and safely no-ops when that driver is unavailable.

The useful next test matrix is:

1. Current t2bce with native pm_async=1 and no helper.
2. Current t2bce with pm_async=0 and no helper.
3. Add only Wi-Fi, Bluetooth, or Touch Bar recovery where testing proves it necessary.
4. Continue testing the complete legacy apple_bce recovery on additional models, using the timestamp fix.

When reporting results, please include the Mac model, Wi-Fi chipset, kernel version, /sys/power/pm_async, /sys/power/mem_sleep, and whether lsmod shows apple_bce or t2bce.

[felix-antonio-sl]

Confirmed on current Omarchy Quattro with the new t2bce stack:

• Model: MacBookPro15,4 (13-inch 2019, Intel/T2)
• Omarchy: 4.0.1-1
• Kernel: 7.1.8-arch1-Watanare-T2-3-t2
• Wi-Fi: BCM4377b, PCI ID 14e4:4488
• Driver stack: t2bce (t2bce_core, t2bce_vhci, t2bce_audio)
• /sys/power/pm_async: 0
• /sys/power/mem_sleep: s2idle [deep]

Closing the lid correctly triggered suspend, but every attempt was aborted by the BCM4377b driver:

brcmfmac 0000:01:00.0: PM: pci_pm_suspend(): brcmf_pcie_pm_enter_D3 [brcmfmac] returns -5
brcmfmac 0000:01:00.0: PM: failed to suspend: error -5
PM: Some devices failed to suspend, or early wake event detected

This produced repeated deep/fallback-s2idle attempts and significant battery drain while the lid was closed.

With t2bce, cycling only brcmfmac_wcc and brcmfmac through a Before=sleep.target oneshot service fixed it:

• pre-suspend: modprobe -r brcmfmac_wcc brcmfmac
• post-resume: modprobe brcmfmac, then modprobe brcmfmac_wcc

There was no need to cycle t2bce, audio, Bluetooth, or Touch Bar modules on this machine.

Verified with an RTC-controlled suspend test:

PM: suspend entry (deep)
ACPI: PM: Preparing to enter system sleep state S3
ACPI: PM: Waking up from system sleep state S3
PM: suspend exit

Wi-Fi reloaded and reconnected successfully, and there were zero new brcmf_pcie_pm_enter_D3 / suspend error -5 messages after the fix.

This fills the t2bce + pm_async=0 + add only Wi-Fi recovery where testing proves it necessary case from the proposed test matrix. It suggests Omarchy could install a chipset-specific Wi-Fi suspend service when PCI ID 14e4:4488 is detected on a T2 Mac.

[iJustinCabral]

Overnight confirmation on MacBookAir9,1 with current Quattro t2bce with the same Wi-Fi-only workaround as the 15,4 report above, and real S3 rather than s2idle.

Machine

• MacBookAir9,1 (Ice Lake, no Touch Bar)
• Omarchy 4.0.2-1
• linux-t2 7.1.8-arch1-Watanare-T2-3-t2
• Stack: t2bce_core / t2bce_vhci / t2bce_audio (no apple_bce)
• Wi-Fi: BCM4377b 14e4:4488
• /sys/power/pm_async: 0
• /sys/power/mem_sleep: s2idle [deep] (mem_sleep_default=deep left as the T2 installer set it)

Fix: a Before=sleep.target oneshot that unloads brcmfmac_wcc + brcmfmac on pre and reloads on post. No t2bce cycle, no Bluetooth/audio cycle, no SuspendState=freeze, no d3cold disable on NVMe/T2 bridges.

This boot (2026-09-02 21:22 → now):

• /sys/power/suspend_stats/success=7 fail=0
• zero brcmf_pcie_pm_enter_D3 / failed to suspend
• zero Unable to change power state from D3hot to D0
• seven PM: suspend entry (deep) → ACPI: PM: Waking up from system sleep state S3
• longest sleep ~4h 37m overnight (21:31 → 02:08); another ~2h 27m later in the day
• on resume: t2bce_* stateful resume status=0, keyboard/trackpad back on t2bce_vhci, Firmware: BCM4377/4 … FWID 01-52f5532e
• lid closed: dark, cool, fan off (real S3, not frozen s2idle with t2fanrd holding manual PWM)

This fills the Air 9,1 cell of the t2bce + pm_async=0 + add only Wi-Fi recovery matrix.

Please do not land a blanket s2idle / SuspendState=freeze for current t2bce machines. That is what PR #9830 currently does, based on linux-t2 6.17.7 / apple-bce where unload + deep hard-reset. On this 7.1.8 t2bce Air, deep resumes. Forcing freeze would take a working S3 path and put it back on the high-drain s2idle path.

Suggested split: keep mem_sleep_default=deep on t2bce; unload brcmfmac only when PCI 14e4:4488 is present; never unload it on BCM4364 (14e4:4464).