Bug 1960997

Summary: upower battery indicator/service is delayed in reporting correct power and battery status
Product: [Fedora] Fedora Reporter: Nicholas Stommel <nicholas.stommel>
Component: upowerAssignee: Richard Hughes <rhughes>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 34CC: bberg, ckellner, hdegoede, rhughes
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2021-05-25 16:19:23 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Nicholas Stommel 2021-05-17 02:22:44 UTC
Description of problem:
The upower service and battery indicator is delayed in showing accurate results for about 3 to 5 minutes after changing power status from plugged in/charging to unplugged/discharging almost every time. This problem is highly annoying and I did not encounter it until installing Fedora 34 (default Gnome distro). When the charger is unplugged, the upower service still reports the system is charging for 3 to 5 minutes, despite acpi reporting correct results that it is on battery during this time. The same goes for when the charger is plugged in, the upower service still reports that the system is on battery for 3 to 5 minutes even when acpi reports it is charging. Eventually upower reports the correct status, but it takes too long in doing so. Forcing upower to refresh manually using 
"busctl call --system org.freedesktop.UPower /org/freedesktop/UPower/devices/battery_BAT0 org.freedesktop.UPower.Device Refresh" 
instantly fixes the problem, as does restarting the upower service using 
"sudo service upower restart". 
This phenomenon seems to come with an inaccuracy in the reported battery percentage: The battery percentage indicator is also slightly incorrect sometimes, reporting 95% to 99% charge until the upower service is restarted or a refresh is issued via busctl, even when acpi reports 100% charge.
Why is upower not being refreshed soon enough? Something interesting to note is that the sound effect for plugging in and unplugging the charger actually plays correctly most times despite the delay in upower My hardware is a Lenovo Yoga C940 15". I would be grateful if this somewhat bothersome problem (the system does not appear as responsive & trustworthy when it takes so long to report the correct status) could be addressed.

Version-Release number of selected component (if applicable):
upower client and daemon version 0.99.11

How reproducible:
Almost every time laptop charger is plugged in or unplugged from machine, this delay occurs. Inaccuracy in battery status occurs most times as for this reason.

Steps to Reproduce:
1. Unplug or Plug in laptop to power source
2. Observe that upower does not update the service or battery indicator to the correct status for 3 to 5 minutes

Actual results:
The charging indicator and upower service are delayed in reporting the correct power status by 3 to 5 minutes despite acpi reporting correct results. Battery percentage indicator is also slightly incorrect sometimes, reporting 95% to 99% charge until the upower service is restarted or a refresh is issued via busctl, even when acpi reports 100% charge.

Expected results:
The charging indicator and upower service should report almost immediately when power/battery status changes from unplugged/discharging to plugged in/charging and vice versa. The percentage charged indicator should also follow acpi and not stop updating when the battery is fully charged.

Additional info:
I don't believe this is a BIOS/hardware issue because acpi reports correct results every time the system is plugged in and unplugged, and manually refreshing upower via busctl or through the service works every time as well. This seems like a problem with the upower service.

Comment 1 Nicholas Stommel 2021-05-17 03:30:11 UTC
For now I am using this workaround: https://gitlab.freedesktop.org/upower/upower/-/issues/143#note_919997
Although I think it is a kind of hackish and poor alternative to increasing polling frequency or fixing whatever is causing this issue in the upower service/package.

Comment 2 Christian Kellner 2021-05-17 09:07:58 UTC
Can you maybe provide the udev events when you plug in (or vice versa) the machine (udevadm monitor)? IIRC, UPower uses those, maybe they are not reported correctly?

Comment 3 Nicholas Stommel 2021-05-19 00:23:30 UTC
Okay, I tried running udevadm monitor, and it appears the kernel is correctly detecting a change in the power supply. Here is the output for plugging in then unplugging the charger, which occurs exactly as the charger is unplugged andd plugged in:

$ udevadm monitor
monitor will print the received events for:
UDEV - the event which udev sends out after rule processing
KERNEL - the kernel uevent

KERNEL[157.929689] change   /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:18/PNP0C09:00/ACPI0003:00/power_supply/ADP1 (power_supply)
UDEV  [157.935390] change   /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:18/PNP0C09:00/ACPI0003:00/power_supply/ADP1 (power_supply)
KERNEL[158.002795] change   /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:18/PNP0C09:00/PNP0C0A:00/power_supply/BAT0 (power_supply)
UDEV  [158.004415] change   /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:18/PNP0C09:00/PNP0C0A:00/power_supply/BAT0 (power_supply)
KERNEL[165.220090] change   /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:18/PNP0C09:00/PNP0C0A:00/power_supply/BAT0 (power_supply)
UDEV  [165.225886] change   /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:18/PNP0C09:00/PNP0C0A:00/power_supply/BAT0 (power_supply)
KERNEL[165.274580] change   /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:18/PNP0C09:00/ACPI0003:00/power_supply/ADP1 (power_supply)
UDEV  [165.278246] change   /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:18/PNP0C09:00/ACPI0003:00/power_supply/ADP1 (power_supply)

I again stress this is likely a problem with upower itself, as the charging/battery indicator does not update to reflect the correct power state until about 3 minutes pass despite acpi and the kernel reporting power events and status correctly.

Comment 4 Hans de Goede 2021-05-25 16:19:23 UTC
As also mentioned here:
https://ask.fedoraproject.org/t/battery-indicator-not-reporting-correct-power-status-until-delay-on-lenovo-laptop/

Your Yoga C940 is a standard Intel x86 laptop, so it is using the ACPI battery driver to provide this information. Normally the firmware will send an ACPI notify to the kernel’s battery driver on unplug/replug of the charger and this gets forwarded to upower which then immediately updates.

It seems that for some reason on the C940 these ACPI notify calls are not happening and this is something which is outside of Linux’ control, so there really is not much what we can do here.

Increasing the default polling rate in Fedora is not a good idea because the polling itself uses battery so we don’t want to do it too often; and normally we get the notifications on unplug/replug so the polling is only necessary to keep an eye on the battery percentage.

There might be some subtle Linux-kernel ACPI code bug lurking somewhere which causes the notifications to not happen, but this definitely is not a upower bug, so lets close this bug.