void-linux / void-linux/void-packages
ksystemstats update breaks GPU sensors in KDE
Nobody has claimed this yet.
- Dominant language
- Shell
- Stars
- 3.4k
- Forks
- 2.8k
- Avg merge
- 2d 5h
- Merged PRs (30d)
- 299
Description
Is this a new report?
Yes
System Info
Void 6.18.44_1 x86_64 AuthenticAMD notuptodate hold rrrrmmnFFFF
Package(s) Affected
ksystemstats-6.7.4_1
Does a report exist for this bug with the project's home (upstream) and/or another distro?
didn't find any and that's the question where it belongs
After upgrading ksystemstats from 6.6.3_1 to 6.7.4_1, all GPU sensors disappeared from system monitor (KDE plasma)
system:
ksystemstats-6.7.4_1
eudev-3.2.14_2
eudev-libudev-3.2.14_2
NVIDIA TU106, proprietary driver
PCI class: 0x030000
nvidia-smi shows stuff: temp, wattage, usage, etc. kstatsviewer --list | grep '^gpu' only shows:
gpu GPU
no gpu0 sensors are created (used to be on 6.6.3_1), so system monitor does not see any GPU info + thermal monitor plugin (shows CPU/GPU temps in a bar) does not see GPU temps too
downgrading only ksystemstats to 6.6.3_1 immediately restores GPU util, temps, etc.
digged into what causes it, and it seems like systemd vs eudev difference. I'm not sure this is even correct, but that's my limit of system understanding at this point
KDE uses udev_enumerate_add_match_sysattr three times (introduced not so long ago),
https://invent.kde.org/plasma/ksystemstats/-/blob/master/plugins/gpu/LinuxBackend.cpp?blame=1#L52-54
eudev seems to just add three values to list
https://github.com/eudev-project/eudev/blob/master/src/libudev/libudev-enumerate.c#L398
and uses AND between them which obviously results in an empty list
while systemd seems to use OR
https://github.com/systemd/systemd/blob/main/src/libudev/libudev-enumerate.c#L224
so ksystemstats is relying on systemd OR semantics which breaks Void's eudev treats the same calls as AND
not sure what is the correct place for a fix, likely eudev?
Expected behaviour
KDE to see GPU sensors (gpu0...)
kstatsviewer --list | grep '^gpu'
gpu/all/usedVram All GPUs Used Memory
gpu/gpu0/totalVram GPU 1 Total Video Memory
gpu/all All GPUs
gpu/gpu0/usage GPU 1 Usage
gpu/gpu0/memoryFrequency GPU 1 Memory Frequency
gpu/gpu0/temperature GPU 1 Temperature
gpu/gpu0/coreFrequency GPU 1 Frequency
gpu/gpu0/usedVram GPU 1 Video Memory Used
gpu/gpu0/power GPU 1 Power
gpu/gpu0/name GPU 1 Name
gpu/gpu0 GPU 1
gpu/all/usage All GPUs Usage
gpu GPU
gpu/all/totalVram All GPUs Total Memory
Actual behaviour
kstatsviewer --list | grep '^gpu'
gpu GPU
and nothing else
Steps to reproduce
how I "reproduced" the behavior bug (GPU is 0000:26:00.0):
udevadm trigger -n -v -s pci -a 'class=0x030000' | grep '0000:26:00.0'
sees gpuudevadm trigger -n -v -s pci -a 'class=0x030000' -a 'class=0x030200' -a 'class=0x038000' | grep '0000:26:00.0'
does not
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with KDE's plugins/gpu/LinuxBackend.cpp around the three udev_enumerate_add_match_sysattr calls, then reproduce the difference with the two udevadm trigger commands from the report. Compare the enumeration behavior against eudev and systemd, and verify completion when kstatsviewer --list again shows gpu0 sensors and KDE exposes GPU metrics.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- linux
- Domain
- operating-systems
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 52/100