Switching from GDM to SDDM enabled me to change my fan speed as well, so I’m seconding that this looks like an issue with xorg and root (or lack of it.)
Just to say that this issue seems present in potentially every branch that were recently updated (regression from a widespread change/fix?)
On amd64, I’ve tested manual fan control with at least:
450.102.04 (works), 450.119.03 (fails)
460.67 (works), 460.73.01 (fails)
465.19.01 (works), 465.24.02 (fails), 465.27 (fails)
I assume this applies to update from 390.141 to 390.143 as well.
As others stated, does work if Xorg is root or with CAP_SYS_ADMIN (not a good thing). Xorg as root is falling out of use, and many distributions will instead give limited access to /dev/nvidia*, so a solution would be appreciated.
Unfortunately, I am not able to duplicate issue locally.
I tried starting gnome with non root user and able to change GPU fan speed.
With Nvidia driver 465.27, I ran Xorg as rootless, for security, (logged in as a non-root user and then ran exec startx from tty1 to start Xorg and enter KDE Plasma) and GPU fan control and applying overclocks no longer works. It also fails to remember previously set power limit settings.
I originally thought it was due to a community tool but it’s apparently an issue with the driver, since the community tool is only a UX interface for doing the same things manually.
OS: Arch Linux
Coolbits: 31
(I did not use a login manager for this)
Just upgraded on Arch Linux and I’m experiencing the same problem. My GTX 1060 graphics card emits a harsh noise when spinning up/down so I set the fan speed to a fix value with this on startup:
nvidia-settings -a "[gpu:0]/GPUFanControlState=1" -a "[fan:0]/GPUTargetFanSpeed=55"`
Coolbits is set to 4:
Section "Device"
Identifier "Device0"
Driver "nvidia"
VendorName "NVIDIA Corporation"
Option "Coolbits" "4"
EndSection
I start X as user with exec startx from tty1
Setting the GPUTargetFanSpeed returns an “Unknown Error”. I downgraded the nvidia packages and the kernel and got it working again. Thanks @jwmaness!
Downgraded from:
nvidia-465.27-5
nvidia-settings-465.27-1
nvidia-utils-465.27-1
linux-5.12.2.arch1-1
Downgraded to:
nvidia-460.67-4
nvidia-settings-460.67-1
nvidia-utils-460.67-1
linux-5.11.10.arch1-1
Fan control still broken. managed to get mem oc and core oc working but no fan control after downgrading from 465 on ubuntu 20.10. Currently using drivers 460.73.01 can’t downgrade. Will nvidia fix this issue?
Hey guys, I’ve spent whole night and found something from 3 years ago that helped me. Works well even from startup:
nvidia-settings -a GPUGraphicsClockOffsetAllPerformanceLevels=N -a GPUMemoryTransferRateOffsetAllPerformanceLevels=N
Where N = Mhz
Hope that will help somebody. I am on lqx kernel, and aside from that glitch 465 felt choppy. I first downgraded to 455 (nvidia-settings too), but still couldn’t change overclock somehow. But now it works.
Yes, for the modern nvidia drivers you have to use those new attributes “GPUGraphicsClockOffsetAllPerformanceLevels” and “GPUMemoryTransferRateOffsetAllPerformanceLevels”. This is known as per my report above.
However, this is only tangentially related to this issue, the overclocks and fan settings can’t be set in Xorg rootless mode on the 465 New Feature releases, either in the GUI or via the CLI.
1 Like
The same issue occurs on the recently released 460.73 drivers as well. 460.67 did not have this issue.
Any news on this?
Here are some related bug reports/discussions at nvidia github:
https://github.com/NVIDIA/nvidia-settings/issues/65
https://github.com/NVIDIA/nvidia-settings/issues/63
Btw, as a workaround (if you don’t want to run xorg with root all the time) you can do this:
- start
nvidia-persistenced(otherwise the settings applied under rooted xorg (see below) are reset)
$ sudo nvidia-persistenced --user $USER
- make a custom xinitrc, like
.xinitrc_nvsettingsand add your desired nvidia-settings commandline
nvidia-settings -a "[gpu:0]/GPUFanControlState=1" -a "[fan:0]/GPUTargetFanSpeed=25"
- start rooted xorg, which just loads
.xinitrc_nvsettingsand quits (since nvidia-persistenced runs in the background, the settings are preserved) and start your normal rootless xorg afterwards.
$ sudo startx .xinitrc_nvsettings && startx
The Xwrapper config file is not needed for this. Tested under arch linux.
I’m doing something similar as a (hopefully temporary) workaround. However,
This isn’t the case for me: I’m not using nvidia-persistenced, but the settings are sticking. I created the file /etc/X11/xinit/xinitrc.d/60-nvidia-fans-80pct.sh, containing:
#!/bin/sh
if [ ! -z ${DISPLAY+x} ]; then
nvidia-settings -a "[gpu:0]/GPUFanControlState=1" -a "[fan:0]/GPUTargetFanSpeed=80"
fi
Important: if anyone copies this, remember to chmod +x /etc/X11/xinit/xinitrc.d/60-nvidia-fans-80pct.sh and maybe change the gpu:0 if you have multiple gpus.
Everytime I reboot, I manually log into the root account, run startx, log out and log in into my user account. With that, the error keeps happening if I try to change the values with nvidia-settings, but the fans are kept at 80%. If you need other settings, add them to the file above (you might wanna rename it, to reflect w/e it is that you’re doing).
The process of starting x with the root account is annoying, since it’s not automated - but I’m using i3, so starting and exiting is almost instant (it’s limited by my reaction time, not a ‘loading’ state). When I close the terminal opened at the end of xinitrc, X is killed (it was forked before the exec) - Last lines of my /etc/X11/xinit/xinitrc, used by root:
if [ -d /etc/X11/xinit/xinitrc.d ] ; then
for f in /etc/X11/xinit/xinitrc.d/?*.sh ; do
[ -x "$f" ] && . "$f"
done
unset f
fi
i3 &
exec alacritty
1 Like
Thanks, this works for me!
This is fixed for me with 470.63.01 under Arch Linux.
Still not working on Ubuntu 21.04 with the 470 driver.
@amrits To reiterate, this still occurs in 470.74
I’ve made a recording and made the bug report log file:
nvidia-bug-report.log.gz (287.5 KB)
recording.tar.gz (3.8 MB)
On OpenSUSE Tumbleweed with nvidia drivers installed from packages provided from nvidia’s repository I’m having issues setting the fan speed. Switching DM from gdm to LightDM allows GWE to work. Setting fan speed from console also works. If I revert to gdm setting the fan speed no longer works because of an “Unknown Error”
On Fedora 35, the only time when setting fan speed stops working is when I enable kernel modesetting. Setting fan speed on gdm is the default DM works fine though.
Recalling the issue with kernel modesetting on Fedora I made damn sure that nouveau isn’t loaded at all. Below are the arguments that the kernel is launched with on OpenSUSE:
splash=silent quiet modprobe.blacklist=nouveau rd.driver.blacklist=nouveau nvidia-drm.modeset=0 mitigations=auto
Still no dice on OpenSUSE. I’ve no idea what I should do.
This just still isn’t fixed. It “works” if Xorg happen to run as root (or has CAP_SYS_ADMIN which is essentially root, not sure for the “exact” requirement) but distros and display managers will try to avoid this where possible for security reasons – with nvidia at most they give the user access to /dev/nvidia* through video group or other methods (this /used/ to be enough to set fan speed, but not anymore).
I don’t use OpenSUSE or Fedora to confirm what they do, but GDM normally does not attempt to run Xorg as root anywhere anymore (so, can’t change fan speed), while I don’t think(?) LightDM has support for rootless Xorg yet (sddm gained support this year, but distros may not necessarily be using that yet).
modeset=1 may (depending on distro) cause GDM to use wayland until select a Xorg session, setting fan speed also doesn’t work on wayland so it may have been related to your previous issues… but that’s not related to this one.
Just reposting my previous message which I had to delete due to some issues with the content and editing posts isn’t possible after a while.
Nvidia - any update on this issue? It is still persist.