ksystemstats update breaks GPU sensors in KDE
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 52/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- linux
- Domain
- operating-systems
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.
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
- Dominant language
- Shell
- Stars
- 3.5k
- Forks
- 2.8k
- Avg merge
- 1d 23h
- Merged PRs (30d)
- 325
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing 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.
More from void-linux/void-packages
-
bug needs-testing
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
void-linux/void-packages#63249 · 3 comments ·
Maintainers usually reply within 1 day
-
xmlto: sources no longer available from upstreamPossibly taken @L1TerminalFault claimed this 5 days ago. Openbug needs-testing
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
void-linux/void-packages#63237 ·
Maintainers usually reply within 1 day
-
AI 🤖 bug needs-testing
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
void-linux/void-packages#63041 · 1 comment ·
Maintainers usually reply within 1 day
-
request
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
void-linux/void-packages#63016 ·
Maintainers usually reply within 1 day
-
nextcloud-client: VFS plugins installed where the client does not searchMay be free again A pull request for this issue was closed without being merged. Openbug needs-testing
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
void-linux/void-packages#62700 ·
Maintainers usually reply within 1 day
All issues in void-linux/void-packages
Similar issues
-
area:docs documentation good first issue priority:medium
Difficulty 1/5 Under an hour Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
PostHog/posthog-js#5524 ·
Maintainers usually reply within 2 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
paperclipai/paperclip#18671 ·
Maintainers usually reply within 1 day
-
package-update
Difficulty 1/5 Under an hour Newbie friendliness 62/100
Maintainers usually reply within 1 day
-
area:core
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
julian-hemmer/ypass#4 ·