void-linux / void-linux/void-packages

ksystemstats update breaks GPU sensors in KDE

Open
#62,056 6 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

bug needs-testing
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 gpu
  • udevadm trigger -n -v -s pci -a 'class=0x030000' -a 'class=0x030200' -a 'class=0x038000' | grep '0000:26:00.0'
    does not

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.