prime-select intel is not powering off the nvidia card

Bug #1765363 reported by Tim Richardson on 2018-04-19
This bug affects 78 people
Affects Status Importance Assigned to Milestone
nvidia-prime (Ubuntu)

Bug Description

Right now, it seems that prime-select intel makes sure the nvidia driver is not loaded, as nvidia-settings reports.
But my power consumption is > 20W.
cat /proc/acpi/bbswitch reports the card is still on.

If bbswitch and powertop are reliable, then the nvidia card is still powered.
This is a thinkpad w520 in Optimus mode.

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: nvidia-prime 0.8.7
ProcVersionSignature: Ubuntu 4.15.0-15.16-generic 4.15.15
Uname: Linux 4.15.0-15-generic x86_64
ApportVersion: 2.20.9-0ubuntu5
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Thu Apr 19 19:56:21 2018

EcryptfsInUse: Yes
InstallationDate: Installed on 2017-12-14 (125 days ago)
InstallationMedia: Ubuntu 17.10 "Artful Aardvark" - Release amd64 (20171018)
PackageArchitecture: all
SourcePackage: nvidia-prime
UpgradeStatus: Upgraded to bionic on 2018-03-09 (41 days ago)

Tim Richardson (tim-richardson) wrote :
Tim Richardson (tim-richardson) wrote :

However, I do not have this problem on my Thinkpad P50. The nvidia card is definitely turned off when in hybrid graphics after prime-select intel

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in nvidia-prime (Ubuntu):
status: New → Confirmed
Giraffe (dodger-forum) wrote :

Same here using a Precision 7510 after selecting Intel (sudo prime-select intel && sudo reboot) the following happens:

apr 24 07:23:10 Precision-7510 systemd[1]: Starting Fall back on nouveau if nvidia is not loaded...
apr 24 07:23:10 Precision-7510 kernel: nouveau 0000:01:00.0: NVIDIA GM107 (117300a2)
apr 24 07:23:11 Precision-7510 systemd[1]: Started Fall back on nouveau if nvidia is not loaded.

Then Nouveau wil load and the Nvidia dGPU will run on Nouveau and stay powered on.

Giraffe (dodger-forum) wrote :

Running Xubuntu 18.04 by the way.

Francois Thirioux (fthx) wrote :

I confirm a power usage issue.
Dell 7510 (too !)
Ubuntu (GNOME) 18.04
Nvidia M1000M

I found that the file :
is not removed by prime when switching to Nvidia, so the module cannot be loaded (as far I understand the stuff). When I remove it and load with Nvidia mode, the Nvidia module is loaded, not the Nouveau module.

The grub option "" (or something like that) is either not removed when purging Nvidia-390 stack. Removing it manually allows to use Nouveau with normal (low) power usage.

I did not succeed to get a Nvidia-390 with Intel mode AND dGPU powered off.

Alain Rouet (alain-rouet) wrote :

So, if I understand what's happening here. When switching to Intel, both Nouveau and the proprietary driver are blacklisted and the power management is disabled because of "" kernel parameter. The discrete GPU is therefore always ON, but cannot be used at all.

Why not just blacklist the proprietary driver to let Nouveau take care of the power management? It would also be great, if possible, to add "nvidia-drm.modeset=1" kernel parameter to enable prime synchronisation to avoid tearing.

Alberto Milone (albertomilone) wrote :

When switching to Intel, nouveau is loaded manually (overriding the blacklist), and switches off the dGPU.

The leftover /etc/modprobe.d/blacklist-nvidia.conf should be removed when switching back to Nvidia.

P.S. We cannot enable nvidia-drm.modeset by default, because it breaks SLI.

Alain Rouet (alain-rouet) wrote :

I didn't know about the SLI breakage, my bad.

Just did a clean install and I can confirm that it's working as it should:

