[RESPONDED] Battery percentage gets misreported as 0% occasionally

Framework Laptop 13 Linux
1

I’m on the 12th gen i5-1240P, running Arch Linux (kernel 6.5.6, older ones reproduce this issue too), and sometimes see the battery charge get misreported as 0%. This causes the system to immediately power down, which is extremely inconvenient. Has anyone seen similar behavior?

screenshot-2023-10-15-23:31:26

(the popup is lying, the battery is charging just fine)

dmesg output doesn’t show anything unusual, but a few instances of this EC error are present (I think those are normal though?):

[267610.915734] cros_ec_lpcs cros_ec_lpcs.0: packet too long (4 bytes, expected 0)
3

Based on the error itself, my first question is what power charger are you using and if it’s FW official, have you tried other outlets? If it’s not one of our chargers, what is the exact model and power provided?

Additionally, what is the output of:

cat /sys/class/power_supply/ACAD/online
(Should be 1)

and now let’s compare with, provide all output here as well:

upower -i /org/freedesktop/UPower/devices/battery_BAT1

4

I was seeing sort of similar behavior, also Arch 6.5.? x64 kernel Ave Plasma desktop, but on 11th Gen i5. Except my case it wouldn’t pop up 0%, it was a random number around 9%, so it didn’t force a shutdown. By the time I could try to troubleshoot, the battery reading was back to my charge target number. Haven’t seen it do it since my last kernel update a few days ago, but I’ll keep an eye out. I suspect a KDE/Plasma bug…

Using third party USB-PD 2.0 100W chargers and e-marked 5A cables, if it matters.

5

The error is wrong, the charger is working fine with the laptop. This has also happened to me before while on battery, around the time it discharged just below 70%, shutting down the machine. After turning it back on the battery charge was reported correctly again.

I will keep upower --monitor-detail running in the background in case it happens again. I hope that at least lets me find out what’s shutting down the machine when the battery reports 0% and how to stop it from doing that (KDE is configured to ignore low battery levels, so it must be something else doing it).

I’m not familiar with how exactly battery state is reported to the system, does it go through the EC? If so, could interference by the BIOS cause this, similar to how it causes the Fn key to stop working occasionally?

6

This would be my assumption, however, if the adapter is working with one laptop and not another (FW), it gives us a place to start from.

Provide the output requested. That is what I can help with. Again, we don’t actually know what the issue is.

7

I’ve disabled and masked upower.service, which apparently is incapable of not shutting down the system when the battery reports 0%. Hopefully this will at least let me read the journal for anything suspicious and also run the commands you posted if this happens again.

8

+1 for me too! I also see the popup occasionally on my 12th gen i5-1240P. I am running kubuntu, and it would occasionally pop saying battery was at 5%, 9%, and so on. I never got around to finding out where it’s wrong though.

As for my device, I’ve seen it happen on different chargers in different places:

  • 100w charger
  • 65w lenovo USB C charger
9

I just hit this again (also while plugged in), but I think it fixed itself because the charge state in sysfs looks reasonable

~> cat /sys/class/power_supply/BAT1/status
Discharging
~> cat /sys/class/power_supply/BAT1/charge_now
3286000
~> cat /sys/class/power_supply/BAT1/charge_full
3286000
~> cat /sys/class/power_supply/ACAD/online
1

The UPower command’s output also looks fine, however I could only start UPower after the problem happened, so it probably didn’t catch it.

~> upower -i /org/freedesktop/UPower/devices/battery_BAT1
  native-path:          BAT1
  vendor:               NVT
  model:                Framewo
  serial:               0251
  power supply:         yes
  updated:              Tue Oct 17 07:21:10 2023 (0 seconds ago)
  has history:          yes
  has statistics:       yes
  battery
    present:             yes
    rechargeable:        yes
    state:               discharging
    warning-level:       none
    energy:              50.6044 Wh
    energy-empty:        0 Wh
    energy-full:         50.6044 Wh
    energy-full-design:  55.0088 Wh
    energy-rate:         1.2936 W
    voltage:             17.385 V
    charge-cycles:       163
    time to empty:       39.1 hours
    percentage:          100%
    capacity:            91.9933%
    technology:          lithium-ion
    icon-name:          'battery-full-symbolic'
  History (charge):
    1697520070  100.000 discharging
    1697520070  0.000   unknown
  History (rate):
    1697520070  1.294   discharging
    1697520070  0.000   unknown

Here’s how KDE surfaces the issue when it happens:
screenshot-2023-10-17-07:19:03

10

You may want to edit your module block list and add cros_ec_lpcs or cros_ec_debugfs.

1 Like
11

If you feel it has been resolved, do let us know. If not, it’s worth trying DHowett’s suggestion next.

12

@Matt_Hartley This seems to be an issue in your firmware, so I do hope you are tracking it internally. Disabling the kernel modules can only work around the issue by reducing communication with the EC (so that the race condition is less likely to happen). I will give that a try though.

13

Please file a ticket, we’ll see if we can replicate. Thus far, no luck on my end.

14

@jschievink Regarding your inability to prevent the shutdown in an orderly fashion, read this for some background:

Be advised: it’s a depressing reading. In short: authoritarian tendencies of some free software developers at full display.

FYI, I’ve had a similar issue on a previous laptop (where the battery was at fault) and I believe I was able to prevent the shutdown by setting PercentageAction to 0 in /etc/UPower/UPower.conf.

15

I’ve been seeing this on a fresh Ubuntu 23.04 installation (with latest updates). (On FL13 11th gen with latest BIOS)

Usually start seeing these within 30 minutes of having executed the following, in this order, while plugged in (in my case):

  1. Ctrl-Alt F2 to get to tty
  2. Login
  3. sudo init 3 (just to minimize the number of processes)
  4. sudo ectool fanduty 100
  5. geekbench6

Then the “packet too long” will start showing up within 30 minutes of that.

If from a fresh reboot, and I only do steps 1, 2 and 3…then it would happily sit at the terminal quietly.

Additional note:
ectool was compiled from GitHub - DHowett/framework-ec: Embedded Controller firmware for the Framework Laptop with instructions from the Instructions section here.

16

I’m seeing this issue as well.

Framework 12th gen i5-1240P, 3.04 firmware, Ubuntu/Kubuntu 23.10 and now 24.04.

While whatever is happening in the kernel happens regardless of DE, the alerts only pops up under KDE, not Gnome. What is interesting to me is that when warning appears, KDE seems to think that the battery state of charge is less than 10% (it will report varying numbers) and then within a second it will report the correct state of charge.

I do see the cros_ec_lpcs packet too long errors from dmesg.

My laptop generally stays plugged in, so I have enabled the charge limit at 75%. I have been charging the laptop through a USB-C hub so that I can have one connection to the laptop. Based on this thread I’m trying providing power on a different port that is directly connected to the power supply and not going through the USB-C hub. I use an Anker GaN power supply. I have already tried plugging the hub into different ports on the laptop. My next experiment if the dedicated power line doesn’t resolve it will be to use the OEM Framework charger, and I will also try switching the USB-C cable (one experiment at a time).

17

Update 1

After a few hours I got the battery is critical warning under KDE again, so I have switched to the Framework OEM charger.