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!

2 Likes
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!
1 Like
8

Thank you very much.
I was looking for a way to physically tell if the laptop is down or in hibernate, like an LED blinking, maybe a BIOS setting to make the LED blink as long as it is in hibernate.
Since the problem I am facing is that in order to check if the system is powered down I need to switch in on to have a look at the log files and once it is online I need to switch it back off and the cycle repeats.

As far as I understand it the dmsg is the display of the kernels ring buffer and will be deleted on reboot. So instead of dmsg I had a look at /var/log /messages.
Here is the interesting part of it:

Nov 18 21:09:02 framework systemd[1394]: session.slice: Consumed 8.759s CPU time, 1.4M memory peak, 0B memory swap peak.
Nov 18 21:09:02 framework systemd[1394]: Closed dbus.socket - D-Bus User Message Bus Socket.
Nov 18 21:09:02 framework systemd[1394]: Removed slice app.slice - User Application Slice.
Nov 18 21:09:02 framework systemd[1394]: app.slice: Consumed 6.326s CPU time, 3.4M memory peak, 0B memory swap peak.
Nov 18 21:09:02 framework systemd[1394]: Reached target shutdown.target - Shutdown.
Nov 18 21:09:02 framework systemd[1394]: Finished systemd-exit.service - Exit the Session.
Nov 18 21:09:02 framework systemd[1394]: Reached target exit.target - Exit the Session.
Nov 22 14:45:55 framework chronyd[977]: Selected source 192.168.178.1 (_gateway)
Nov 22 14:45:55 framework chronyd[977]: System clock wrong by 3678344.958853 seconds
Nov 22 14:45:55 framework systemd-resolved[914]: Clock change detected. Flushing caches.
Nov 22 14:45:55 framework chronyd[977]: System clock was stepped by 3678344.958853 seconds
Nov 22 14:45:55 framework chronyd[977]: System clock TAI offset set to 37 seconds
Nov 22 14:45:55 framework rsyslogd[955]: imjournal: journal files changed, reloading...  [v8.2312.0-1.fc40 try https://www.rsyslog.com/e/0 ]
Nov 22 14:45:55 framework sddm-greeter-qt6[1219]: file:///usr/share/sddm/themes/01-breeze-fedora/Main.qml:230:17 Parameter "username" is not declared. Injection of parameters into signal handlers is deprecated. Use JavaScript functions with formal parameters instead.
Nov 22 14:45:55 framework sddm-helper[1488]: Detected locale "C" with character encoding "ANSI_X3.4-1968", which is not UTF-8.#012Qt depends on a UTF-8 locale, and has switched to "C.UTF-8" instead.#012If this causes problems, reconfigure your locale. See the locale(1) manual#012for more information.
Nov 22 14:45:55 framework audit[1488]: USER_AUTH pid=1488 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:authentication grantors=? acct="malte" exe="/usr/libexec/sddm-helper" hostname=? addr=? terminal=? res=failed'

As you can see by the system clock being way off, the battery was completely drained and it exited before without an problems.

Also I went ahead and disconnected the battery for the last week and checked daily at first and then after 3 days and every time the battery was at 90% (which is the loading limit I set up).
To me this feels like it is maybe a main board issue, what do you think?

9

Most probably: my bet would be that something is shorting slightly on the mobo and slowly but surely drains the battery. I’d report it to the Framework support and ask for the mobo replacement unless they have some better ideas.

10

For what it’s worth, I’ve observed similar behaviour in my brand-new AMD Framework 13. Whatever it is, I don’t think it’s likely to be a random hardware fluke in your unit. It might be possible that most people don’t fully shut down when closing up their laptops, so the “high drain in sleep mode” problem might be due to the same root cause (and isn’t due exclusively to sleep).

11

Given these steps described by the OP, I strongly believe he in fact did completely powered off his machine. Perhaps it may be some “common hardware fault” of these AMD mobos. It would be good if anyone with similar problem reported it here so that we know how “common” it is.

How about your case? Have you tried some more controlled testing of this issue? I mean like make sure for 100% that the laptop was fully powered-off then leave it for a few days to see if it happens every time?

12

This fixes high power consumption in S5 triggered by Linux shutdown.

https://lore.kernel.org/linux-pci/20240712062411.35732-1-kai.heng.feng@canonical.com/

1 Like
13

From what the description of the patch says, it fixes spurious wake-ups caused by connected USB devices (some specific TB dock is mentioned). @Malte , @Wolf_Logan could you guys please confirm/deny if you had any USB devices connected when the drains happened? Also could you please check if the kernels you use have this patch included?

Also on AMD mobo expansion card slots 1&3 combined with USB-A expansion cards cause higher power consumption: maybe this is somehow related?

14

It helps all PCIe devices. If they’re not put into D3 they stay on when you shut the machine.

2 Likes
15

apologies, I should have read the whole thread there… :wink:
…which also explains, that this patch is still being discussed on LKML and thus probably not included by most distros: @Malte, looks like you will have to patch and build your own kernel image to see if it helps with your specific problem…

16

Yes I had these USB devices installed:

So I never used USB-A cards in slot 1 or 3

Since I had a feeling about the USB-C cards too, I removed all expansion cards from the laptop and since I did that I hadn’t any problems with drained battery.
Also I opened up a ticket at framework support. and they advised me to reset the BIOS and wait to see if the battery drains again.

I just checked again and the battery is fine, but the laptop has no expansion cards installed at the moment.

also since @Wolf_Logan seems to experience the same issue it feels less likely to be a one of a time hardware issue. maybe you can try to store the laptop without expansion cards too and report if it drains again.

1 Like
17

Just linking to my experience: Laptop powered off, battery empty after 3 days

In my case the interaction with support was mostly inconclusive. Since the laptop is my main work PC I can’t afford to let it powered off for days to replicate the issue but things appear to have been stabilized, I wonder if the patch linked above helped (I’m running debian unstable, currently with kernel 6.12.3)

1 Like
18

Since my last update on the issue I didn’t had any problems with battery drainage at all. Since the second incident I changed two things that might be the reason why it now works well:

  1. Reset the BIOS.
  2. Store the laptop with only one USB-C connector in the upper left position (slot 1).

I personally believe that battery drainage is due to the USB connectors but can’t really prove it. While storing the laptop without any (active) USB expansion cards seems to work and is certainly a good workaround, as a long term solution it feels rather unsatisfying to me and it would be really great if framework could investigate in the topic some more and maybe release a BIOS update that fixes the issue.

1 Like
19

Here are my new reports regarding the FW AMD laptop 13:

in the past weeks I did quite some extensive testing:

Time,Battery [%],USB-C Connectors
04.01.2025 12:47,"88",USB-C 1
04.01.2025 13:00,"87",USB-C 1; Network 2
04.01.2025 13:53,"87",USB-C 1; Network 2
04.01.2025 16:25,"87",USB-C 1; Network 3
04.01.2025 21:27,"86",USB-C 1; Network 3
05.01.2025 09:30,"85",USB-C 1; Network 3
05.01.2025 11:14,"84",USB-C 1; Network 3; USB-A 2
05.01.2025 12:54,"84",USB-C 1; Network 3; USB-A 2
05.01.2025 15:00,"84",USB-C 1; Network 3; USB-A 2
05.01.2025 12:11,"83",USB-C 1; Network 3; USB-A 2
05.01.2025 21:11,"83",USB-C 1; Network 3; USB-A 2
06.01.2025 09:50,"80",USB-C 1; Network 3; USB-A 2; USB-A 4
06.01.2025 11:37,"80",USB-C 1; Network 3; USB-A 2; USB-A 4
06.01.2025 15:39,"80",USB-C 1; Network 3; USB-A 2; USB-A 4
07.01.2025 11:55,"78",USB-C 1; Network 3; USB-A 2; USB-A 4
07.01.2025 13:45,"77",USB-C 1; Network 3; USB-A 2; USB-A 4
08.01.2025 17:20,"75",USB-C 1; Network 3; USB-A 2; USB-A 4
09.01.2025 09:00,"74",USB-C 1; Network 3; USB-A 2; USB-A 4
09.01.2025 18:30,"73",USB-C 1; Network 3; USB-A 2; USB-A 4
10.01.2025 12:45,"71",USB-C 1; Network 3; USB-A 2; USB-A 4
10.01.2025 19:26,"69",USB-C 1; Network 3; USB-A 2; USB-A 4
11.01.2025 13:18,"68",USB-C 1; Network 3; USB-A 2; USB-A 4
12.01.2025 12:45,"66",USB-C 1; Network 3; USB-A 2; USB-A 4
13.01.2025 21:41,"64",USB-C 1; Network 3; USB-A 2; USB-A 4
15.01.2025 09:16,"61",USB-C 1; Network 3; USB-A 2; USB-A 4
16.01.2025 10:07,"59",USB-C 1; Network 3; USB-A 2; USB-A 4
16.01.2025 16:45,"58",Trial without any slots
17.01.2025 12:45,"56",Trial without any slots
19.01.2025 11:39,"51",Network 3;
21.01.2025 11:22,"49",Network 3;
24.01.2025 15:22,"44",Network 3;
25.01.2025 13:32,"90", battery charged

The numbers of the slots refere to this image. During this testing I did not had any issues with fast battery drainage. On the 25.01.25 I stop my experiments and stowed the laptop away.

On the 06.02.2025 I opened it up again and the battery was 79% charged, which for 12 days feels like a lot of discharge, especially since I’m not planning to use the laptop daily.
My old Lenovo x230 survived for half a year in the closet without much discharge at all.
I started the laptop and loaded the battery back to 90% then used init 0 as a normal user and stored it with only one USB-C adapter plugged in slot 1.

Somewhere I read that using a mouse (and look if the LED is on) is a good idea to test if the USB-A still has power. This method has its limits since (at least my) mouse only works on USB-2 which makes it hard to check if power is present. But I found out that using a external USB-3 hard-disk works well.

On the 08.02.25 I first added the USB-A adapter and a external USB-3 hard-drive and the hard-drive immediately powered on, so it was on power for the last 2 days. When I booted the laptop it had 29% battery left, so I recharged it completely.

After I rebooted the laptop I plugged a mouse in and it was dark, I plugged the hard-disk in the same slot and it was working (LED and sound/vibrations of the rotating disks).
It did not matter in which slot I added the hard-disk (I tried 2 and 3).

I kept testing with the Laptop on a power-source, and hard-disk running. Then I shut the laptop down and the hard-disk was still running. Also when I shot the laptop down and after it was offline I added the harddisk and it was sill powering up. While after adding it after some time ~20 mins it was not powering up anymore.

On the 16.02.2025 the laptop had 82% battery.

The conclusions I found are:

  1. The discharge rate even in normal operation is abnormal high and since I’m planing to use the laptop not that often i’m not super happy with that.
  2. The full drain within 2-3 days is connected to the USB slots not fully powering down.
    1. Maybe sometimes (for whatever reasons) the laptop does not shuts down fully after an init 0 and the 20 mins wait time.
  3. It doesn’t matter much if you store the laptop with slots plugged in or not.

EDIT: I did another test today (18.02.25):
When I first add the USB-C docking-station for power supply to the switched off laptop and then the hard-drive, the hard-drive powers on immediately. After the laptop was fully charged again, I removed the USB-C power supply and the hard-drive was still powered, about 15mins later it was also powered down. I believe this is how it should be, so maybe something within the mainbord sometimes stays online after the 15mins and that is what drains the battery.

2 Likes
20

In the meantime I talked to the Framework customer support. They advised me to perform a mainboard reset, which sounded like a good idea so I did it.
You do it by:

  • Plug in the system to AC.
  • Remove the Input Cover.
  • Press the chassis open switch in the center of the Mainboard 10 times, you must press it slowly, so press for 2 seconds. Release, wait for the red blink on the Mainboard LEDs. repeat.
  • Press the power button to boot the system
  • BIOS settings will be reset to defaults.

After doing so I checked if it worked, by seeing that the BIOS indeed resetted (power LED brightness switched from medium back to the default of high and the battery charging limit was from my value of 90% back to 100%).

Over the weekend (22.02.2025 and 23.02.2025) I installed nvtop and powertoop (without AC connected), but the results looked all fine to me, I believe it is not OS related.
On the 23.02.2025 20:20 I charged the battery up to 90% again by just plugging it into the USB-C dockingstation, once it was fully charged I bootet it up for a small check and then used init 0 as root to shut it off.

Yesterday, the 27.02.2025 21:28 I started to boot the laptop again and nothing happend, after hooking it up to AC it bootet again and I could see that the battery was completely drained again.
Since my initial suspicion was that the ultra fast drainage was related to charging the laptop without switching it on, I used the last command to check if I actually switched the laptop on on the 23.02.2025. Here is the interesting part of the last command:

    framework:~ # last
    root     pts/2        192.168.178.24   Thu Feb 27 21:30   still logged in
    malte    pts/1        :0               Thu Feb 27 21:30   still logged in
    malte    pts/0        :0               Thu Feb 27 21:27   still logged in
    malte    tty2                          Thu Feb 27 21:27   still logged in
    reboot   system boot  6.12.5-200.fc41. Sat Dec 21 00:59   still running
    malte    pts/1        :0               Sun Feb 23 20:20 - down   (00:00)
    malte    pts/0        :0               Sun Feb 23 20:19 - 20:20  (00:00)
    malte    tty2                          Sun Feb 23 20:19 - down   (00:00)
    reboot   system boot  6.12.5-200.fc41. Sun Feb 23 20:19 - 20:20  (00:00)
    malte    pts/3        :0               Fri Feb 21 16:57 - down   (00:09)
    malte    pts/2        :0               Fri Feb 21 16:57 - down   (00:09)

But as you can see this suspicion is not holding up.

By now I am out of ideas and also running low on patience. In the current state the laptop is unusable for me, since im not using it on a day-to-day basis.

EDIT:

Framework support asked me to run sudo dnf install tlp -y and sudo tlp-stat -b

    --- TLP 1.6.1 --------------------------------------------

    +++ Battery Care
    Plugin: generic
    Supported features: none available

    +++ Battery Status: BAT1
    /sys/class/power_supply/BAT1/manufacturer                   = NVT
    /sys/class/power_supply/BAT1/model_name                     = FRANGWA
    /sys/class/power_supply/BAT1/cycle_count                    =      5
    /sys/class/power_supply/BAT1/charge_full_design             =   3915 [mAh]
    /sys/class/power_supply/BAT1/charge_full                    =   3927 [mAh]
    /sys/class/power_supply/BAT1/charge_now                     =   3537 [mAh]
    /sys/class/power_supply/BAT1/current_now                    =      0 [mA]
    /sys/class/power_supply/BAT1/status                         = Charging

    /sys/class/power_supply/BAT1/charge_control_start_threshold = (not available) 
    /sys/class/power_supply/BAT1/charge_control_end_threshold   = (not available) 

    Charge                                                      =   90.1 [%]
    Capacity                                                    =  100.3 [%]

Here is the result of that one and also the result of the framework_tool

  AC is:            connected
  Battery is:       connected
  Battery LFCC:     3927 mAh (Last Full Charge Capacity)
  Battery Capacity: 3537 mAh
                    60.992 Wh
  Charge level:     90%
  Manufacturer:     NVT
  Model Number:     FRANGWA
  Serial Number:    0328
  Battery Type:     LION
  Present Voltage:  17.244 V
  Present Rate:     0 mA
  Design Capacity:  3915 mAh
                    60.604 Wh
  Design Voltage:   15.480 V
  Cycle Count:      5
  Battery charging
1 Like