Source: sysfsutils Version: 2.1.0+repack-4+b2 Severity: important I've had the following lines in my /etc/sysfs.conf for years: bus/pci/drivers/radeon/0000:02:00.0/power_method = profile bus/pci/drivers/radeon/0000:02:00.0/power_profile = low
Retrospectively, I think that's because at the time I installed the machine, the radeon driver didn't have dpm yet, which it now does. And since it does, the radeon driver actually throws an EINVAL when writing those sysfs prefs above: https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/radeon/radeon_pm.c#L437-L440 because dpm is now the default, and you can't switch away from it. Anyways, this probably was failing already at startup, which I failed to see, until I upgraded from jessie to stretch, the process of which failed because of the sysfsutils service restart during the package upgrade. This might be fair game, but the real problem is that it's impossible to debug in a straightforward way: the startup script for the "service" is a shell script that doesn't output anything useful in case of errors. All I got was: Setting sysfs variables...sh: echo: I/O error which doesn't tell you which one has failed. So next, I tried sh -x /etc/init.d/sysfsutils start, but thanks to systemd, that just called systemctl which reinvoked the script without -x. So I ended up adding set -x to the script, which finally allowed me to get some more in the systemd log, namely, the following output: + [ -f /sys/bus/pci/drivers/radeon/0000:02:00.0/power_method ] + echo -n profile + echo profile sh: echo: I/O error I'm not saying the script should come with set -x set, but at the very least, it should print out something useful when something fails to be set for some reason. Mike
