FW13 AMD Battery drained completely 2 times

Framework Laptop 13 Linux
1

Framework Laptop 13 hardware

Since a bit more then a month I am a proud owner of a new DIY FW 13 AMD 7640U - 2.8K Display, runnin BIOS version 03.05. I added a WD Black SN770 2 TB and 2 16 GB Crucial (CT2K16G56C46S5) RAM, installed a Fedora 40 on it and was quite happy with it.

Until after a few days of not using it, the battery was completely drained. At first I thought that it is maybe a bad configuration, where I entered init 0 to shut it off but closed the lid too fast and it went into hibernate instead (since that was the default action of my KDE in that case) so I changed the setting to “power off” and hoped for the best.

After this first incident I ran into this problem and fixed it by using the BIOS battery disconnect.

A few days later I again used init 0 to shut it off and wait for the screen and power-button to go dark. That was on Monday the 18.11.2024 on Friday (22.11.2024) the battery again was fully drained. So it feels to me more like a hardware then a software problem.

Do you have any ideas what I can do to not have the battery drain on me?
I really dislike the idea of destroying the Battery by deeply discharging it accidentally.
Also after the first incident I started the Laptop every day to check on the battery and it was always fine (89% with a charging limit set to 90%).

Also I now went ahead and store the laptop without any expansion cards, during the first incident I had 2 USB-A in the left and right front slot and 1 USB-C back left slot and 1 Ethernet, back right slot installed, during the second incident I had 2 USB-A (again both front slots) and 2 USB-C (both back slots) installed.

1 Like
2

There are some known issues with sleep/suspend around battery drain, but some people have had some success with some scripts, see the two below threads.

Personally I run Fedora 41 and get about 8-9% drain over about 9-10 hours.

3

I researched these topics before posting mine and I believe them to be unrelated since I am using init 0 to shut the laptop down.

man runlevel presents me with this table:

Table 1. Mapping between runlevels and systemd targets
       +----------+-------------------+
       | Runlevel | Target            |
       +----------+-------------------+
       | 0        | poweroff.target   |
       +----------+-------------------+
       | 1        | rescue.target     |
       +----------+-------------------+
       | 2, 3, 4  | multi-user.target |
       +----------+-------------------+
       | 5        | graphical.target  |
       +----------+-------------------+
       | 6        | reboot.target     |
       +----------+-------------------+

where you can see that init 0 is not engaging suspend/hibernate mode but rather powers the laptop off. So I believe my topic to be separate and most likely an hardware Issue, that’s why I posted it in the community-support category, but sadly it got moved away.

This actually brings me to a side question:
How do I know if the laptop is off or in suspend/hibernate mode?
My Lenovo T15 from work has a small LED at the back of the screen, which shows me the state, having this on (one of the two) FW13 LEDs would be a really useful feature for me right now.

In case I missed something and you still believe that my topic is a suspend/hibernate mode topic in disguise please let me know what I missed and what you think about it.

1 Like
4

Since you verified to a reasonable extent that the laptop was indeed powered off, I think it’s fair to assume it’s a hardware problem. In this situation your battery is probably the best suspect: I’d ask Framework for replacement and see if it helps. If you want to play it really nice, you can first try to test the battery outside of the laptop: charge it normally to your usual 89-90%, remove it from the laptop for a few days, then install it back and see what the charge will be.
Hope you will pinpoint this issue!

1 Like
5

That’s a really great idea, do you believe I should physically disconnect the battery or is the BIOS battery disconnect sufficient?

6

there can be for example a bug in the bios that is the root cause of this issue, so I think it’s way better to physically remove it to be 100% sure.

7

They seem to move all stuff that has anything to do with linux into the linux forum, even support things despite having tags for linux within the community support.

You could check dmesg to see what power state it’s going into.

Eg, mine says the below for suspend:

[51335.929751] PM: suspend entry (s2idle)
[51335.981011] Filesystems sync: 0.051 seconds
[51336.007013] Freezing user space processes
[51336.010070] Freezing user space processes completed (elapsed 0.003 seconds)
[51336.010076] OOM killer disabled.
[51336.010077] Freezing remaining freezable tasks
[51336.011557] Freezing remaining freezable tasks completed (elapsed 0.001 seconds)
[51336.011563] printk: Suspending console(s) (use no_console_suspend to debug)
[51336.025951] queueing ieee80211 work while going to suspend
[51336.154033] PM: suspend devices took 0.142 seconds
[51336.156068] ACPI: EC: interrupt blocked

Then resume

[85042.033682] ACPI: EC: interrupt unblocked
[85042.247706] nvme nvme0: D3 entry latency set to 8 seconds
[85042.247706] nvme nvme0: D3 entry latency set to 8 seconds
[85042.252233] [drm] PCIE GART of 512M enabled (table at 0x00000080FFD00000).
[85042.252375] amdgpu 0000:c1:00.0: amdgpu: SMU is resuming...
[85042.256558] amdgpu 0000:c1:00.0: amdgpu: SMU is resumed successfully!