[L14 Battery] Constant discharge + Charge in Qubes

[fbk]

I did try disconnecting the battery. It reset all the clocks… which in turn meant I needed to reset the Librem Key as well. I thought the clocks would run on some CR2032

[NineX]

Librem 14: Adding Librem EC, Freed Embedded Controller Firmware – Purism

battery is being controlled by EC
and there was somewhere information how to set charge thresholds. like:
allow battery discharge to 40% then load it to 80% …
it’s matter of setting correct EC profile.

here you have inf0o how to control battery:

Librem 14 Rave – Purism

[NineX]

Controlling the Battery

In our last blog post we also talked about the battery charge controller and that we can set some threshold from user space. Here you go:

/sys/class/power_supply/BAT0/charge_control_start_threshold /sys/class/power_supply/BAT0/charge_control_end_threshold

If the battery percentage falls below the start threshold and then a new charge is started, charging will stop when the battery reaches the end threshold percentage. On my Librem 14 I currently use a script and set this to:

#set default battery thresholds

echo 40 > /sys/class/power_supply/BAT0/charge_control_start_threshold
echo 95 > /sys/class/power_supply/BAT0/charge_control_end_threshold

The system fans can not be controlled from user space yet, right now, but they can at least be monitored a bit:

/sys/class/hwmon/hwmon4

We will work further on it.

The ACPI driver is on its way into PureOS as a DKMS package and we will do our best to get this into upstream Linux kernel so the DKMS will not be necessary mid-term.

[fbk]

I have combed through /sys/class/power_supply myself and under Qubes (at least on my device) these do not appear. I have already wiped the default installation of PureOS on my drive so I can’t verify if those exist or not. The problem is less about determining when the battery starts charging but the behavior that the battery is being used while being plugged into the wall.

And it appears that we have no way to update the EC firmware in any way yet so a fix is probably for the future

New Post: Wrangling the EC: Adventures in Power Sequencing

The new firmware should get applied to Librem 14s that are shipped out starting next week. As far as the ones that are already shipped out, they were stable with the existing firmware (otherwise they would have been held back). But if someone wants the newer firmware anyway, they’d need to download and run our firmware update tool. I spoke too soon, we are still working on a mechanism for end users to update the EC firmware like we do with our boot firmware.

I’ve been monitoring /sys/class/power_supply/BAT0/current_now and mysteriously after a couple reboots and updates it appears to be stable at 0 and my battery is constant at 96%.

This leads me to the conjecture that the charger cannot provide enough wattage to the computer if under significant load and therefore needs to pull current from the battery as well.

Librem 14 fan noise?

So well, yes, CPU load will in any case produce heat, this can not be avoided, that’s the nature of all CPUs and the Intel Core i7 10710U is not different in this regard. If you can sacrifice some performance vs. energy consumption you can do several tricks to keep it low profile. One would be to change the CPU frequency governor from ‘ondemand’ (default) to ‘conservative’. This will cause the CPU to run on lower frequencies longer which will reduce power consumption and thus heat. If this is …

In the above post Nicole talks about limiting the CPU wattage by using
echo 15000000 > /sys/devices/virtual/powercap/intel-rapl/intel-rapl:0/constraint_0_power_limit_uw
echo 20000000 > /sys/devices/virtual/powercap/intel-rapl/intel-rapl:0/constraint_1_power_limit_uw

But powercap does not show up under virtual so I haven’t been able to try that solution.

Edit: Executing “find /sys/ | grep constraint” also returns no results.

[MrChromebox]

@fbk

I have combed through /sys/class/power_supply myself and under Qubes (at least on my device) these do not appear.

they all require the librem-ec DKMS driver, as described in that blog post

[fbk]

So I guess there isn’t much I can do

[MrChromebox]

the default battery charge threshold to start charging is 90%, so the only way I can see what you are describing happening is if it’s below 90%, starts charging, then stops at 100% and discharges until it’s back below 90% again. Is that what you’re seeing?

[W8VUpzsTHzB4bt]

My L14 did not charge at all with preinstalled PureOS. After installing librem-ec-acpi-dkms it still was not charging because /sys/class/power_supply/BAT0/charge_control_start_threshold was 0 by default. After changing it to 75 it started to charge.

[MrChromebox]

that means your L14 shipped with EC firmware that has a bug in the charge thresholds setting, we have an update EC firmware (just no mechanism to apply it yet), but setting via the DKMS driver achieves the same result

[fbk]

The behavior is as follows.

At rest/low load, the battery level stays constant and I do not observe “discharge -> charge -> discharge -> charge” behavior. Under load (eg. during initial setup/updates) the battery begins discharging and then begins charging again.

Due to the intermittent loads this gives the laptop enough time to recover and recharge the battery back to 100% and hence we observe this cycle.

This leads me to believe the charger is unable to provide enough power to the L14 and thus needs to pull extra current from the battery under load. As such my issue is less about setting charging thresholds but rather what I observe to be an inadequate charger (power wise).

[MrChromebox]

@fbk

This leads me to believe the charger is unable to provide enough power to the L14

there’s no way the L14 should be pulling more than 65W - the CPU turbo max is 20W, and even counting the rest of the system (display, etc) and fully populated USB ports, should still be well under 65W.

Will see if I can reproduce here compiling / forcing a heavy load

[fbk]

Thanks! The only reason why I say this is because when the battery reports “fully charged” and I’m just idling/browsing the web…

cat /sys/class/power_supply/BAT0/current_now

reports 0

[MrChromebox]

that makes sense, since the current supplied by the battery (assuming that’s the discharge current) would be zero since on AC power

[fbk]

Yes, but during heavy loads and ramping up it is not 0 sooooooooooooooooooooooooooooooooooooooooooooooooo its discharging even though plugged in.

[MrChromebox]

then that’s something I need to investigate

[fbk]

Thanks! Just as a point of reference, I’ve reinstalled Qubes maybe 2-3 times on the L14 now and every time during the initial update/after you first login this behavior is most prevalent (eg. sudo qubes-dom0-updaste, upgrading fedora-32 to fedora-33 templatevm, or just normal updates).

[wanderingshort]

I’m also seeing odd battery behavior while running Qubes. Even with the charger plugged in, the battery level does not increase despite xfce4-power-manager stating that the battery is charging.

Yesterday I had the laptop on, the battery level was at 74%, and with the charger plugged in for hours it remained at 74%. I turned the laptop off and kept the charger plugged in for over 8 hours overnight. When I turned the laptop back on this morning, the battery level is still reading at 74%. I unplugged the charger for a while and now the battery is at 65%, and plugging the charger back in is keeping the battery at 65% but it is not increasing.

[MrChromebox]

@wanderingshort if your device won’t charge with a PureOS (10) live USB booted, then contact support about an EC firmware update to address the issue

[fbk]

@MrChromebox have you been able to replicate my described situation? For the record I have had no issues with PureOS.

[MrChromebox]

@fbk no I haven’t had a chance to do any testing under Qubes recently. But working on an EC update that may address the underlying issue.