$ xrandr --listproviders
Providers: number : 2
Provider 0: id: 0x65 cap: 0x9, Source Output, Sink Offload crtcs: 3 outputs: 3 associated providers: 1 name:modesetting
Provider 1: id: 0x3f cap: 0x4, Source Offload crtcs: 0 outputs: 0 associated providers: 1 name:nouveau

# cat /sys/kernel/debug/vgaswitcheroo/switch
1:DIS: :Off:0000:01:00.0

Alberto Milone (albertomilone) wrote :

Great, thanks for testing!

Loris Zinsou (nepenthes) wrote :

Unfortunately, nouveau makes laptops with a Pascal dGPU (GeForce 10xx series) really unstable.

For example my Dell XPS 9560 with a GTX 1050 won't boot without "nouveau.runpm=0".
With "nouveau.runpm=0", boot will be slow, and multiple freezes with a recovery a few seconds later will occur after graphical login. The system remains sluggish even as the iGPU is used.
(there might be other bugs affecting general stability with Pascal dGPUs)

If I blacklist nouveau completely (both as a kernel boot option and in /etc/modprobe.d/), the system will function normally, but the dGPU will stay on.

Forcing the use of nouveau on these recent laptops, especially for a LTS, really is a step backwards compared to what we had in 17.10.

Francois Thirioux (fthx) wrote :

Running Quadro M1000M, no crash running Nouveau (just poor perf as everybody)

Well, if I select intel through prime, the line is put in kernel parameters in grub. I've excluded nvidia & nouveau from runtime pm in tlp, to not interfere here.
The result is that I get 15 W power usage.

If I delete the kernel option & update grub, and if I do not exclude nvidia nouveau from runtime pm in TLP, I get 5 W running the same backlight & wifi settings.

cat /sys/kernel/debug/vgaswitcheroo/switch shows
1:DIS: :Off:0000:01:00.0
too, but anyway the FACT is that the power usage on my Dell 7510 is much higher, and is 100 % related to some stuff involving nvidia/prime.

Francois Thirioux (fthx) wrote :

Definitely not TLP-related since I experience the same difference without TLP installed.

Alain Rouet (alain-rouet) wrote :

Seems like you're right, François. I installed Powertop on both Ubuntu 18.04 (~12.5W at idle) and Fedora 27 (~5W) on the same laptop to measure the power comsumption. The method is not what I'd call scientific, but the difference is big enough to tell there's indeed something wrong.
On Fedora, I installed the proprietary driver via RPM Fusion, and disabled it with "modprobe.blacklist=nvidia,nvidia_drm,nvidia_modeset,nvidia_uvm" kernel parameter.

Alain Rouet (alain-rouet) wrote :

I tried something this morning, since I was convinced that this problem revolves around Nouveau power management.

I made a backup of prime-select,
# cp /usr/bin/prime-select /usr/bin/prime-select.orig

