465.24.02 - No longer able to set Graphics Clock Offset and Memory Transfer Rate Offset

Interesting. 5.3.0-64-generic is a bit older version than linux 5.11.16.arch1-1, so maybe that’s somehow a factor.

Could you try with kernel 5.11 or 5.12 (and possibly Nvidia driver version 460.73) to see if the issue occurs then? I’m having the issue on both kernels with that driver version.

Here’s the nvidia-bug-report with dmidecode output. This is with the 5.11.16-arch1-1 kernel and 465.24.02 driver.

nvidia-bug-report.log.gz (243.6 KB)

I am using Ubuntu 20.10 and 460 when i updated via software update I lost fan control. OC of the core and power limit still works, but fan control is became broken. I decided to install 465 and can’t change anything. went back to 460 via deb. And oc of core works again but fan control is still broken. I am using 5.8.0-50-generic and xanmod 5.11.17. No difference between the two. Is this something that can be fixed with an update or will i have to downgrade. Also would like to mention i use greenwithenvy, but can’t change fan with either xserver or gwe. says failed to set new fan speed!.

Related archlinux bug report: FS#70515 : [nvidia-dkms] GPUTargetFanSpeed does not work on 465.X.X

465.27
I had this problem and still have it with the new version.
However
I’ve read this
https://wiki.archlinux.org/index.php/NVIDIA/Troubleshooting#Overclocking_not_working_with_Unknown_Error
so I thought it might be a problem with gdm which starts Xorg rootless.
installed sddm and plasma to try both gnome and plasma on sddm. and it WORKED IN BOTH (fan,memory overclock,coreoverclock).
I don’t know why this problem appeared now I’ve always used gdm and it still works on older versions of the driver so maybe it’s a packaging trick that used to be done on arch downstream and now it doesn’t or a driver change that re-required root-Xorg.
I’ll post this here and on the arch downstream bug report.

I tried duplicating issue with kernel 5.11 on driver 465.24.02. and 460.73 but no luck.
Precision T7600 + Fedora release 32 + 5.11.16-100.fc32.x86_64 + NVIDIA TITAN Xp + 465.24.02

Highlighting steps tried at my end -

  1. On terminal, ran command nvidia-xconfig --cool-bits=4
  2. opened nvidia-settings, under thermal settings option, enabled GPU Fan Setting and changed fan speed using scroll bar
  3. Apply
    Closed nvidia-settings and reopened again to verify the changed speed.

@amrits
Do you use rootless xorg?

Anyway, xorg under root should never be required for this functionality. So if nvidia has changed this, which seems to be the case atm (affected distros at least arch & ubuntu according to this thread), this should get fixed.

2 Likes

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.

To my understanding, GDM runs Xorg as rootless by default when a particular kernel mode setting is used.

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?

@starfall Thanks man! that worked for me for now. until they fix this.

1 Like

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_nvsettings and 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_nvsettings and 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