Package: upower
Version: 1.90.9-1
Severity: normal
Tags: upstream
X-Debbugs-Cc: [email protected]
Dear Maintainer,
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation?
* What exactly did you do (or not do) that was effective (or
ineffective)?
* What was the outcome of this action?
* What outcome did you expect instead?
*** End of the template - remove these template lines ***
-- System Information:
Debian Release: 13.0
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.12.107+deb13-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=da_DK.UTF-8, LC_CTYPE=da_DK.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages upower depends on:
ii dbus [default-dbus-system-bus] 1.16.2-2
ii libc6 2.41-12+deb13u4
ii libglib2.0-0t64 2.84.4-3~deb13u5
ii libgudev-1.0-0 238-6
ii libimobiledevice-1.0-6 1.3.0+git20250228-2
ii libplist-2.0-4 2.6.0-2+b1
ii libpolkit-gobject-1-0 126-2
ii libupower-glib3 1.90.9-1
ii udev 257.13-1~deb13u1
Versions of packages upower recommends:
ii polkitd 126-2
upower suggests no packages.
-- no debconf information
Adding my own debug performed using ChatGPT
Package: upower
Version: 1.90.9-1
Severity: normal
Subject: UPower sometimes initializes incorrect EnergyFull on MacBook Pro ACPI
SBS battery
### Summary
On a MacBook Pro 2017 using the ACPI SBS battery driver, UPower 1.90.9-1 can
initialize an absurdly large `EnergyFull` value after boot. This results in a
completely incorrect battery percentage being reported by UPower.
Restarting the UPower daemon immediately fixes the values without any change to
the kernel battery data. After the restart, the values remain stable.
### System
* Distribution: LMDE 7 (gigi), based on Debian Trixie 13
* Architecture: amd64
* Kernel: 6.12.107+deb13-amd64
* UPower: 1.90.9-1
* Hardware: MacBook Pro 2017
* Battery driver: ACPI SBS (`/sys/bus/acpi/drivers/sbs`)
* Battery manufacturer: TOP
* Battery model: A1405
* Battery type: Li-ion
* Replacement battery: approximately 12 months old
### Kernel battery data
With the AC adapter connected, the kernel reports:
```
POWER_SUPPLY_STATUS=Full
POWER_SUPPLY_PRESENT=1
POWER_SUPPLY_TECHNOLOGY=Li-ion
POWER_SUPPLY_CYCLE_COUNT=617
POWER_SUPPLY_VOLTAGE_MIN_DESIGN=7600000
POWER_SUPPLY_VOLTAGE_NOW=8477000
POWER_SUPPLY_CURRENT_NOW=0
POWER_SUPPLY_CURRENT_AVG=0
POWER_SUPPLY_CAPACITY=94
POWER_SUPPLY_CHARGE_FULL_DESIGN=8000000
POWER_SUPPLY_CHARGE_FULL=7567000
POWER_SUPPLY_CHARGE_NOW=7542000
POWER_SUPPLY_MODEL_NAME=A1405
POWER_SUPPLY_MANUFACTURER=TOP
```
There are no `energy_*` attributes in `/sys/class/power_supply/BAT0`; the
battery interface exposes charge and voltage values.
### Incorrect UPower state
Before restarting the UPower daemon, `upower -i` reported:
```
state: fully-charged
energy: 57.3192 Wh
energy-full: 491.918 Wh
energy-full-design: 60.8 Wh
energy-rate: 0 W
voltage: 8.477 V
charge-cycles: 617
percentage: 11.6522%
temperature: approximately 27 C
capacity: 100%
```
The `energy-full` value of 491.918 Wh is clearly inconsistent with the kernel
data and the other UPower properties.
In particular, the kernel reports:
```
charge_full = 7567000 uAh
charge_full_design = 8000000 uAh
charge_now = 7542000 uAh
voltage_now = approximately 8.477 V
```
The reported UPower percentage of 11.6522% is also directly explained by the
incorrect `EnergyFull` value:
```
57.3192 / 491.9176 * 100 = 11.6522%
```
The battery was in fact reported by the kernel as `Full`, with 7.542 Ah out of
a 7.567 Ah full-charge capacity.
### Reproducing the problem
The important observation is that restarting UPower fixes the problem without
changing the battery or kernel state.
I ran:
```
sudo systemctl restart upower
sleep 2
upower -i $(upower -e | grep BAT)
```
Immediately afterwards UPower reported:
```
state: fully-charged
energy: 57.3192 Wh
energy-full: 57.5092 Wh
energy-full-design: 60.8 Wh
energy-rate: 0 W
voltage: 8.479 V
charge-cycles: 617
percentage: 99.6696%
temperature: 29.5 C
capacity: 94.5875%
```
The kernel battery values remained unchanged.
The corrected percentage is consistent with the kernel charge values:
```
7542000 / 7567000 * 100 = 99.6696%
```
The corrected battery capacity is also exactly consistent with the kernel
values:
```
7567000 / 8000000 * 100 = 94.5875%
```
I subsequently ran `upower -i` three more times over approximately 30 seconds.
All three readings remained identical, with:
```
energy-full: 57.5092 Wh
percentage: 99.6696%
capacity: 94.5875%
```
### Expected behaviour
UPower should initialize its battery properties consistently from the kernel
battery data.
In this case the kernel data are internally consistent, but UPower initially
constructs an impossible `EnergyFull` value of approximately 492 Wh and
consequently reports the battery as only 11.65% charged.
Restarting the daemon causes UPower to calculate the values correctly from
exactly the same kernel data.
### Assessment
This appears to be an initialization/state problem in UPower rather than a
problem with the battery or the kernel battery interface.
The fact that:
1. the kernel data remain unchanged,
2. UPower initially reports `EnergyFull = 491.918 Wh`,
3. restarting only the UPower daemon changes this to `57.5092 Wh`,
4. the battery percentage simultaneously changes from 11.6522% to the
mathematically correct 99.6696%, and
5. subsequent UPower readings remain stable,
makes the issue reproducible as a daemon-startup problem.
The hardware is a MacBook Pro using the ACPI SBS battery driver, so this may be
specific to the SBS/charge-based battery handling or to the initialization of
the charge/energy conversion.
I also noticed that current upstream UPower development contains work
concerning explicit definition of battery energy/charge units
(`wip/kate/issue253`), which may be relevant, although I have not established
that it is the same issue.
### Additional information
The battery is an aftermarket replacement and reports a cycle count of 617.
However, the kernel-reported charge values are internally consistent and the
incorrect UPower state is reproducibly corrected by restarting UPower.
No UPower package replacement, downgrade, patch, or kernel change was performed
during the test.
The problem therefore seems suitable for investigation in UPower's battery
initialization code, particularly the path used when an SBS battery exposes
charge values but no `energy_*` sysfs attributes.
