It sounds like an issue which should be reported upstream. Please let us know what you find out.

Yeah. Thanks for pushing me up the chain, dude.

I was able to stop the flow of these messages with a simple patch for upower, and one for powerdevil. The biggest issue is that I'm not sure which one of these is the issue, or if the problem is initiated further down - like at the kernel level. When I think back to when I think it started, it matches the new kernel release (6.1.1) better than the last updates to upower or powerdevil. So I have no idea where to file a bug report upstream - upower, powerdevil, kernel?

In any case, I created this patch for upower (can;t seem to find tags for code, sorry):

--- a/src/linux/up-device-supply-battery.c 2022-12-26 15:54:48.887273250 -0500
+++ b/src/linux/up-device-supply-battery.c 2022-12-26 16:01:27.774169696 -0500
@@ -99,7 +99,7 @@
* device */
if (!self->shown_invalid_voltage_warning) {
self->shown_invalid_voltage_warning = TRUE;
- g_warning ("no valid voltage value found for device %s, assuming 10V",
+ g_debug ("no valid voltage value found for device %s, assuming 10V",
g_udev_device_get_sysfs_path (native));
}
/* completely guess, to avoid getting zero values */

it's pretty simple - just swaps out g_warning for g_debug. The PKGBUILD was modified to accommodate the patch (remember to add the patch file to source and sums):

prepare() {
cd upower
patch -p1 -i ${srcdir}/up-device-supply-battery.patch
}

For powerdevil, the patch I created actually fixes an example of sloppy programming - something all developers do, so no judgement. The developer probably assumed that the chances of a null pointer in that particular piece of code was unlikely. But:

--- a/daemon/powerdevilcore.cpp 2022-11-29 06:50:58.000000000 -0500
+++ b/daemon/powerdevilcore.cpp 2022-12-28 18:29:45.859554595 -0500
@@ -525,8 +525,11 @@
Device device(udi);
Battery *b = qobject_cast<Battery *>(device.asDeviceInterface(DeviceInterface::Battery));

- disconnect(b, &Battery::chargePercentChanged, this, &Core::onBatteryChargePercentChanged);
- disconnect(b, &Battery::chargeStateChanged, this, &Core::onBatteryChargeStateChanged);
+ if (b != nullptr)
+ {
+ disconnect(b, &Battery::chargePercentChanged, this, &Core::onBatteryChargePercentChanged);
+ disconnect(b, &Battery::chargeStateChanged, this, &Core::onBatteryChargeStateChanged);
+ }

qCDebug(POWERDEVIL) << "Battery with UDI" << udi << "has been removed";


and again, the PKGBUILD was modified to accommodate the patch (remember to add the patch file to source and sums):

prepare() {
cd powerdevil-${pkgver}
patch -p1 -i ${srcdir}/null-device-fix.patch
}

The disappearance of the log messages with these patches is fine, but the underlying issue, or issues, still exist. It could be that device names changed (udev?), or something similar to that - maybe new device(s) added? Nothing matching the upower output above is defined via acpi.

If anyone can suggest where I should push this to, upstream, then please, suggest away.

> When I think back to when I think it started, it matches the new kernel release (6.1.1)

This should be quite easy to determine...just install an earlier kernel, either 6.0.x or -lts and see if you can still repro.

It appears that the issue lay with the kernel. linux-6.1.2 resolves the issue, amongst many others apparently - the changelog is huge.