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.
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.
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.
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!
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!
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?
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.
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).
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?
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?
apologies, I should have read the whole thread there…
…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…
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.
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)
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:
Reset the BIOS.
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.
