[SOLVED] udev causes some apps to freeze when battery alarm trips

Mahbod Karamoozian · 2025-11-06 15:19:22

i own an HP victus 15 fb2082wm and have tested this on a fresh install of vanilla arch too (the only difference being waybar periodically freezing instead of fully locking up), filesystem is BTRFS if that is of importance. if the battery precentage reaches 8% polling the status will take 200ms and processes which poll the battery like waybar may freeze or for osu! drop input periodically, weirdly this will not happen on kubuntu 25.10 (live booted). my only clue as to this is some configuration with the kernel in kubuntu and arch being done differently. not loading the nvidia driver will not make a difference so that is out of the picture.

thanks in advance

Last edited by Mahbod Karamoozian (2025-11-07 20:05:54)

seth · 2025-11-06 15:43:51

not loading the nvidia driver will not make a difference so that is out of the picture

Some daemon (supergfxd etc) might shut down the device when the battery drops below a threshold, regardless of any driver.

Please post your complete system journal for a boot covering the condition:

sudo journalctl -b | curl -F 'file=@-' 0x0.st

We can't comment on the situation based on "my system does an oopsie"

Mahbod Karamoozian · 2025-11-06 15:58:53

seth wrote:

Please post your complete system journal for a boot covering the condition

https://0x0.st/K9Zk.txt
here is a journal of a normal system boot on high battery

seth · 2025-11-06 16:22:42

nvidia-powerd ?
But we'll have to see a journal covering a bad boot.

Mahbod Karamoozian · 2025-11-06 16:59:41

http://0x0.st/K9N_.txt
here is one with the laptop booting at 7% battery
i have disabled nvidia powerd
if i disable the waybar battery module it will not freeze

Last edited by Mahbod Karamoozian (2025-11-06 17:00:35)

Mahbod Karamoozian · 2025-11-06 17:21:45

i come with new information:
the freeze duration on waybar and other apps is dependent on how much modules are loaded weirdly AND if upower is present, maybe this really is a kernel configuration thing

seth · 2025-11-06 19:28:07

i have disabled nvidia powerd

Nov 06 20:28:38 wackybox systemd[1]: Started nvidia-powerd service.
Nov 06 20:28:38 wackybox nvidia-powerd[782]: nvidia-powerd version:2.0 (build 1)
Nov 06 20:28:39 wackybox nvidia-powerd[782]: DBus Connection is established
Nov 06 20:28:39 wackybox nvidia-powerd[782]: ERROR! Error in processParam call : -1 16   13
Nov 06 20:28:39 wackybox nvidia-powerd[782]: ERROR! Error in processParam call : -1 16   13
Nov 06 20:28:39 wackybox nvidia-powerd[782]: ERROR! Error in processParam call : -1 16   13
Nov 06 20:28:39 wackybox nvidia-powerd[782]: CRITICAL! k10temp not found
Nov 06 20:28:39 wackybox nvidia-powerd[782]: ERROR! JPAC is not created/already destroyed, ignoring request.
Nov 06 20:28:39 wackybox nvidia-powerd[782]: ERROR! JPAC is not created/already destroyed, ignoring request.
Nov 06 20:28:50 wackybox nvidia-powerd[782]: ERROR! JPAC is not created/already destroyed, ignoring request.
Nov 06 20:28:50 wackybox nvidia-powerd[782]: ERROR! JPAC is not created/already destroyed, ignoring request.

if the battery precentage reaches 8% polling the status will take 200ms and processes which poll the battery like waybar may freeze or for osu! drop input periodically

There're no timeouts indicated in the journal - it is *only* waybar that's affected?
Can you still "acpi -i" ?

Mahbod Karamoozian · 2025-11-06 20:04:31

i can do acpi -i, it just is more delayed than usual and only apps that poll battery are affected, waybar could very well be unaffected if its battery module was disabled, about nvidia powerd, it makes no real difference in this bug, i have a subvolume dedicated to testing things on a fresh install for a sanity check and it happens there too and that subvolume does not have any nvidia driver installed

seth · 2025-11-06 20:31:21

Your battery polls slow - does this not happen (check acpi, not some panel!) on ubuntu?

Mahbod Karamoozian · 2025-11-06 21:04:49

on kubuntu 25.10 (livebooted) the apps are unaffected by the freeze and atop all that upower is running which was the thing that amplifies the delay on arch, the polling times on arch are a bit more but kubuntu can be delayed at times too, not as much as arch in some cases however, that one can hit 400ms if waybar is running. but it doesn't really matter because even if it's just 100ms on both the freeze only happens on arch

seth · 2025-11-06 21:12:03

