Public bug reported:
Hardware / software
- Lenovo LOQ 15IRX10, product 83JE, board LNVNB161216
- BIOS R3CN39WW (07/24/2025), EC firmware 1.39
- CPU: 13th Gen Intel Core i5-13450HX
- Kernel: 7.0.0-38-generic (Ubuntu 7.0.0-38.38~24.04.4-generic 7.0.14),
also observed on 7.0.0-34-generic
- Distro: Linux Mint 22.3 (Ubuntu 24.04 "Noble" base), upower 1.90.3
- Battery: BYD L24B4PK4, charge_types: "Fast Standard [Long_Life]",
ideapad conservation_mode = 1
Symptom
The kernel emits a continuous storm of KOBJ_CHANGE uevents for
/sys/class/power_supply/BAT1:
udevadm monitor --kernel, 10 s on battery: 7099 BAT1 events
udevadm monitor --kernel, 10 s on AC: 15279 BAT1 events
upowerd processes every event, leaks memory, reaches ~11 GB RSS and is
OOM-killed (seen in 4 of the last 7 boots since 2026-10-01; upower.service
"Consumed 1h 18min CPU time" in a 5.5 h session). systemd-udevd also burns CPU.
What I ruled out (each measured as BAT1 events in 5 s)
- normal: 8023
- with upower.service stopped: 7983 -> not driven by
userspace reading
- charge_types switched Long_Life -> Standard: 8012 -> not mode-specific
- /sys/firmware/acpi/interrupts/sci and all GPE counters do NOT increase
during the storm -> not hardware/EC
interrupts
- with ideapad_laptop unloaded (modprobe -r): 0 <- storm stops
completely
- after modprobe ideapad_laptop again: storm returns
ftrace on power_supply_changed (func_stack_trace), every hit looks like:
kworker/5:0-14193 [005] ..... 20458.958776: power_supply_changed
<-acpi_battery_notify
=> power_supply_changed
=> acpi_battery_notify
=> acpi_ev_notify_dispatch
=> acpi_os_execute_deferred
=> process_one_work
=> worker_thread
=> kthread
=> ret_from_fork
=> ret_from_fork_asm
(consecutive hits ~0.6 ms apart)
So the notifications are AML Notify(BAT1, ...) executed by firmware code,
not caused by SCI/GPE. Since they stop only when ideapad_laptop is unloaded,
some ACPI method evaluated by ideapad_laptop appears to execute
Notify(BAT1). dmesg shows the driver registers
"ACPI: battery: new hook: Ideapad Battery Extension".
Suspected mechanism (hypothesis, not verified):
power_supply_changed() -> uevent -> power_supply_uevent() reads all
properties including the ideapad extension property charge_types ->
ideapad evaluates a VPC/GBMD-style method on the EC -> the firmware method
does Notify(BAT1, 0x80) -> acpi_battery_notify() -> power_supply_changed()
-> ... i.e. a self-sustaining loop inside the kernel. This would explain why
the storm continues without any userspace reader and without interrupts.
Workaround in use
systemctl set-property upower.service MemoryMax=300M
(prevents the OOM situation, but the loop keeps wasting CPU).
Happy to test patches or provide acpidump / more traces.
** Affects: linux (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2169715
Title:
ideapad-laptop battery extension causes endless BAT1 "change" uevent
storm (~800-1500/s) on Lenovo LOQ 15IRX10 (83JE); upowerd grows to >10
GB and gets OOM-killed
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2169715/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
