Option "Coolbits" is not used | Optimus-enabled laptop running an RTX 2070 | Manjaro Linux

Hi there.
I’m trying to enable Coolbits so I can change the fan speeds of my Optimus-enabled laptop running Manjaro with an RTX 2070.

My current Xconf is as follows:

cat /etc/X11/xorg.conf.d/10-coolbits.conf 
Section "ServerLayout"
        Identifier      "layout"
        Screen 0        "iGPU"
        Option          "AllowNVIDIAGPUScreens"

Section "Device"
        Identifier      "iGPU"
        Driver          "modesetting"
        BusID           "PCI:0:2:0"

Section "Screen"
        Identifier      "iGPU"
        Device          "iGPU"

Section "Device"
        Identifier      "RTX"
        BusID           "PCI:1:0:0"
        Driver          "nvidia"
        VendorName      "NVIDIA"
        BoardName       "NVIDIA Corporation TU106M [GeForce RTX 2070 Mobile] (rev a1)"
        Option          "Coolbits" "12"

However it is not actually enabled. Using Nvidia bug report, I get the following messages:

cat nvidia-bug-report.log | grep Coolbits
[     7.816] (WW) NVIDIA(G0): Option "Coolbits" is not used
        Option          "Coolbits" "12"
[   114.674] (WW) NVIDIA(G0): Option "Coolbits" is not used

I’m currently at a loss on how I’m supposed to fix this. Any help would be greatly appreciated.
Thanks! <3
nvidia-bug-report.log (642 KB)

1 Like


This appears to be a driver bug. Namely, it seems that the Coolbits option can only be attached to an X screen associated with the GPU (it appears that if attached to GPU itself, the option gets transferred to the screen internally), but there is no X screen associated with the discrete GPU if you are using PRIME render offload. It will have to be fixed upstream.

Until it’s fixed upstream, I can provide a workaround for driver version 440.64. The file nvidia_drv.so should have sha1sum dbd03c529fd6d66c6a016a9cfbc4613be501e0fc. Perform the following replacements:

  • at offset 45970, replace 6 bytes with B801000000C3,
  • at offset 45A4B, replace 2 bytes with 9090,
  • at offset 45A86, replace 10 bytes with B8010000004883C408C3,
  • at offset 4A988, replace 1 byte with EB.

You should get a file with sha1sum d2a16889a058b0368371e1d5167f4f0fefab6800. These changes are roughly equivalent to using Option "Coolbits" "12" in xorg.conf for all of your GPUs regardless of whether there is an associated X screen. Enjoy!

Note that although I did my best to ensure the workaround is correct (and it works well for me), it might have unintended consequences, and so you are using it entirely at your own risk.


Was this ever fixed upstream? If not, could you provide me with a workaround for the 440.82 driver? Thank you

Nope. I did the work because I needed it myself, and provided it openly as a courtesy to other people who hit the same bug.

Ah, thanks for the info. So currently it is not possible to “fix” this in the 440.82 release?

It’s possible–you just have to do the work yourself.

No problem, thanks for clearing it up! I ended up switching to nvidia-only from my bios to check and there’s not a lot I can do on my laptop even with Coolbit set. So no point for me to pursue this course further. Thanks anyways!

1 Like

Exactly. Coolbits doesn’t work in offload mode but it’s pointless on notebook gpus anyway because those are locked by the vendor most if not all times.

Coolbits on notebook GPUs is not pointless. For instance, I have an old notebook where I can apply an offset of 398 MHz on memory clock and 200 MHz on graphics clock. I would not call that pointless. Please, avoid making such statements that could lead people (specially NVIDIA employees) to ignore the actual problem. I see no technical reason for Coolbits to not work with PRIME Render Offload. Yes, the option is currently tied to an X screen, but why should it be? If I revert to a setup with NVIDIA’s card only (old PRIME setup), I can set Coolbits. It is a software limitation, and the patch previously posted here is a proof that it is indeed possible to fix it. Will NVIDIA do it? That is the question that remains unanswered.


I need this feature as well. It seems the issue to be simple enough for NVIDIA to fix. So why aren’t they doing something about it? Why put your customers thru the misery of manually having to patch a binary?

I filed internal bug request 3188001 to track adding a way to do this without using sketchy-looking binary patches of dubious origin. :)

The bug tracker is not public but you can refer to this number in the future to make it easier for us to look it up.


