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.