system-frequently-crashing-after-gpu-drivers-update/62139/219
A Manjaro KDE user, noted above, is using a udev rule:
KERNEL=="card0", SUBSYSTEM=="drm", DRIVERS=="amdgpu", ATTR{device/power_dpm_force_performance_level}="high"
I cannot get this rule to work on my xfce system. It is placed in:
/etc/udev/rules.d/30-amdgpu-pm.rules
For some time a message was being logged:
Nov 06 09:56:27 user systemd-udevd[300]: card0: /etc/udev/rules.d/30-amdgpu-pm.rules:1 Failed to write ATTR{/sys/devices/pci0000:00/0000:00:02.1/0000:01:00.0/drm/card0/device/power_dpm_force_performance_level}, ignoring: Permission denied
The first failure was recorded May 21st. The rule was created May 2nd and the log began on March 13th.
What really perplexes me is that a demand trigger of the rule works!
sudo udevadm trigger
So there’s no question that the rule is good. Does anyone have a clue as to why it won’t run automatically? I tested on kernel 5.14.10 and 5.10.70 LTS. Systemd was updated around that same time:
stable-update-2021-03-18-kernels-plasma-frameworks-libreoffice-firefox-systemd
Sorry, I can’t post links yet. An easy way to check is with either of these commands:
udevadm info --attribute-walk /sys/class/drm/card0 | grep -Pi 'power_dpm'
udevadm info -a -n '/dev/dri/card0' | grep -Pi 'power_dpm'
What’s the ownership and permissions information for the rule file?
I forgot to mention that I’m not actually seeing “Permission denied” anymore. It showed up in the “Logs” as an “important” message for months up until the last major update.
As of today, I’m not getting a permission failure but the rule is also not being applied during startup and I can’t find anything in the journal that indicates a failure.
/etc/udev/rules.d
-rw-r--r-- 1 root root 108 Nov 9 17:47 30-amdgpu-pm.rules
-rw-r--r-- 1 root root 346 Oct 9 09:58 50-xow.rules
-rw-r--r-- 1 root root 58549 May 23 15:05 70-snap.core.rules
-rw-r--r-- 1 root root 94 Jul 15 07:46 99-evjs.rules
/usr/lib/rules.d
-rw-r--r-- 1 root root 8109 Aug 26 15:34 95-upower-hid.rules
-rw-r--r-- 1 root root 354 Aug 26 15:34 95-upower-wup.rules
-rw-r--r-- 1 root root 171 Aug 19 23:45 96-e2scrub.rules
-rw-r--r-- 1 root root 28 Sep 7 11:57 99-fuse3.rules
-rw-r--r-- 1 root root 28 May 16 2020 99-fuse.rules
-rw-r--r-- 1 root root 4604 Oct 4 14:21 99-systemd.rules
The only udev error in the logs is:
Nov 10 08:36:38 user systemd-udevd[310]: vhba_ctl: /usr/lib/udev/rules.d/60-linux514-vhba.rules:1 Only network interfaces can be renamed, ignoring NAME="vhba_ctl".
Notably all other rules are being applied. I feel like some sort of additional security layer has been added that affects sysfs per the AMDgpu documentation:
The amdgpu driver provides a sysfs API for adjusting certain power related parameters. The file power_dpm_force_performance_level is used for this. It accepts the following arguments:
auto
low
high
manual
profile_standard
profile_min_sclk
profile_min_mclk
profile_peak
Another useful command:
udevadm test "$(udevadm info -a -q path '/dev/dri/card0')"
card0: /etc/udev/rules.d/30-amdgpu-pm.rules:1 ATTR '/sys/devices/pci0000:00/0000:00:02.1/0000:01:00.0/drm/card0/device/power_dpm_force_performance_level' writing 'high'
udevadm trigger -v -n -a power_dpm_force_performance_level=high
/sys/devices/pci0000:00/0000:00:02.1/0000:01:00.0
udevadm trigger -v -n -t devices -s drm
/sys/devices/pci0000:00/0000:00:02.1/0000:01:00.0/drm/card0
/sys/devices/pci0000:00/0000:00:02.1/0000:01:00.0/drm/card0/card0-DP-1
/sys/devices/pci0000:00/0000:00:02.1/0000:01:00.0/drm/card0/card0-DVI-D-1
/sys/devices/pci0000:00/0000:00:02.1/0000:01:00.0/drm/card0/card0-DVI-D-2
/sys/devices/pci0000:00/0000:00:02.1/0000:01:00.0/drm/card0/card0-HDMI-A-1
/sys/devices/pci0000:00/0000:00:02.1/0000:01:00.0/drm/renderD128
I can’t combine those two and get a match:
udevadm trigger -v -n -t devices -s drm -a power_dpm_force_performance_level=high
I checked again today and am seeing the “permission denied” error so this has something to do with Linux security in general and not specifically Arch or Manjaro.
At some point a restriction must have been added somewhere when using a udev rule to write sysfs in this particular way.
I’ve given up and have moved to using “corectrl” which can change the setting after login. This method isn’t really acceptable.