on kubuntu 25.10 (livebooted) the apps are

seth wrote:

check acpi, not some panel!

You (or rather the waybar pluin) can easily avoid that by not polling the battery synchronously in the GUI thread, so the only question is whether the battery (and thus "acpi -i") responds slow on ubuntu when you're close to empty.

Mahbod Karamoozian · 2025-11-06 21:13:33

it responds latently like it does on arch

seth · 2025-11-06 21:24:23

So the problems are
1. the battery responds slow on low power (likely some firmware or even battery driven powersaving)
2. the waybar battery module polls the battery synchronously

You'll likely not be able to so something about the battery behavior, => https://github.com/Alexays/Waybar/issues

Mahbod Karamoozian · 2025-11-06 21:27:15

the real point of delay following analysis of sysfs is the status part (the one that says discharging) with 200ms+ real time vs no user and sys time, i wanted to bring this to attention because this only affects arch to freeze the apps, aside from waybar there is osu! which only drops input in arch but not in kubuntu with the exact same appimage

Last edited by Mahbod Karamoozian (2025-11-06 21:27:36)

Mahbod Karamoozian · 2025-11-06 22:01:08

i am the bearer of big news, I HAVE PINPOINTED IT!!!!
i used the debug kernel parameter to look for things in journalctl and found it, when the battery is low systemd udevd will spam the logs with

systemd-udevd: BAT0: Device is queued (SEQNUM=XXXX, ACTION=change)
systemd-udevd: BAT0: Device is ready for processing (SEQNUM=XXXX, ACTION=change)
systemd-udevd: BAT0: Worker [YYYY] is forked for processing SEQNUM=XXXX
(udev-worker): BAT0: Processing device (SEQNUM=XXXX, ACTION=change)
(udev-worker): BAT0: Device processed (SEQNUM=XXXX, ACTION=change)
(udev-worker): BAT0: sd-device-monitor(worker): Passed ZZZ bytes to netlink monitor

the same happens when the battery is charging but due to the fact that the battery will take 0.002ms to poll this isn't much of an issue, when discharging with high battery this spam is nowhere to be seen so something tells me it isn't necessary for it to exist on low battery at least

when i focefully killed systemd-udevd there are no more freezes
now that we have pinpointed where this bug with inconsistency among distros comes from the road is much easier

Last edited by Mahbod Karamoozian (2025-11-06 22:03:50)

Mahbod Karamoozian · 2025-11-06 22:24:34

upon even further investigation this spam happens when the battery alarm is tripped, this is useful for waking up a laptop when it's low battery to put itin hibernate mode, echoing 0 to this variable causes the spam to stop and the device to not wake up when sleeping with low battery, this variable also resets upon resume
now for the fun part: this spam caused by battery alarm also exists on kubuntu but that one somehow circumvents the freeze, what this all points me to is the udev implementation in arch linux that is causing this freeze

seth · 2025-11-06 22:36:41

For reference: https://wiki.archlinux.org/title/Laptop#udev

now for the fun part: this spam caused by battery alarm also exists on kubuntu but that one somehow circumvents the freeze

