Public bug reported:
(user-guided, LLM agent-assisted)
Summary
On Apple MacBookAir6,2, systemctl suspend with the default deep (S3) sleep mode
enters suspend and then wakes itself back up after ~4-5 seconds, with no user
interaction (no key press). The machine never actually stays asleep. Switching
/sys/power/mem_sleep to s2idle fully resolves the issue — the machine then
suspends and stays suspended normally until deliberately woken.
System
Hardware: Apple MacBookAir6,2 (11"/13" Air, Haswell ULT)
BIOS/firmware: Apple Inc., version 478.0.0.0.0, dated 2023-01-13
Board: Mac-7DF21CB3ED6977E5
CPU: Intel Core i7-4650U @ 1.70GHz (Haswell-ULT)
GPU: Intel Haswell-ULT integrated graphics (i915)
Wifi: Broadcom BCM4360 802.11ac [14e4:43a0] (using proprietary wl driver, see
note below — this was ruled out as the cause, see reproduction steps)
Thunderbolt: Intel DSL3510 "Cactus Ridge 4C 2012" [8086:1547]
Kernel: 7.0.0-31-generic (Ubuntu 24.04-based, #31~24.04.1-Ubuntu SMP
PREEMPT_DYNAMIC Mon Aug 10 09:38:02 UTC 2)
Distro: KDE neon User Edition (Ubuntu 24.04 "noble" base)
NOT YET TESTED on vanilla/mainline upstream kernel — only on the above distro
kernel. Happy to test a specific mainline version if a maintainer points me to
one.
Steps to reproduce
cat /sys/power/mem_sleep → s2idle [deep]
Ensure deep is selected (it's the default).
Run systemctl suspend.
Machine appears to suspend (screen off, disk standby) then wakes itself within
~4-5 seconds — confirmed via kernel log timestamps, not just visual observation.
Evidence ruling out the "obvious" causes
Before concluding this is a firmware/DSDT-level issue, I disabled every
plausible wakeup source one at a time and retested each time — none of them
stopped the immediate wake:
Broadcom wl driver PM bug: initially dmesg showed ERROR @wl_notify_scan_status
/ wlp3s0 Scan_results error (-22) during suspend prep. Added a systemd-sleep
hook to modprobe -r wl before suspend / modprobe wl after. This eliminated the
wifi driver error from the log, but the instant-wake behavior was UNCHANGED —
so this was a real but separate bug, not the cause of the wake.
/proc/acpi/wakeup: disabled XHC1 (USB controller, internal keyboard/trackpad
are USB-attached on this hardware) — no change.
/proc/acpi/wakeup: disabled all PCIe root ports (RP01, RP02, RP03, RP05, RP06)
— no change. (P0P2, HDEF, SPIT were already disabled by default; ARPT/EC/ADP1
are S4-only, LID0 S4-only and untouched since lid was never closed during
testing.)
/sys/class/rtc/rtc0/wakealarm: empty, no scheduled RTC wake.
systemd-inhibit --list: only standard delay-type inhibitors present
(NetworkManager, UPower, ModemManager, fprintd, kwin_wayland for
screen-lock-before-sleep) — nothing blocking or forcing an early resume.
GPE correlation
With every named device in /proc/acpi/wakeup disabled, I diffed
/sys/firmware/acpi/interrupts/gpe* immediately before and after multiple
suspend attempts (waiting for PM: suspend exit in the kernel log before
re-snapshotting, to avoid catching the async systemctl suspend return early).
gpe70 — administratively disabled the entire time — incremented by
exactly +1 on every single suspend attempt, consistently across repeated
tests. No other GPE showed this precise 1:1 correlation with the
suspend/resume cycle itself (gpe4E also increments, but at a rate
consistent with normal EC housekeeping/background polling, not a
discrete per-attempt trigger).
Example diff from one cycle:
gpe4E: 348598 EN enabled unmasked -> 348742 EN enabled unmasked
(background noise)
gpe70: 17 disabled unmasked -> 18 disabled unmasked
(+1, exact per-cycle)
Journal for that same cycle:
kernel: PM: suspend entry (deep)
kernel: ACPI: PM: Waking up from system sleep state S3
kernel: PM: suspend exit
(elapsed: ~4 seconds)
This points to a GPE that's disabled for normal runtime SCI generation
but still gets asserted by firmware/EC specifically during the S3
transition on this model — i.e., a DSDT/EC firmware quirk, not something
fixable from user space via /proc/acpi/wakeup.
Workaround
Setting mem_sleep_default=s2idle on the kernel command line (forcing s2idle
instead of deep/S3) makes suspend/resume work completely normally — the machine
suspends and stays suspended until deliberately woken. This strongly suggests
the bug is specific to this model's S3 firmware path and doesn't affect the
(fully OS-managed) s2idle path at all.
Request
Given this workaround, it would help other MacBookAir6,2 owners if this model
were added to the DMI-based s2idle force-quirk table in drivers/acpi/sleep.c
(similar to existing entries for other known-broken machines), so the machine
defaults to working suspend out of the box rather than requiring users to debug
this manually.
Happy to provide acpidump/DSDT, sudo dmidecode full output, or test
patches if useful.
** Affects: linux (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2166911
Title:
MacBookAir6,2 (Haswell): S3 deep-sleep suspend wakes immediately (~4s)
via GPE70; s2idle works fine
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2166911/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
