[Laptop 16 / 7040 / BIOS 4.05] Hibernate (ACPI S4, "platform" mode) only powers off on AC — instantly aborts on battery, no errors logged

[TrapStoner]

System Model or SKU

Framework Laptop 16 (AMD Ryzen™ 7040 Series)

BIOS Version

4.05

DIY Edition Information

Memory: Kingston Fury Impact 64Gb(2x32Gb) KF556S40IBK2-64
Storage: Samsung 990 Pro 2TB NVMe SSD

Port/Peripheral Information

Peripheral vendor and name:

1. USB C Card
2. USB C Card
3. USB A Card
4. USB C Card
5. USB A Card
6. SD Reader Card
   ALL expansion cards empty except one USB C where stock charger is plugged during AC testing.

Standalone Operation

Full System, Standalone mode NOT enabled (normal usage)

Describe the Bug

systemctl hibernate (and suspend-then-hibernate) with the kernel's default platform hibernation mode reliably completes a real power-off-and-resume cycle only while AC is connected. On battery, the exact same call goes through the full snapshot-preparation sequence and then instantly reports as "resumed" — same second, same boot, no reboot ever happens, no error anywhere in the kernel or systemd logs. It just silently declines to actually power off.

Switching HibernateMode from platform to shutdown (plain ACPI S5 poweroff instead of the ACPI S4 sleep-state transition, image restore on the following cold boot works the same either way) fixes it completely on both AC and battery. So this looks isolated to whatever the platform/ACPI-S4 path is doing differently from a plain S5 poweroff, specifically when unplugged.

Environment

• Framework Laptop 16, AMD Ryzen 7040 Series (board FRANMZCP09)
• CPU: AMD Ryzen 9 7940HS w/ Radeon 780M
• BIOS: 4.05 (dated 06/30/2026)
• OS: Fedora Linux 44 (KDE Plasma Desktop Edition)
• Kernel: 7.2.5-200.fc44.x86_64 (also reproduced on 7.2.4-200.fc44)
• WiFi/BT: Intel AX210 (8086:2725 / 8087:0032) — not the MediaTek RZ616, so this is not the known BT-resume-crash regression covered elsewhere on this tracker
• AMD PMC driver: amd_pmc loaded, Program 0 Firmware 76.102.0 at time of initial testing
• Root filesystem: btrfs, hibernating to a NOCOW swapfile (resume=/resume_offset= correctly configured and verified working — image write/restore itself is fine, this is purely about the power-off step)
• Secure Boot: disabled, kernel lockdown [none] (ruled out as a factor — see below)

Steps To Reproduce

1. Unplug AC, run on battery.
2. cat /sys/power/disk — confirm [platform] is selected (the kernel/systemd default when platform hibernation ops are registered, which they are here since ACPI reports (supports S0 S4 S5)).
3. sudo systemctl hibernate (or trigger it via lid-close / idle timeout with suspend-then-hibernate configured — same result).
4. Watch it: screen and keyboard backlight go dark, machine appears to be preparing to hibernate for ~60–80 seconds (this is the memory-snapshot/image-write phase, consistent with the size of RAM in use), then it comes back on by itself, immediately, no power button touched, screen relit automatically.
5. Plug in AC, repeat steps 2–3 exactly. This time it genuinely powers off — fans stop, all lights out — and stays off until you physically press the power button. A real cold boot follows and the session resumes correctly from the saved image.

Expected Behavior