By running a completely different userspace stack (waybar means you're likely not running KDE?)?

osu! which only drops input

The battery might provide an input device (via the wmi) which you might be able to sniff w/ evtest or acpi_listen

Mahbod Karamoozian · 2025-11-06 22:38:39

i am running the same offending apps across both platforms, userspace stack does not matter in the slightest according to my investigations

seth · 2025-11-06 22:40:20

Same wayland compositor? You're running waybar on kubuntu?

Mahbod Karamoozian · 2025-11-06 23:00:32

as i said userspace stack does not matter at all, yes i am running waybar on both environments, it's for the sake of testing battery polling, surely osu! wouldn't care about your DE to poll battery, if you read how i pinpointed the issue it should be very conclusive that the problem is not in the installation but in the packaging

Last edited by Mahbod Karamoozian (2025-11-06 23:01:26)

Mahbod Karamoozian · 2025-11-06 23:08:03

both distros poll the battery slowly and both distros spam logs with change udev events once the battery alarm is tripped but only arch has this weird freezing behaviour for battery polling apps
a workaround would be to set battery alarm upon power on and resume to below somewhere where upower would hibernate on critical power so that you'll never be bothered with this bugged state, thing is that this bugged state should not even exist as it doesn't in kubuntu, userspace stack is sidetracking and irrelevant talk compared to the low level stuff

Mahbod Karamoozian · 2025-11-07 00:32:28

for the final test i used the arch installation media to liveboot a minimal environment to rule out the final possibilities (being the filesystem and liveboot state) and seeing the same results as my existing archlinux install i am confident that i have found the culprit per #15 & #16

seth · 2025-11-07 08:11:51

for the final test i used the arch installation media to liveboot a minimal environment to rule out the final possibilities (being the filesystem and liveboot state) and seeing the same results as my existing archlinux install

And on ubuntu, cause you didn't test any userspace freezing here for sure and there's no mystery about the batteries discharge events and slow IO (as with acpi) when polling the battery.

It's the userspace process that freezes, waiting for IO that's slow on either system, right?
If you've identified the culprit, is should not be hard to provide a fix.

Edit: "strace -f -tt -o /tmp/waybar.strace" on either system to see which calls stall and whether and how they perform on kubuntu
Edit #2

grep -ri bat /{etc,usr/lib}/udev/rules.d/

Last edited by seth (2025-11-07 08:23:55)

Mahbod Karamoozian · 2025-11-07 15:04:04

right now i am in the process of frankensteining things together to find a trip point in the experimental subvolume, i have copied all the contents of kubuntu's udev directory to no avail same with copying the systemd and udev packages, the only thing i haven't done yet us to swap kernels because kubuntu live expects the casper image file, will report once i hit the trip point

Last edited by Mahbod Karamoozian (2025-11-07 15:45:26)

Mahbod Karamoozian · 2025-11-07 17:32:44

i installed kubuntu live on a persistent media for the sake of better testing and i have swapped kernels around for both kubuntu and arch but the results remain the same, anything that is wrong is wrong in the system space stack of arch since even from the archlinux installer this bug happens as established previoisly

edit: check page 2/post #26 for final findings

Last edited by Mahbod Karamoozian (2025-11-07 20:05:13)

Arch Linux

#1 2025-11-06 15:19:22

[SOLVED] udev causes some apps to freeze when battery alarm trips

#2 2025-11-06 15:43:51

Re: [SOLVED] udev causes some apps to freeze when battery alarm trips

#3 2025-11-06 15:58:53

Re: [SOLVED] udev causes some apps to freeze when battery alarm trips

#4 2025-11-06 16:22:42

Re: [SOLVED] udev causes some apps to freeze when battery alarm trips

#5 2025-11-06 16:59:41

Re: [SOLVED] udev causes some apps to freeze when battery alarm trips

#6 2025-11-06 17:21:45

Re: [SOLVED] udev causes some apps to freeze when battery alarm trips

#7 2025-11-06 19:28:07

Re: [SOLVED] udev causes some apps to freeze when battery alarm trips

#8 2025-11-06 20:04:31

Re: [SOLVED] udev causes some apps to freeze when battery alarm trips

#9 2025-11-06 20:31:21

Re: [SOLVED] udev causes some apps to freeze when battery alarm trips

#10 2025-11-06 21:04:49

Re: [SOLVED] udev causes some apps to freeze when battery alarm trips

#11 2025-11-06 21:12:03

Re: [SOLVED] udev causes some apps to freeze when battery alarm trips

#12 2025-11-06 21:13:33

Re: [SOLVED] udev causes some apps to freeze when battery alarm trips

#13 2025-11-06 21:24:23

Re: [SOLVED] udev causes some apps to freeze when battery alarm trips

#14 2025-11-06 21:27:15

Re: [SOLVED] udev causes some apps to freeze when battery alarm trips

#15 2025-11-06 22:01:08

Re: [SOLVED] udev causes some apps to freeze when battery alarm trips

#16 2025-11-06 22:24:34

Re: [SOLVED] udev causes some apps to freeze when battery alarm trips

#17 2025-11-06 22:36:41

Re: [SOLVED] udev causes some apps to freeze when battery alarm trips

#18 2025-11-06 22:38:39

Re: [SOLVED] udev causes some apps to freeze when battery alarm trips

#19 2025-11-06 22:40:20

Re: [SOLVED] udev causes some apps to freeze when battery alarm trips

#20 2025-11-06 23:00:32

Re: [SOLVED] udev causes some apps to freeze when battery alarm trips

#21 2025-11-06 23:08:03

Re: [SOLVED] udev causes some apps to freeze when battery alarm trips

#22 2025-11-07 00:32:28

Re: [SOLVED] udev causes some apps to freeze when battery alarm trips

#23 2025-11-07 08:11:51

Re: [SOLVED] udev causes some apps to freeze when battery alarm trips

#24 2025-11-07 15:04:04

Re: [SOLVED] udev causes some apps to freeze when battery alarm trips

#25 2025-11-07 17:32:44

Re: [SOLVED] udev causes some apps to freeze when battery alarm trips

Board footer