Blog
Framework Laptop 13 suspend battery drain on Linux: the honest take
The Framework Laptop 13 drains its battery while the lid is shut, and on Linux that is worse than on Windows. That is the real complaint, it is not imaginary, and it is also fixable enough that it should not by itself stop you buying one. Both halves of that sentence matter.
Why it drains at all
Modern laptops, the Framework 13 included, do not do old-style S3 suspend where the machine is all but off with only RAM kept alive. They do s2idle, also called modern standby or S0ix. The CPU and devices drop into deep idle states but the system is technically still running and can wake for notifications. s2idle only saves real power if every component actually reaches its deepest idle state. If one device, a USB controller, the SSD, the EC, or a firmware ACPI quirk keeps something awake, the laptop sits in a shallow idle and the battery bleeds.
On the Framework 13 with a 61 Wh pack, the reported figure on Linux is roughly 5 to 10 percent overnight. That is the number in our Framework 13 (AMD Ryzen AI 300) notes: a documented s2idle drain of 5 to 10 percent overnight, and a multi-day suspend empties the pack. On the older Framework 13 (AMD 7040) the same area shows up as suspend being shaky until BIOS 3.05, which is the more important detail than any kernel flag: a firmware update moved that machine from “tweak” toward stable. Keep the Framework BIOS current before you blame Linux.
What acpi_osi actually does
The workaround people reach for is a kernel command-line parameter,
usually acpi_osi="Windows 2020" or similar. It does not fix power
management directly. The ACPI firmware tables in many laptops branch on
which operating system is asking: they expose different power and device
behaviour to “Windows” than to anything else, because the vendor only
validated the Windows path. Setting acpi_osi makes Linux claim a
specific Windows version so the firmware hands it the better-tested code
path, which on some boards lets devices reach the deep idle states they
were skipping. It is a “lie to the firmware so it stops penalising you”
flag, not a power-saving feature, and whether it helps is board and
BIOS-version specific. Test it, measure the overnight drain with and
without, keep it only if the number actually drops.
The other levers worth knowing: amd_pmc debugging exposes which device
blocked the deepest s2idle state on AMD platforms, the SSD’s APST
behaviour is a common culprit, and the kernel version matters because
AMD s2idle handling has improved release over release. Our
Framework 13 (AMD Ryzen AI 300)
report puts the Fedora floor at kernel 6.12 with the note that s2idle is
improving with that kernel, and flags Ubuntu LTS as needing 24.10 or
newer, with suspend graded broken on the older stack. A Strix Point
Framework on Ubuntu 24.04 GA is the bad combination. The same hardware
on Fedora 41-plus or Ubuntu 24.10-plus with a 6.12 or newer kernel is
materially better.
The honest take
This is a real issue and Framework’s own forums are full of it, so anyone telling you the Framework 13 just works on Linux with no qualifiers is selling something. The drain is genuine, it is worse than Windows because the firmware was tuned for Windows, and a multi-day closed-lid suspend can come back to a dead battery.
It is also not a hardware defect and not unique to Framework. Almost
every s2idle-only laptop has some version of this, the
ThinkPad T14 Gen 5 (AMD) note
calls out needing acpi.ec_no_wakeup=1 on some units for the same class
of problem. What you get on Framework that you do not get elsewhere is
the thing that actually fixes it long term: BIOS updates you can
install, replaceable parts, and a vendor that ships firmware fixes for
exactly these s2idle quirks. The 7040 model’s jump at BIOS 3.05 is the
proof.
The recommendation: if you close the lid for an hour at lunch, the 5 to
10 percent figure is a non-issue, ignore it. If you routinely leave the
laptop suspended for two or more days and expect charge left, either
hibernate instead of suspend, or pick an all-AMD machine with a known
stable s2idle profile like the
Tuxedo InfinityBook Pro 14 Gen10,
graded suspend ok on Ubuntu LTS. For everyone in between, run a current
kernel, keep the BIOS updated, test acpi_osi and measure it, and buy
the Framework for the reasons you were buying it anyway.