Expected: hibernate behaves the same regardless of AC/battery state (it's an entirely reasonable, everyday case — arguably the most important case, since hibernate-on-low-battery is precisely when you want this to work).

Actual: on battery, the ACPI S4 transition appears to abort/bounce immediately after being asserted, with zero indication anywhere that anything went wrong.

Screenshots

No response

Operating System

Fedora 44

Linux Kernel Version

No response

Additional Context

Evidence

Kernel log for a battery-mode attempt (journalctl -k -b 0), representative of every failed attempt reproduced:

PM: hibernation: hibernation entry
Filesystems sync: 0.077 seconds
Freezing user space processes
Freezing user space processes completed (elapsed 0.001 seconds)
OOM killer disabled.
PM: hibernation: Marking nosave pages: [...]
PM: hibernation: Basic memory bitmaps created
Freezing remaining freezable tasks
PM: hibernation: Preallocating image memory
PM: hibernation: Allocated 5453893 pages for snapshot
PM: hibernation: Allocated 21815572 kbytes in 5.49 seconds (3973.69 MB/s)
printk: Suspending console(s) (use no_console_suspend to debug)
ACPI: EC: interrupt blocked
ACPI: PM: Preparing to enter system sleep state S4
ACPI: EC: event blocked
ACPI: EC: EC stopped
ACPI: PM: Saving platform NVS memory
Disabling non-boot CPUs ...
[... CPUs 1-15 go offline ...]
PM: hibernation: Normal pages needed: 6022617 + 1024, available pages: 8605595
ACPI: PM: Restoring platform NVS memory
ACPI: EC: EC started
Enabling non-boot CPUs ...
[... CPUs 1-15 come back online ...]
ACPI: PM: Waking up from system sleep state S4
ACPI: EC: interrupt unblocked
ACPI: EC: event unblocked
[... normal device resume, amdgpu "SMU is resumed successfully!", USB re-enumeration ...]
PM: hibernation: Basic memory bitmaps freed
PM: hibernation: hibernation exit

Every line above happens within the same wall-clock second as "Preparing to enter system sleep state S4" — there is no elapsed real time between S4 entry and S4 wake. journalctl --list-boots confirms no new boot ID is created; it's the same boot session before and after.

On AC, the identical command produces the identical log sequence up through "ACPI: PM: Preparing to enter system sleep state S4" — and then the machine genuinely powers off. The next log entries appear only after a real cold boot (new boot ID, full kernel/ACPI re-init from scratch), and a physical power-button press was required in between.

What's been ruled out

• Not a wake-source race: disabled all S4-capable devices in /proc/acpi/wakeup (NHI0, NHI1 — Thunderbolt/USB4 — plus tested with PCIe root ports) one at a time and in combination. No change on battery.
• Not Secure Boot / kernel lockdown: confirmed mokutil --sb-state disabled and /sys/kernel/security/lockdown = [none] throughout testing.
• Not the resume-image config: resume=/resume_offset= are correctly set and verified (the AC-mode successful cycles prove image write/restore works fine — the failure is specifically in the power-off step, not the snapshot or the resume side).
• Not the known MediaTek RZ616 Bluetooth hibernate-resume crash (tracked elsewhere on Framework's forum, kernel 6.11+ regression in hci_unregister_dev()) — this system uses the Intel AX210, and the failure mode is completely different anyway (that one crashes during resume; this one never even gets to a real power-off in the first place).
• Not HibernateMode=shutdown-affected: switching from platform to shutdown mode (plain ACPI S5 poweroff instead of the S4 platform transition, still writing/restoring the image via resume=/resume_offset= exactly the same way) fixes it completely and reproducibly on both AC and battery. This isolates the bug specifically to the ACPI S4 platform-enter path (hibernation_platform_enter() → acpi_hibernation_enter()), not to hibernation/image-handling in general.

Question for Framework

Is this an intentional EC/firmware safety gate (e.g. refusing to commit to a real S4 power-cut below some confidence threshold on battery, to avoid a brownout mid-transition), or an unintended BIOS 4.05 regression? Either way, it'd be good to have this either fixed or at least documented, since right now it fails completely silently — no error surfaced to the OS, no log line anywhere indicating why the platform declined to sleep — which makes it effectively undiagnosable from the OS side without exactly this kind of side-by-side AC/battery comparison.

Happy to test a candidate BIOS/EC firmware fix, pull more ACPI GPE counters, or run acpidump/EC dumps if that'd help narrow it down further.