On a device/in a situation which reproduces this, can you please run
udevadm monitor -e
I expect that there is a high frequency of uevents related to the battery from the kernel's battery driver. These get relayed through udev and upower to U-S-S. In particular we need to see if there are any properties which actually change, i. e. whether the battery goes crazy or the bat driver has a bug to fire a ginormous amount of uevents (which keeps significant parts of the system busy). It's of course possible that there are no uevents but upower manages to get stuck in some kind of loop. But that's less probable as it never happened on other systems.
The recent "dmesg" output would also be interesting, in case that the driver reports some error there.
On a device/in a situation which reproduces this, can you please run
udevadm monitor -e
I expect that there is a high frequency of uevents related to the battery from the kernel's battery driver. These get relayed through udev and upower to U-S-S. In particular we need to see if there are any properties which actually change, i. e. whether the battery goes crazy or the bat driver has a bug to fire a ginormous amount of uevents (which keeps significant parts of the system busy). It's of course possible that there are no uevents but upower manages to get stuck in some kind of loop. But that's less probable as it never happened on other systems.
The recent "dmesg" output would also be interesting, in case that the driver reports some error there.
Thanks!