and replaced the parameter that disables Nouveau power management (as per
# sed -i "s/boot_params\['nouveau.runpm'\] = '0'/boot_params\['nouveau.runpm'\] = '-1'/" /usr/bin/prime-select

After restarting on the integrated GPU, I launched Powertop (sudo powertop) in a terminal to measure the power consumption at idle, and it was around 6W.

Loris Zinsou (nepenthes) wrote :

@Alain What's you graphics card?
nouveau.runpm=-1 is the default setting for nouveau on Optimus systems. If the graphics card is not used, it will be powered down after 5 seconds iirc. As you did, this can be forced in the kernel boot parameters.
Unfortunately, with this setting, systems with recent graphics cards (GTX 10xx series) will not reach a usable desktop after login, and end up with a black screen.
I couldn't confirm but it may be this bug:

With nouveau.runpm=0, I experience slowdowns and lockups even if the Intel iGPU is in use, so some other nouveau bug might be involved.

Alain Rouet (alain-rouet) wrote :

$ lspci | grep 3D
01:00.0 3D controller: NVIDIA Corporation GM107M [GeForce GTX 950M] (rev a2)

I should have specified it earlier, sorry.

Beavis (gordian-dziwis) wrote :

This is a regression, with xubuntu 17.10 prime worked fine.

Beavis (gordian-dziwis) wrote :

So pascal based gpu cant be turned of because powermanagment for nouveau is broken and disabled? And the loaded nouveau driver is causing freezes and slow down and instabilities?

Is there a workaround? Or does Ubuntu 18.04 break every laptop with an pascal gpu.

Jan Alexander (jan-alexander) wrote :

I can confirm the same issue on 18.04 using Gigabyte AERO 15x v8 with Nvidia GTX 1070 MaxQ. The `prime-select intel` method leaves the card powered on, even though the vgaswitcheroo/switch indicates it's off - the system power draw is ~ 20W.

After installing bbswitch and turning the card off that way (had to mask off the nvidia-fallback to prevent manual loading of the nouveau module), the power draw drops to ~ 10W so the card is indeed powered off in that case.

There is something broken in nouveau driver for my system as it is unable to power down the card using the vgaswitcheroo method, when running with nouveau.runpm=0.

Noam Mor (noam-mor) wrote :

Can confirm on a Dell XPS 9550 - power draw went from ~7W to ~20W after updating to 18.04, even with prime-select intel.

Tom (tom-lorinthe) wrote :

Confirming on Dell XPS 15 9560; Nvidia is not power-down when prime selecting Intel: I am now on 13W with TLP enabled... 17.10 would give me about half of that.

In addition, I cant suspend properly. Half of the times it will freeze an I need to force power down...

Together with ir seems that 18.04 indeed broke all Nvidia dual laptops.

Артем (givespam) wrote :

Confirm on Lenovo ideapad 520S-14IKB (Intel i5-7gen, Nvidia 940MX , Intel 620HD).
On Ubuntu 17.10 (Nvidia driver 390.48 from ppa:graphics-drivers/ppa ppa:graphics-drivers/ppa) prime-select worked fine.
On Ubuntu 18.04 prime-select not turn off nvidia (driver from ppa and driver from repository).
Nouveau and bumblebee switches the graphics card well.

I noticed a different output of the command: cat /sys/kernel/debug/vgaswitcheroo/switch

nouveau driver:
1:DIS: :DynOff:0000:01:00.0

nvidia 390.48, after prime-select intel:
1:DIS: :Off:0000:01:00.0

You can see the different status of the discrete card. When "DunOff" it really disconnected from the power supply, and in case of "Off" it continues to consume energy. If it matters.

Артем (givespam) wrote :

Correction. I run command of Alain Rouet (alain-rouet):
# sed -i "s/boot_params\['nouveau.runpm'\] = '0'/boot_params\['nouveau.runpm'\] = '-1'/" /usr/bin/prime-select

And output of the coomand cat /sys/kernel/debug/vgaswitcheroo/switch was different. Now it's:
1:DIS: :DynOff:0000:01:00.0

And my nvidia card realy turn of. Thank you Alain Rouet! You are cool!

Francois Thirioux (fthx) wrote :

I confirm, when you delete the nouveau.runpm=0 option from grub (no need to force the -1 value if you just modify the grub file, it's default if @nepenthes is right), you get :

sudo cat /sys/kernel/debug/vgaswitcheroo/switch

1:DIS: :DynOff:0000:01:00.0

On my machine even removing nouveau.runpm=0 didn't work, Nouveau was not able to turn off the card.

Dedas (andreas-winkler) wrote :

I tried this on my Dell XPS 15 but without nouveau.runpm=0 the login freezes. With it on the GTX 1050 doesn't really turn off. Any clues?

Giraffe (dodger-forum) wrote :

To manually disable you discrete graphics card:
sudo systemctl disable nvidia-fallback
sudo -s
modprobe -r nvidia && modprobe bbswitch && echo "OFF">/proc/acpi/bbswitch && logger Nvidia OFF

the last set of commands have to be re-entered after reboot but it gets the job done for now.

Noam Mor (noam-mor) wrote :

Changing nouveau.runpm=0 to nouveau.runpm=-1 in /etc/default/grub, and then running update-grub, fixed the issue. Back to 6W. Dell XPS 9550.

Stefan Girstmair (djefo) wrote :

@Noam Mor:

What driver did you use then? I tried it and it just booted into a black screen.

Loris Zinsou (nepenthes) wrote :

@Stefan: When you're using nouveau.runpm=-1, nouveau is always used to dynamically power down the card. This works because a Dell XPS 9550 ships with a GeForce GTX 960M, which nouveau is actually able to power down, unlike the more recent XPS 560 with a GTX 1050.

pagetronic (pagetronic) wrote :

Same here, NVIDIA Quadro M2000M (GM107GLM).

I can turn it off with acpi-call-dkms
echo '\_SB.PCI0.PEG0.PEGP._OFF' > /proc/acpi/call

But it freeze on reboot or suspend.

Stefan Girstmair (djefo) wrote :

Thanks Loris,

ok. I have a laptop with a 1070 maxq, so i guess this does not work then. Guess I'll have to wait for an official fix then.

Beavis (gordian-dziwis) wrote :

Following worked for me to get the dgpu switched off on an xps 15 9560.

1. Purge nvidia
2. Install nvidia and do not reboot
3. Install bumblebee-nvidia
4. Set bootparameters are to acpi_rev_override=1 and i915.modeset=1

If you have tlp installed uncomment:
#RUNTIME_PM_DRIVER_BLACKLIST="amdgpu nouveau nvidia radeon"

Could not get optirun to work. Switching to nvidia with prime works, but switching back to intel gives a black screen with only the cursor visible. Making goto step 1. necessary.

Beavis (gordian-dziwis) wrote :

I forgot a bootparameter: "nouveau.modeset=0".

Francois Thirioux (fthx) wrote :

Please note that
RUNTIME_PM_DRIVER_BLACKLIST="amdgpu nouveau nvidia radeon"
is TLP's default (happens too if the line is commented), so if you don't want to blacklist any driver you have to set
as TLP config file's comments warn us about this trick.

Loris Zinsou (nepenthes) wrote :

Let's try to let nouveau turn off the dGPU with a mainline 4.17rc6 kernel, probably available as DEB packages tomorrow (21/05/2018) from
See this PR:

It includes an ACPI fix critical for Optimus laptops (making the acpi_osi and acpi_rev_override workarounds obsolete).
This may not be enough to get a stable system with GeForce 10xx series and nouveau just yet, but it's worth trying.

Loris Zinsou (nepenthes) wrote :

I'm now using a mainline 4.17rc6 kernel, and it looks like ACPI errors are gone, however nouveau will still make my system unstable, causing a freeze on using `lspci` and on graphical login.

For systems with a GTX 1050/ GTX 1050 Ti, relevant bugs on nouveau bug tracker are:

sadly it looks that there hasn't been any progress regarding these issues.

Matthieu Gras (grasm) wrote :

For anyone who is looking for a solution to their problem with newer Nvidia cards and the regression that you need to reboot to switch graphics:

I solved the problem by using bbswitch instead of nouveau to switch off the graphics cards and communication to a socket of a simple Rust program which kills the Xserver, and unloads the nvidia kernel modules without having to reboot.

Matthieu Gras (grasm) wrote :

My solution also works around another bug which causes Ubuntu to default to a low framerate (40Hz for me) by using the intel driver instead of the modesetting driver and using custom modeline settings. If you don't want that remove the monitor config file and adapt the makefile.

Matthieu's code is the best solution I've seen, as long as you are ok with lightdm.
The multi-dispatch aspects of the new module are a good simplification, Matthieu's approach looks like it's now easy to switch between intel and hybrid modes; he just blacklists modules.

Dear maintainers, it seems a shame to stop using bbswitch, the cause of all the functional and user-experience regressions of the new package.

tom (tombuntus) wrote :

Here's my workaround, running on xps 15" with 1050.

sudo apt install nvidia-prime

kernel param nouveau.modeset=0 (I think this is probably dumb of me, but not sure)

sudo prime-select intel

sudo apt install bbswitch-dkms

add bbswitch to /etc/modules by

sudo gedit /etc/modules

and add the line

bbswitch load_state=0

(this did not work for me)

I have to use
sudo tee /proc/acpi/bbswitch <<<OFF

but i'm finally running intel, at a cost of 10-11W in powertop

sudo powertop

(unplug your laptop before running powertop, or you can't see wattage)

tom (tombuntus) wrote :

Ok, here's more complete detail, for 18.04. Do same as before with
kernel param nouveau.modeset=0 (I think this is probably dumb of me, but not sure)

sudo apt install nvidia-prime
sudo prime-select intel
sudo apt install bbswitch-dkms

then, the last part is a little different:

sudo gedit /etc/modules

and add


(no load_state=0)

sudo gedit /etc/modprobe.d/bbswitch.conf


options bbswitch load_state=0

and save and quit.

Now it runs intel, with nvidia off, every time from startup.

Michal Hruby (mhr3) wrote :

Thanks @tombuntus, works on my xps 9560 as well, even though I had to run `echo "OFF">/proc/acpi/bbswitch` after reboot. Also fixes problems with suspend.

Stefan Girstmair (djefo) wrote :

@tombuntus and @ mhr3

thanks for your help. I followed all the steps but do not seem to have successfully changed anything on my system. Still the same powerconsumption. And the two commands you said you had to run (echo "OFF">/proc/acpi/bbswitch, and sudo tee /proc/acpi/bbswitch <<<OFF) do not work for me. I am not even able to find bbswitch in the /proc/acpi/ folder.
Do you maybe know what the problem could be?

I've made a few tweaks which you can see here

it now works between reboots. I should do a fresh install to make sure it works without action. For example, I've made a note that after install I did

sudo systemctl enable prime-socket

the problem I have is that I don't have any clue about what I'm doing.

Leonardo (rnalrd) wrote :

Setting "nouveau.modeset=-1" does not help here. My DELL XPS L502X is still running hot:

~$ sudo service lm-sensors status
● lm-sensors.service - Initialize hardware monitoring sensors
   Loaded: loaded (/lib/systemd/system/lm-sensors.service; enabled; vendor preset: enabled)
   Active: active (exited) since Thu 2018-06-07 20:18:15 CEST; 27min ago
  Process: 991 ExecStart=/usr/bin/sensors (code=exited, status=0/SUCCESS)
  Process: 807 ExecStart=/usr/bin/sensors -s (code=exited, status=0/SUCCESS)
 Main PID: 991 (code=exited, status=0/SUCCESS)

giu 07 20:18:15 xps sensors[991]: acpitz-virtual-0
giu 07 20:18:15 xps sensors[991]: Adapter: Virtual device
giu 07 20:18:15 xps sensors[991]: temp1: +96.0°C (crit = +100.0°C)
giu 07 20:18:15 xps sensors[991]: temp2: +96.0°C (crit = +100.0°C)
giu 07 20:18:15 xps sensors[991]: coretemp-isa-0000
giu 07 20:18:15 xps sensors[991]: Adapter: ISA adapter
giu 07 20:18:15 xps sensors[991]: Package id 0: +96.0°C (high = +86.0°C, crit = +100.0°C)
giu 07 20:18:15 xps sensors[991]: Core 0: +96.0°C (high = +86.0°C, crit = +100.0°C)
giu 07 20:18:15 xps sensors[991]: Core 1: +95.0°C (high = +86.0°C, crit = +100.0°C)
giu 07 20:18:15 xps systemd[1]: Started Initialize hardware monitoring sensors.

~$ cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-4.15.0-22-lowlatency root=UUID=345b57d7-dea8-44de-a3c0-4614b87a4565 ro quiet splash video=VGA2:d nouveau.runpm=-1 vt.handoff=1

~$ cat /proc/acpi/bbswitch
0000:01:00.0 ON

~$ sudo cat /sys/kernel/debug/vgaswitcheroo/switch
1:DIS: :DynPwr:0000:01:00.0

~$ sudo lsmod | grep nouveau
nouveau 1716224 1
mxm_wmi 16384 1 nouveau
ttm 102400 1 nouveau
wmi 24576 5 dell_wmi,wmi_bmof,dell_wmi_descriptor,mxm_wmi,nouveau
i2c_algo_bit 16384 2 nouveau,i915
drm_kms_helper 167936 2 nouveau,i915
drm 397312 8 nouveau,i915,ttm,drm_kms_helper
video 40960 4 dell_wmi,dell_laptop,nouveau,i915


Diego (panopliaespartana) wrote :

Same problem with Lenovo Legion Y520.
Intel HD 640 / Nvidia GTX 1050 Ti

Kostadin Stoilov (kmstoilov) wrote :

I am experiencing the same problem on a Dell XPS 9550 with a GTX 960M.

I just upgraded from 16.04 where prime-select was able to power the graphics card down with bbswitch.

Strangely enough even nouveau is perfectly capable of powering down the card if it does not have which disables the power management feature.

Sadly this is in the grub config generated by prime-select intel.

For now i have removed the nvidia proprietary drivers to get back decent battery life.

Uranicus (matthias.ritter) wrote :

I applied the tweak of Tim (#46) on my Medion P6812 with a NVIDIA Corporation GF116M [GeForce GT 555M/635M].

After a clean install of Ubuntu 18.04.1 with the application of the Nvidia driver (switching to Intel) the power (by powertop) went from approx. 18 W to 9 W (tlp also installed and running).

Thanks to Tim for his tweak!!!!

I hope the Ubuntu guys can use this to apply a permanent solution for the next release.

Vladimir (volnes88) wrote :

Still no fix in official repos?

Oussama Khmis (ipeculiar) wrote :

this is the only solution that worked for me:
running ubuntu 18.04 after upgrade from ubuntu gnome 16.04.5
CPU intel i7-2670QM
GPU NVidia 525M
this solution is perfect for me! no bugs no lag nothing everything is super stable!

Ryan (picklechips) wrote :

Dell XPS 15 9570 with GTX 1050ti (mobile)

None of the above solutions worked, and while at first Tims solution appeared to work, I was still using > 20w ...

I've been enjoying 18.04 otherwise but as a student often in classes without chargers, battery life is too important to me. I'll be reverting back to 16.04 - looking forward for this issue to be fixed.

Is there a way to subscribe to this bug? I'd like to get back on to 18.04 as soon as this is fixed.

Changed in nvidia-prime (Ubuntu):
status: Confirmed → Opinion
status: Opinion → Confirmed

Hi Ryan, my solution uses bbswitch to turn off the card, which is what Ubuntu used before 18.04. If it works for your hardware in 16.04 (up to and including 17.10) it will work in 18.04. Also if it was working and then stopped working, it must be something you did.

If you'd like support with it, please post an issue on the github repo. Note that the readme has debugging steps. It doesn't actually do very much, so there is not much than can go wrong.

Ryan (picklechips) wrote :

Hey Tim! Not sure what was going on before (Mind must have been hazy after a full day of trying to fix this) but it actually is working now.

I went from >20W to 8.5W, and my battery life went from ~6 hours to ~11.5 hours. Really a dramatic difference and now I'm getting the battery life that was advertised with my laptop. Finally can leave my charger at home!

Thanks a ton - hopefully this can be be used to help fix the package somehow.

AaronMa (mapengyu) wrote :

This issue should be fixed by the bug:

Please test the proposed packages or wait for the release channel.

Dan Robinson (dlrobinson) wrote :

This is affecting me with nvidia-prime 0.8.10 on Cosmic. Is that relevant here or should I report a new bug?

Michael Weimann (m982) wrote :

This still happens after the 18.04.2 update.
My card is a MX150.

I have to power off the card by bbswitch every time I boot my laptop.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.