In the meantime, I found a cleaner way of overclocking without sacrificing the use of NVDIA’s PRIME Render Offload. It consists of:

  1. launch Xorg with normal PRIME;
  2. assign the desired clock offsets through nvidia-settings;
  3. close the current Xorg session;
  4. relaunch Xorg with PRIME Render Offload.

The key idea is that the clock offsets are not lost between Xorg sessions. In step 4 you will not be able to change the offsets, but they will still have the same values you assigned in step 2.

I created a simple script to automate two calls of startx. The first call only executes nvidia-settings to assign the offsets and subsequently closes. The second call properly starts the window manager. Some changes in .xinitrc are also required, as well as a symbolic link in /etc/X11/xorg.conf.d/ to the proper configuration file for each startx call. I have no idea how to achieve the same level of automation using a login manager (sorry).

If anyone is interested, I can share my scripts here.

1 Like

I would like to see your scripts. I have made some before and it worked on a Debian-based distro, but does not with Manjaro. Maybe I would be able to use yours… Mine was quite weird - on boot, a systemd service. A script starts that changes tty to tty7 (some systemd way), and there changes xorg config (file copy), starts X, runs prime-offload, runs GWE app (that applies the OC), sleeps for a bit, kills the session and then switches back to tty1 plus reverts xorg.conf. That was spaced out between 5 bash scripts because of my noobish bash skills (basically wouldn’t work otherwise). I bet your implementation is cleanier.

Btw, I am able to apply +400mhz memory offset and +200mhz graphics offset without a hitch. These high memory offsets manage to overpower my laptops charger, so while the laptop is mining (both CPU and GPU), it has to draw up to ~1A (~15W) from battery, which is a bit sketchy, but fun to see. Because of repasting (and CPU undervolt) it manages a very good sustained load.
I always use prime render offload, AND overclock. But it is unnecessarily complicated, as you say.
To be fair, graphics OC makes significant difference in gaming. Memory offsets increase hashes quite well, but I only turn on miners when it is cold at my dorm (heaters are not permitted, so a bit of a workaround). And prime render offload then is the only way to have a smooth desktop experience.

Alright, here we go: nvidia-startx-oc.zip (4.1 KB)
I zipped all required files and included a README with instructions of how to use them. If you have any questions or problems, feel free to contact me (although I can not guarantee I will be able to help). It is a very basic script, you may need to add more options to match your needs.

I’ve never seen my laptop draw energy from both, charger and battery. That is a bit weird. You changed the power limit or overvolted the gpu?
I did not stress my system too much beyond gaming, perhaps on a heavier, sustained workload it also would show this peculiar behavior. Well, I hope my 120W power supply has enough headroom to overclock without this… trick?
And nice workaround to the heaters prohibition. XD

1 Like

Thats a perfect script, the only big change is going to be the last command in shell script. Instead of “startx” it’ll be “systemctl start sddm”. Though considering that most often use-case is a single-user system, startx makes a lot of sense.

About the power draw – I believe the GTX1050 in my laptop is underclocked a bit:
By default it shows max graphics frequency of ~1950mhz, but it only ever reaches ~1750mhz. So I overclock it by 200mhz and then it shows max frequency of ~2150mhz, while actually maxing out at ~1950mhz.
No overvolting or powerlimit changes. The power draw outpaces the charger when fiddling with memory frequency going from ~3500/7000 to ~3700/7400. For some reason the GPU gets really hungry. I guess it increases voltage automatically (maybe the default memory frequency is also higher?).

The charger is 135W, btw :D
It was fun to watch, but I am not sure the laptop is happy with this above-design power consumption. I doubt GPU would kick off (die), but I am less confident of “suporting” circuitry (MOSFETs, etc).

To be honest, I love abusing electronics, but I’ll take some caution with the laptop.
I also have a PC with GT430, and the fermi GPU is too old for mining (just to get the idea how old the PC is). CPU is good enough, though it has no AES acceleration.
A bit of fiddling with fancontrol and I have a second, silent heater. The PSU cable connectors to the CPU are a bit toast, so there are some stability issues on sustained load.
It also makes some vruum vruum sounds when restarting fancontrol service (as OS loses fan control momentarily).

PS.: Thank you for the script and the extensive documentation.

1 Like

On my Razer Blade 15 Advanced (2080 Super MaxQ) I’d like to stay with Hybrid graphic mode on PopOS and using Coolbits options if possible.
Currently running 460.32.03 on PopOs! 20.10

Any news about this bug?


Hello, any news about this bug request? It would be really cool to use the CoolBits option without needing to start a separate Xorg server.