You are not logged in.
Pages: 1
Hello,
I have been running into some problems with power management on my thinkpad T14. The machine is relatively new, I installed arch in late February/early immediately after getting it.
I am running the latest linux-hardened (5.18.6) with an Xfce (4.16). A few weeks ago, about June 08 I updated all the packages with pacman. Soon after, I had some sudden shutdowns only to find that the battery was zero upon restarting and charging. In xfce4-power manager I have the critical battery capacity at 7% , but this is routinely ignored, but more frequently it is never reached at all.
So I looked at the packages in the pacman cache, thinking xfce4-power-manager was bad. But alas, it was not one of the updated packages so it can't be the issue since it worked before. In fact, it had been quite some time since I updated all packages, maybe since early to mid march. Since I knew I had a working system up until that point, I played around with force downgrading all packages to various dates---reasoning as the problematic versions could have started whenever. Surprisingly, this failed, even when I wound the clock back all the way to march when I first got Xfce and linux-hardened up and running.
I've mucked around with Upower for a bit, starting and restarting with systemctl but with little effect.
The typical sequence goes like this:
26%
25%
24%
[prompt appears at 24%, showing shutdown/logout or cancel options but NO suspend]
[press cancel]
0%
[laptop shuts down if I'm not quick enough with the charger, and will be at 0% upon rebooting]
The strangest part is that it isn't consistent. I have had the above sequence at an indicated 13%, 19%, 20% etc. The fact that it shuts down leads me to believe that the reading is simply wrong, and thus it will never reach the ask level before running out of physical charge.
But on the other hand, setting the critical level to an arbitrary 30% in the xfce4-power-manager setting dialog results in an on-screen notification suggesting battery is on low power at 30%, but it does not perform the "ask" options by giving a prompt. After doing this and seeing the notification, re-opening the xfce4-power-manager settings GUI shows the critical level at 10%. It seems not to save anything higher than 20%, so basically (returns 10 if x >= 20; else x).
Charging the laptop fully, I am suspicious that it hangs around at 99% longer than it should, suggesting perhaps the reading is too high (it thinks it's over 100%), but I have no quantitative proof of this.
Any ideas?
upower 0.99.19-1
xfce4-power-manager 4.16.0-3Offline
Hi!
The first thing to check is an UEFI update/upgrade (current should be version 1.51 on T14 Gen2), if available and the threshold settings defined there as they are the ones used by the device itself. Then check the errors in `journalctl -b -p err`. You can read the battery states manually in /sys/class/power_supply/BAT#/ where # is usually 0. Check e.g. `cat /sys/class/power_supply/BAT0/charge_full{,_design}` to get the battery health.
Offline
How do I check the actual UEFI version number? Searching just gave me results for windows or how to simply check the obvious: it is 64 bit.
Anyway, here is journal -b -p err:
Jun 27 13:21:08 lm kernel: ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PC00.RP09.PEGP.DDNT], AE_NOT_FOUND (20211217/psargs-3>
Jun 27 13:21:08 lm kernel: ACPI Error: Aborting method \_SB.PC00.LPCB.EC.SEN4._TMP due to previous error (AE_NOT_FOUND) (20211217/pspa>
Jun 27 15:07:43 lm kernel: ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PC00.RP09.PEGP.DDNT], AE_NOT_FOUND (20211217/psargs-3>
Jun 27 15:07:43 lm kernel: ACPI Error: Aborting method \_SB.PC00.LPCB.EC.SEN4._TMP due to previous error (AE_NOT_FOUND) (20211217/pspa>I don't know if any of these are related to battery.
Also, forgot to mention that reading the battery states in "/sys/class/power_supply/BAT0" just returns what is shown by the Xfce power manager icon.
Aha! So, just now the Xfce tray showed 62% but the capacity in BAT0 showed 37%. I just plugged the charger back in only to have the icon update itself to read the correct percentage. After unplugging, it is now ticking down as expected and is in tune with the BAT0 readings. So sometimes it is accurate, sometimes it isn't. It seems that for some reason the power manager fails to update in certain cases, as if the process gets suspended.
Also, we have "energy" instead of charge, giving
cat energy_full_design
51000000
cat energy_full
44370000I don't know the units on this, but it seems some energy has been lost. However, I don't think that's the cause of the problem.
Offline
Ok, I spoke too soon: it happened again just now. Had a terminal window open to periodically check the battery and I suddenly ran into the emergency ask popup, this time at 23%, and upon answering it jumped back to zero percent again.
[root@lm BAT0]# cat capacity
38
[root@lm BAT0]# cat capacity
37
[root@lm BAT0]# cat capacity
36
[root@lm BAT0]# cat capacity
35
[root@lm BAT0]# cat capacity
34
[root@lm BAT0]# cat capacity
30
[root@lm BAT0]# cat capacity
28
[root@lm BAT0]# cat capacity
27
[root@lm BAT0]# cat capacity
24
[root@lm BAT0]# cat capacity
23
[root@lm BAT0]# cat capacity
0It appears the level in /sys/class/power_supply/BAT0 isn't accurate either. Suggesting again the power manager is fine, since it is just reading from there.
Offline
How do I check the actual UEFI version number? Searching just gave me results for windows or how to simply check the obvious: it is 64 bit.
64bit is the architecture, not a uefi version. `dmidecode -s bios-version` should do it (needs root permission).
Anyway, here is journal -b -p err:
Unknow symbols are "normal". Could vanish on a new firmware version or sometimes on a new kernel version. Check for your battery using `acpi -bi` or `acpi -V` for everything available, as you have upower installed you could also use `upower -i /org/freedesktop/UPower/devices/battery_BAT0` or corresponding DBus methods. But they all just know what the kernel tolds them and thats what you already found in /sys/class/power_supply.
Little hint: You did cut off the messages (see the > at line end). If you want to post journalctl-stuff or similar don't use a pager (like most, more, less) or redirect the output to a text file.
journalctl -b -p err > /tmp/my_journal_export
# or
journalctl --no-pager -b -p err…62% but the capacity in BAT0 showed 37%.…
Stop the xfce power manager and run it in debug mode. Should be `xfce4-power-manager --debug` but I currently got no xfce to verify.
Also, we have "energy" instead of charge, giving…
Different things. Energy is the current level of usable energy until you have to recharge. The battery health values are the overall health of your battery and how much energy it aleady lost. As batteries get older 100% depends on the health. If it is too low or the battery damaged it can cause errors.
I don't know the units on this, but it seems some energy has been lost. However, I don't think that's the cause of the problem.
That are just the bare values. `echo "scale=2;44370000/51000000" | bc` → 0.87, so your battery hat 87% of charge.
So check the uefi version used, debug the xfce power manager and perhaps you could in parallel check `dbus-monitor --system path=/org/freedesktop/UPower/devices/battery_BAT0` to be sure that the battery state gets updated on a lower level (upower).
Offline
dmidecode needed root permission, but no big deal:
N34ET46W (1.46 )So I do not have the latest version. I have installed fwupd and followed the instructions for doing a UEFI update in the wiki. I confirmed that I'd be getting the 1.5 version, ran it, rebooted and upon logging back in it appears nothing has happened. Still running the old version, but now I have stuff in the /EFI directory of my boot partition. Do I need to manually load them using efibootmgr or something?
Either way, looking at the version dates it seems 1.46 was released before I got the laptop, and since it worked before it seems strange that it would give any trouble now. May or may not be the actual problem.
Moving on: from upower -i /org/freedesktop/UPower/devices/battery_BAT0.
native-path: BAT0
vendor: Celxpert
model: 5B10W51829
serial: 5679
power supply: yes
updated: Mon 27 Jun 2022 09:11:57 PM EDT (1 seconds ago)
has history: yes
has statistics: yes
battery
present: yes
rechargeable: yes
state: discharging
warning-level: none
energy: 33.95 Wh
energy-empty: 0 Wh
energy-full: 44.37 Wh
energy-full-design: 51 Wh
energy-rate: 15.449 W
voltage: 11.41 V
charge-cycles: 365
time to empty: 2.2 hours
percentage: 76%
capacity: 87%
technology: lithium-polymer
icon-name: 'battery-full-symbolic'
History (charge):
1656378687 76.000 discharging
History (rate):
1656378717 15.449 discharging
1656378687 15.423 discharging
1656378657 15.412 discharging
1656378627 15.405 dischargingPercentage 76% is what I also see on the status tray. Capacity appears to show the percent of the total original charge, so out of full-design I would have 66% of the original total currently. I don't have variables for "charge_full_design/etc". Only energy_full.
Didn't see anything suspicious on xfce4-power-manager --debug.
For dbus-monitor --system path=/org/freedesktop/UPower/devices/battery_BAT0, things seem ok. It periodically spits out messages with the various values, but only the ones that have changed (which I assume is what's supposed to happen). I'll probably leave these going until I get down to ~24% indicated percent to see if anything weird happens. That's usually around when it jumps to zero.
Offline
Ok, this time at 26% indicated:
signal time=1656383644.837730 sender=:1.14 -> destination=(null destination) serial=4882 path=/org/freedesktop/UPower/devices/battery_BAT0; interface=org.freedesktop.DBus.Properties; member=PropertiesChanged
string "org.freedesktop.UPower.Device"
array [
dict entry(
string "UpdateTime"
variant uint64 1656383644
)
dict entry(
string "TimeToEmpty"
variant int64 2739
)
dict entry(
string "Voltage"
variant double 9.555
)
dict entry(
string "Percentage"
variant double 26
)
dict entry(
string "EnergyRate"
variant double 15.679
)
dict entry(
string "Energy"
variant double 11.93
)
]
array [
]
signal time=1656383674.856633 sender=:1.14 -> destination=(null destination) serial=4895 path=/org/freedesktop/UPower/devices/battery_BAT0; interface=org.freedesktop.DBus.Properties; member=PropertiesChanged
string "org.freedesktop.UPower.Device"
array [
dict entry(
string "UpdateTime"
variant uint64 1656383674
)
dict entry(
string "TimeToEmpty"
variant int64 2733
)
dict entry(
string "Voltage"
variant double 9.415
)
dict entry(
string "EnergyRate"
variant double 15.553
)
dict entry(
string "Energy"
variant double 11.81
)
]
array [
]
signal time=1656383704.899704 sender=:1.14 -> destination=(null destination) serial=4906 path=/org/freedesktop/UPower/devices/battery_BAT0; interface=org.freedesktop.DBus.Properties; member=PropertiesChanged
string "org.freedesktop.UPower.Device"
array [
dict entry(
string "UpdateTime"
variant uint64 1656383704
)
dict entry(
string "TimeToEmpty"
variant int64 2697
)
dict entry(
string "Voltage"
variant double 9.206
)
dict entry(
string "EnergyRate"
variant double 15.585
)
dict entry(
string "Energy"
variant double 11.68
)
]
array [
]
signal time=1656383725.727222 sender=:1.14 -> destination=(null destination) serial=4917 path=/org/freedesktop/UPower/devices/battery_BAT0; interface=org.freedesktop.DBus.Properties; member=PropertiesChanged
string "org.freedesktop.UPower.Device"
array [
dict entry(
string "UpdateTime"
variant uint64 1656383725
)
dict entry(
string "IconName"
variant string "battery-caution-symbolic"
)
dict entry(
string "WarningLevel"
variant uint32 5
)
dict entry(
string "TimeToEmpty"
variant int64 0
)
dict entry(
string "Voltage"
variant double 8.978
)
dict entry(
string "Percentage"
variant double 0
)
dict entry(
string "EnergyRate"
variant double 0
)
dict entry(
string "Energy"
variant double 0
)
]
array [
]Suddenly, we go from TimeToEmpty: int64 2697 ----> int64 0 in one message. Percentage also 0. Strangely, the energy and energy rate also goes to zero, the machine is still running so it should be using power, right?
Likewise, on xfce4-power-manager:
TRACE[xfpm-power.c:804] xfpm_power_battery_charge_changed_cb(): Current system charge status: ((XfpmBatteryCharge) XFPM_BATTERY_CHARGE_CRITICAL)
TRACE[xfpm-power.c:773] xfpm_power_system_on_critical_power(): System is running on low power
TRACE[xfpm-power.c:774] xfpm_power_system_on_critical_power(): Critical battery action: ((XfpmShutdownRequest) XFPM_ASK)Since a few times I was not quick enough to grab the charger, I can safely say that the 0% reading is probably accurate. The question remains: why is the reading over 20% too high before running out of power?
Offline
Did you have a look in uefi for power settings? Are there any thresholds configured? I can only set charge behaviour in mine (from at least 50% to 100%) but have no option for low battery states.
Check with the default linux kernel and linux-lts instead of the hardened one just to be sure it happens there too. If it does I suggest you pull a request on bugzilla.kernel.org as my knowledge ends on reading battery values and device drivers and my searches result in "needs vendor specific driver support". If it does not, file a bug against linux-hardened instead. This can then be solved by a kernel (compile) option.
I think it should be a kernel thing as it did work properly earlier, but just check it to be sure.
Offline
How do I check uefi for power settings?
I figured out how to get the firmware updated, so I'm running 1.50 now, but still no luck. This time was even worse, it ran out at 30%. But it lingered on 99% for a very long time this time, so the whole range seems like it's shifted up.
I tried my regular arch boot installation, but no luck, same issue. Don't have linux-lts.
So that's linux-hardened 5.18, 5.17 (5.16? maybe, I still had the issue going back to older working versions). Actually, what I'll do now is go back and test versions until I get a normal behavior again, which will show which versions are affected.
Offline
Depends on the model. Upon starting at the ThinkPad logo there is a text message telling you how to enter setup. Newer TPs require Enter key, older ones the blue ThinkPad button or F1, F2 or DEL key pressed.
Can you check `journalctl -kg battery` with the new firmware? Should give you a single line like "ACPI: battery: Slot [BAT0] (battery present)".
You can install linux{,-lts} in parallel to your kernel and boot them using your bootloader (GRUB, systemd-boot,...). After testing you can remove them like any other package with pacman. Just make sure you have enough space on your boot partition if it is a separate one.
Offline
For journalctl -kg battery I get three lines:
Jun 30 11:59:35 lm kernel: ACPI: battery: Slot [BAT0] (battery present)
Jun 30 11:59:35 lm kernel: thinkpad_acpi: battery 1 registered (start 0, stop 100)
Jun 30 11:59:35 lm kernel: ACPI: battery: new extension: ThinkPad Battery ExtensionYeah, that was actually the problem with loading the new firmware the first time: I didn't have enough space on my EFI partition. I simply moved the regular arch and arch-fallback images out and put them back when the update was complete.
Currently I have linux 5.18.5 and linux-hardened 5.15.25 as my boot entries. Linux-hardened 5.15.25 was released in late February, and the problem still persists. I started using this computer in february, but only installed linux-hardened after a few weeks so this is probably even before the last working version. I am starting to doubt it is a kernel issue, at least directly.
Perhaps something got changed after I had a working version installed, whereas all new installations and re-installations just reproduce the bad setup/parameters.
Offline
I just wanted to know if the same is happening on the default kernel or lts kernel as this is the "baseline" to check for and I think it is kind of required to file an appropriate bug report. If we put all information together it should be a useful bug report. One thing that may be of interest is to check the behaviour on plugged to AC, on removing the plug after fully loaded and the first minutes after.
/edit: the three lines are looking good. Seems not to be a firmware problem.
Last edited by koffeinfriedhof (2022-06-30 18:57:35)
Offline
The same is happening on the default kernel (latest version). This, coupled with the fact that running older versions of linux-hardened has failed to solve the problem makes me hesitant to blame the kernel, yet. It worked before, and the problem started after updating all packages after an extended time, so it still could be another package, but not xfce4-power-manager or upower.
When I charge on AC the battery ticks up. I have noticed that when I run it all the way too 99% it stays at 99% after unplugging for a suspiciously long time. After which, when running all the way back down it repeats the problem of running out of power too early--early, as according to the capacity claimed by the kernel.
Just now as I'm typing this, I decided to unplug the AC after it reached only 12% when charging from zero, since the xfce4-power-manager is set at critical for 7% battery.
On clicking the icon, it claimed 12% with an estimated life of 12minutes. then to 16m, 13m, etc. I am running a process in python to make the waiting go quicker.
10%, 12m
10%, 18m, (3.58pm)
10%
0%, 4:00pm!
Then after reconnecting AC power we are on 1% at 4:01pm as I type this. It never reached 7% indicated so once again I never got the ask warning, only the emergency one at 0%.
I forgot to note the time when I was at 12%, but it certainly wasn't more than 5-6 minutes before 4:00pm.
So, it is a bit tricky and nonlinear to think about: was the original 12% correct and it was counting too slowly? Or was it never really at 12% at all, and it was counting down normally? I don't put too much stock into the lifetime estimation, since that depends on the power output which depends on what the computer is doing, if the fan is running, etc. But, it wasn't exactly counting down as the battery percentage dropped either.
I a few days ago in this thread I noticed the battery had stopped counting, and updated only when I plugged the charger back in, but that problem has not been recurring. I have been routinely unplugging and replugging and the reading doesn't typically change when doing either, even after waiting several minutes.
My next thought it is it could be a systemd problem. This, because upon rebooting one of the first things seen is "starting arch 251.2 so it is a process independent of the kernel I'm booting into. I tried to do a full 'pacman -Syyu' for older repo dates, (maybe beginning of June). I might not have went back far enough for systemd, though.
Offline
Okay. So lets do some simple logging and collecting.
#!/bin/bash
exec 2> /tmp/batterylog.err > /tmp/batterylog
printf "date |time |acpi|file|charge |Alarm|\n"
dbus-monitor --system --profile "type='signal',interface='org.freedesktop.DBus.Properties',path='/org/freedesktop/UPower/devices/DisplayDevice',member='PropertiesChanged'" |
while read -r line; do
d=$(date +'%y_%m_%d|%H:%M:%S')
a=$(acpi -b | cut -d, -f2)
b=$(cat /sys/class/power_supply/BAT0/{capacity,charge_now,alarm})
printf "|%s| %s|%3d%%|%7d|%5d|\n" $d $a $b
done(did we already check if there is a difference between acpi -b and upower?)
This will log to /tmp, so the file would be deleted upon reboot. Change the path if you want to keep, but every script start will overwrite the old data.
On every dbus signal concerning the battery (should be DisplayDevice) it will add one line to the table.
You can then file a bug report to https://bugs.freedesktop.org against upower. Add
upower -d
# and
find /sys/class/power_supply/BAT0/ -type f -print -exec cat "{}" \;to the battery data we've collected so far.
Offline
Ok, I made the log. But upower isn't the problem. The oldest file on my computer is apparently from Feb 17th, and I just tested upower 0.99.15-1 (Feb 10th) and nothing has changed. It cannot be a bug in upower.
Also, I do not have the package with acpi as a command, so acpi -b does nothing.
I've run numerous downgraded versions of packages and so far none of them have made a difference.
Offline
nvm. Took a short look at the code and it does also just print the files in /sys/class/power_supply if nothing provided in the acpi folder. You can lookup /proc/acpi for battery information. If nothing in it, e.g. /proc/acpi/battery, it uses power_supply.
So the logging does not contain the wrong values? I think it must be the kernel as all tools just parse this values. The uefi just does its own stuff, like setting charge threshold, but I don't know how to access it from command line. Does `systemctl status acpid` print anything helpful?
// Another idea: Get an iso with an old kernel version and live mode like Debian and check the behaviour.
Last edited by koffeinfriedhof (2022-07-03 09:15:45)
Offline
No, the log contains the wrong values. It just isn't very useful, since it doesn't explain why the values are wrong. Here is a sample:
|22_07_01|17:25:59| 32|14200000%|2218000| 0|
|22_07_01|17:26:29| 31|14030000%|2218000| 0|
|22_07_01|17:26:59| 31|13920000%|2218000| 0|
|22_07_01|17:27:11| 0| 0%|2218000| 0|
|22_07_01|17:27:20| 0| 0%|2218000| 0|
|22_07_01|17:27:21| 0| 0%|2218000| 0|Which is just what I've been describing before. (Also, your script seems to print out the values in a different order than you were anticipating).
Well I'm completely at a loss. I just tested regular arch 5.16 (current around early February) and the problem persists. I'm also using upower and systemd from the same repo dates. Does loading a different kernel version restart the measurement of battery or does it simply start from the last recorded values? I'm still confused, since allegedly at 0% it must be accurate. Meaning if I run it down on a proven kernel version it should be accurate when charging back up if the kernel is really the problem. Why then, does it become inaccurate only after recharging the battery up? And then fails to count down accurately when discharging?
For systemctl status acpid
acpid.service could not be foundSeems weird if acpid was something I had before, but lost somehow.
Last edited by Mike_Hawk (2022-07-04 03:34:19)
Offline
The values differ as acpi does not exist and $a is empty which results in printf seeing one variable less, so everything is moved a column left. To correct it you could install acpi, remove the part or change the line to a="n/a". Implementing error handling and/or file checks just blow it up which is not necessary in this case.
You could try installing acpid to see if there are improvements, but the main thing is that those values come directly from the battery(-controller) and are not calculated or similar. So it is either a bug in the battery driver, a uefi option setting threshold to ~25% or a disfunctional battery controller. Again, file a kernel bug and see if someone can help you. I can't go "deeper" into the system without guessing around.
Offline
Just to mention the elephant in the room: if your battery had been working fine previously and is now randomly powering down, it might be close to dying...
Stuff to try:
- try to replicate the issue with another battery.
- try to replicate the issue with another OS (Ubuntu, Windows, etc.)
- try to recalibrate the battery using TLP.
Offline
It is a brand new laptop. I started using it in February, only 5 months ago. The problems only started the very day I ran a pacman -Syu, nearly a month ago. It would be a grand coincidence if it were to suddenly fail at the very same moment.
But now, even running a complete downgrade of my system does not make a difference. Is it possible for bad software to permanently damage the physical battery?
As far as uefi setting go, I must mention that it isn't consistent. I've seen it jump to zero at anywhere from 19% to 30%. So I can't imagine there is a specific number defined in some config file. It doesn't simply shut off randomly either, it seems to know that the battery is below 1% and will lose power in several seconds, hence giving me a warning. If it were completely blind, you would think that it would simply go black without any warning, right?
So the physical charge left in the battery can apparently be read at 0%, but fails utterly to read the correct amount of charge left at seemingly every other percentage.
>replicate with another battery
Don't have one at the moment. Also, it isn't like my older thinkpad with a detachable one, it's buried in there and I don't know how removable it is supposed to be.
>another OS
Probably a last resort. But if restoring all packages to a certain date, and it still doesn't work, do you think it would make a difference if I just re-installed arch from a live ISO USB? Maybe there are parts that don't get reset/rewritten when simply updating with pacman. It all worked with arch out of the box when I first installed.
>recalibrate with TLP
Just tried this. No luck when using it with current up to date packages, so I thought maybe it needs to be done with the known, proven setup. So I downgrading all packages to March 11th.
1. For some odd reason, TLP did not complain about acpi_call kernel modules missing when using the newest linux-hardened (5.19) and performed the operation normally.
2. When I tried with the older linux-hardened (5.15) it complained that acpi_call kernel modules were missing.
3. I installed acpi_call-dkms and linux-hardened-headers (from the March 11th date to match the rest)
4. I had to edit the boot entry with efibootmgr to remove lockdown parameters which I had set up, in order to make the modules loadable
5. Eventually get it to load
6. Run tlp calibrate
7. This time it makes it down to 21% before jumping to zero
8. AC power is allowed back on, to charge back up to 100%
This all goes fine, but it did absolutely nothing. After running unplugged it once again jumped to zero early (don't remember the exact percent this time, but it was greater than 21%). As far as I can tell tlp recalibrate just runs the battery down and recharges it, which is supposed to work apparently on machines that run normally.
Should this question be moved to laptop issues and renamed, to get more eyes on it? It's clear now that it probably has nothing to do with xfce.
Offline
This is happened to me, recently since late June, not sure on exact date.
cat /sys/class/power_supply/BAT0/capacityis different to
upower / xfce-power-managerIt seems to happen when the laptop wakes up, but intermittently, so can't exactly trace the issue.
I believe
plugging in the charger in
restarting
sleep and wake up again (sometimes)
"fixes" it
using `linux` kernel
I will try and give more information when it happens again
Last edited by dct93 (2022-07-05 21:57:58)
Offline
I did it! I figured out the real problem! Now I just need to find the solution.
It "charges" too fast!
OK, so I let it die completely and instead of plugging in the charger and rebooting, I simply plugged in the charger with the machine off. That way, there was no running kernel or any software to measure capacity. I then waited some time, and unplugged and restarted. When I logged in, it was at 89%.
I then used the computer normally, and this time I actually made it tall the way down to 10% and got the correct critical power warning from xfce4-power-manager.
All this indicates is that when the charger is plugged in, it increments capacity inaccurately fast. The end result is that charge reads too high after charging while the booted into arch. So if I went from (99-25) I was really going from (74-0).
What could cause this? Is it possible that there are multiple processes trying to estimate the charge, resulting in double-increments of percentage for each real percent gained?
Now that I have real grip on the problem, should I ask this in laptop issues forum instead?
Last edited by Mike_Hawk (2022-07-06 23:10:06)
Offline
Sounds like the kernel driver. But afaik nothing gets calculated to avoid exactly your situation. Try installing and running acpid and check again. If it still happens, do file a kernel bug. They'll know what to do if possible.
Offline
Ok, so after a couple days of use I believe the problem is solved. The issue has not returned.
The fact it was counting up too fast was that it simply forgot the actual physical capacity of the battery. It believed the total capacity was much smaller, so the percentage of course would increment higher since it believed it was closer to the maximum than it really was.
At least that is my theory. Running upower -d now returns 87.2941% for capacity instead of 87. Obviously, this is negligible but the fact that it actually changed leads me to believe that it finally did something, rather than just repeating the bad information.
TL;DR: For Thinkpad T14, if you encounter this problem the solution is to recharge from 0% with the machine turned OFF. For some reason, tlp recalibrate does not work.
Offline
TLP's FAQ actually has an entry for your issue.
Other than that:
- Boot up your system firmware (BIOS) and search for/play around with its battery settings if the issue comes back (there might be adaptive charging, charging thresholds, etc.).
- Keep an eye on future system firmware updates for your machine.
Last edited by JoeyCorleone (2022-07-11 07:45:40)
Offline
Pages: 1