prime-select intel is not powering off the nvidia card

Bug #1765363 reported by Tim Richardson
456
This bug affects 91 people
Affects Status Importance Assigned to Milestone
nvidia-prime (Ubuntu)
Undecided
Unassigned

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
Dependencies:

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)

Revision history for this message
Tim Richardson (tim-richardson) wrote :
Revision history for this message
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

Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in nvidia-prime (Ubuntu):
status: New → Confirmed
Revision history for this message
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.

Revision history for this message
Giraffe (dodger-forum) wrote :

Running Xubuntu 18.04 by the way.

Revision history for this message
Francois Thirioux (fthx) wrote :

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

I found that the file :
/etc/modprobe.d/blacklist-nvidia.conf
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 "nouveau.run-pm=0" (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.

Revision history for this message
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 "nouveau.run-pm=0" 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.

Revision history for this message
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.

Revision history for this message
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
0:IGD:+:Pwr:0000:00:02.0
1:DIS: :Off:0000:01:00.0

Revision history for this message
Alberto Milone (albertomilone) wrote :

Great, thanks for testing!

Revision history for this message
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.
See: https://bugs.freedesktop.org/show_bug.cgi?id=100228
(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.

Revision history for this message
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 nouveau.run-pm=0 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 nouveau.run-pm=0 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
0:IGD:+:Pwr:0000:00:02.0
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.

Revision history for this message
Francois Thirioux (fthx) wrote :

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

Revision history for this message
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.

Revision history for this message
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 https://nouveau.freedesktop.org/wiki/KernelModuleParameters/).
# 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.

Revision history for this message
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: https://bugs.freedesktop.org/show_bug.cgi?id=100228

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.

Revision history for this message
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.

Revision history for this message
Beavis (gordian-dziwis) wrote :

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

Revision history for this message
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.

Revision history for this message
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.

Revision history for this message
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.

Revision history for this message
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 https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-390/+bug/1752053 ir seems that 18.04 indeed broke all Nvidia dual laptops.

Revision history for this message
Артем (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:
0:IGD:+:Pwr:0000:00:02.0
1:DIS: :DynOff:0000:01:00.0

nvidia 390.48, after prime-select intel:
0:IGD:+:Pwr:0000:00:02.0
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.

Revision history for this message
Артем (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:
0:IGD:+:Pwr:0000:00:02.0
1:DIS: :DynOff:0000:01:00.0

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

Revision history for this message
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

0:IGD:+:Pwr:0000:00:02.0
1:DIS: :DynOff:0000:01:00.0

Revision history for this message
Mar-castelluccio (mar-castelluccio) wrote :

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

Revision history for this message
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?

Revision history for this message
Giraffe (dodger-forum) wrote :

To manually disable you discrete graphics card:
sudo systemctl disable nvidia-fallback
sudo -s
root@system:
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.

Revision history for this message
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.

Revision history for this message
Stefan Girstmair (djefo) wrote :

@Noam Mor:

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

Revision history for this message
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.

Revision history for this message
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.

Revision history for this message
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.

Revision history for this message
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.

Revision history for this message
Beavis (gordian-dziwis) wrote :

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

Revision history for this message
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
RUNTIME_PM_DRIVER_BLACKLIST=""
as TLP config file's comments warn us about this trick.

Revision history for this message
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 http://kernel.ubuntu.com/~kernel-ppa/mainline/.
See this PR: https://lkml.org/lkml/2018/5/18/159

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.

Revision history for this message
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:
https://bugs.freedesktop.org/show_bug.cgi?id=101665
https://bugs.freedesktop.org/show_bug.cgi?id=100228

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

Revision history for this message
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:
https://github.com/matthieugras/Prime-Ubuntu-18.04

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.

Revision history for this message
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.

Revision history for this message
Tim Richardson (tim-richardson) wrote :

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.

Revision history for this message
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)

Revision history for this message
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

bbswitch

(no load_state=0)

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

write

options bbswitch load_state=0

and save and quit.

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

Revision history for this message
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.

Revision history for this message
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?

Revision history for this message
Tim Richardson (tim-richardson) wrote :

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

https://github.com/timrichardson/Prime-Ubuntu-18.04

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.

Revision history for this message
Leonardo (rnalrd) wrote :

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

<pre>
~$ 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.
</pre>

<pre>
~$ 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
0:IGD:+:Pwr:0000:00:02.0
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

</pre>

Revision history for this message
Diego (panopliaespartana) wrote :

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

Revision history for this message
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 nouveau.run-pm=0 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.

Revision history for this message
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.

Revision history for this message
Vladimir (volnes88) wrote :

Still no fix in official repos?

Revision history for this message
Oussama Khmis (ipeculiar) wrote :

this is the only solution that worked for me: https://goo.gl/vivchV
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!

Revision history for this message
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
Revision history for this message
Tim Richardson (tim-richardson) wrote :

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.

Revision history for this message
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.

Revision history for this message
AaronMa (mapengyu) wrote :

This issue should be fixed by the bug:

https://bugs.launchpad.net/ubuntu/+source/nvidia-prime/+bug/1778011

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

Revision history for this message
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?

Revision history for this message
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.

Revision history for this message
Leonardo (lbrito) wrote :

Same issue for me.

Ubuntu 18.04, lightdm
MSI GS65 Stealth, Geforce GTX 1660 Ti

Revision history for this message
Michal Malaník (michal2727) wrote :

Same issue for me. Nvidia is not powered off in intel mode. Cause massive battery drain, powertop shows value between 30-40 W.

Ubuntu 18.04.3, gdm3
MSI GS65 Stealth, Nvidia GTX 1070 MaxQ
nvidia-prime version 0.8.8.2

Its strange that nvidia powering off in intel mode worked before on 18.04. Then I used nvidia mode for two months. Now I want to switch back to intel mode but its not working anymore. Unfortunately I don't know which update caused this, because I used nvidia mode for some time.

Does this issue already have some official solution, or I have to use bbswitch? The manual bbswitch solution works for me, but I don't like it.

Some notes:
I tried to install nvidia driver 390, nvidia driver 430 and nvidia driver 435 from ppa and also from repository. Nvidia is not powering off in intel mode with any of them.

When system booted in intel mode the /sys/kernel/debug/vgaswitcheroo directory doens't even exist...

Revision history for this message
Vicente R (vicenter) wrote :

Same issue for me. Power consumption ~10W higher than normal on intel mode since some update around that happened around this past month. Previously had to use the command echo 'auto' > '/sys/bus/pci/devices/0000:01:00.0/power/control' (from powertop's tunables) to shut down the dGPU but otherwise worked fine.

Ubuntu 18.04.3, sddm
Legion Y530, Nvidia GTX 1050M
Tested on kernel 5.3 and nvidia 430.50 and on a fresh installation with default kernel and nvidia drivers

Revision history for this message
sagar rathi` (blastofftopluto) wrote :

Same issue for me. Power consumption ~10W higher than normal on intel mode.

Linux Mint 19.3 Cinnamon
Dell 7577
NVIDIA Corporation GP106M [GeForce GTX 1060 Mobile]
Kernel: 5.0.0-37-generic

Can anyone help me turn of dGpu...

Revision history for this message
fred (fred-freemantle) wrote :

Same issue for me

Ubuntu 19.04
MSI Q60 - Ghost
GeForce GTX 1060 Mobile
Intel GPU

Revision history for this message
Naveen Venkat (naveenvenkat) wrote :

Same issue for me as well.

Although, I found that the standard-deviation in powerstat reduced when running on intel under consistent settings (1 chrome tab running YouTube). NVIDIA (av: 33.76 Watts, std: 11.07) and INTEL (av: 31.60 Watts, std: 2.36).

--

Ubuntu 18.04

MSI GE62VR 7RF - Apache Pro (https://www.msi.com/Laptop/GE62VR-7RF-Apache-Pro/Specification)

GeForce GTX 1060 Mobile

Intel core i7 7700HQ

Revision history for this message
Alexey_C (alexey-acv) wrote :

Hi.
I have this problem on Lenovo S540 and Ubuntu 18.04LTS
After reboot bbswitch is ON

But i look this situation:

file /etc/systemd/system/nvidia-prime-boot-service contains call /usr/local/bin/turnoff_nvidia_at_boot, where last command change bbswitch to OFF

#!/bin/sh
rmmod nouveau
rmmod nvidia_drm
rmmod nvidia_modeset
rmmod nvidia_uvm
rmmod nvidia
modprobe bbswitch
echo "OFF" > /proc/acpi/bbswitch

Bingo? No...

After automatically run nvidia-prime-boot-service as a service, switch stay is ON and NVidia powered.

Okay, i run nvidia-prime-boot manually...

$ sudo tlp-stat -b | grep power_now
/sys/class/power_supply/BAT0/power_now = 18832 [mW]

$ sudo systemctl start nvidia-prime-boot

$ sudo tlp-stat -b | grep power_now
/sys/class/power_supply/BAT0/power_now = 5041 [mW]

Nvidia power is OFF.
Bingo is here? No..

It's unpleasant when to have everything, but it's not working properly.
I guess we can run bbswitch OFF later and it will work.
So far, there's only hope for cron.

Revision history for this message
Alexey_C (alexey-acv) wrote :

Yes. I win.
I install new systemd service with timer for power off NVidia after startup.

Problem:
New laptop Lenovo S540 (2020-made) + Ubuntu 18.04 LTS with NVidia 435 driver eats battery for 2-3 hours.

Result:
12 hours on battery.

Before that the actions from comment #43 have been taken (thank, tom (tombuntus))
(I don't install nvidia-prime. I use nvidia-prime, installed with nvidia-driver-435)

$sudo apt install bbswitch-dkms

add "bbswitch" to /etc/modules

add "options bbswitch load_state=0" to /etc/modprobe.d/bbswitch.conf

And i have don't change kernel parameter nouveau.modeset

Steps for make service:

1 - create file /ets/systemd/system/nvidia-off.service
##########################
[Unit]
Description=OFF unused NVidia chip (20W->5W)

[Service]
Type=simple
ExecStart=/usr/local/bin/nvidia-off-on-start

[Install]
WantedBy=multi-user.target
##########################

2 - create file /ets/systemd/system/nvidia-off.timer
##########################
[Unit]
Description=OFF unused NVidia chip (20W->5W)

[Timer]
OnStartupSec=1min

[Install]
WantedBy=multi-user.target
##########################

3 - create executable file /usr/local/bin/nvidia-off-on-start
##########################
#!/bin/sh
modprobe bbswitch
echo "OFF" > /proc/acpi/bbswitch
date >> nvidia-off-on-start.log
cat /proc/acpi/bbswith >> nvidia-off-on-start.log
#########################

4 - enable and start service
$systemctl enable nvidia-off.timer
$systemctl status nvidia-off.timer

RESULT:

- Power of NVidia adapter stay OFF after reboot and login to any user.
- $ sudo tlp-stat -b | grep power_now
   shows 4000-6000 milliWatts
- On-Battery time is up to 10-12 hours
- Bonus: all coolers stay off.

If i select NVidia in Prime-Select (GUI) and reboot, execute "echo "OFF" > /proc/acpi/bbswitch" no have "off" effect and NVidia ready for gaming.

Revision history for this message
Richard Veale (richard-e-veale) wrote :

This problem affects ubuntu 20.04 as well. Ubuntu MATE 20.04 on an razer blade stealth (2019) laptop with nvidia MX150.

The solution posted by Alexy_C works (powers off nvidia card, i.e. lspci reports (ff) rather than (a1))

Otherwise, even in intel mode, the card reports being powered on (a1).

Under normal default install (ubuntu MATE) in powertop, if I enable runtime-pm for the nvidia card, it will lower the consumed power, but the card will remain powered on (a1) albeit ostensibly in some low-power state.

Revision history for this message
Richard Veale (richard-e-veale) wrote :

This affects Ubuntu MATE 20.04 as well. The solution posted by Alexey_C (alexey-acv) works to appropriately poweroff the nvidia card (state ff) and lowers consumed power to about 6W).

Note laptop model is razer blade stealth 2019, with nvidia MX150.

By default, even in nvidia-prime intel mode, the nvidia card remains powered on (lspci reports (a1) rather than (ff) as expected for powered off state).

Enabling "runtime PM for nvidia card" in powertop does lower the consumed power (from 11W to 6W) however lspci reports the card is still powered on (a1), ostensibly in some low-power state.

Revision history for this message
Richard Veale (richard-e-veale) wrote :

I will report that I also tried in 20.04 -- Kubuntu, Ubuntu (GNOME), and XFCE (as well as my main system MATE) and can report the same behavior (no poweroff of nvidia card by default even in intel mode).

Revision history for this message
Vasyl (exposight) wrote :

I confirm the issue on Ubuntu 18.04 base with kernel 4.15.0-88, NVidia drivers 435.21 and 440.59 make no difference in the behavior. After 'prime-select intel' the nvidia driver is not loaded at all and intel graphcs are active, but according to PowerTop the NVIDIA chip still consumes the power. Acer laptop, NVidia 1050 Ti, Intel i5-7300HQ.

(TLDR: see SOLUTION at the end of the comment!)

Good thing is: as reported in comment #61 above by Vincente, command from PowerTop Tunables tab (Runtime PM for PCI device NVIDIA Corporation GP107M) actually helps to power off the NVidia chip and power consumption goes down by a ~10W. Unfortunately, that does not persist after system restart.

After checking the relevant NVidia driver manual http://us.download.nvidia.com/XFree86/Linux-x86_64/440.59/README/dynamicpowermanagement.html I have found that same command to enable the runtime power management which PowerTop uses:
 echo auto > /sys/bus/pci/devices/0000\:01\:00.0/power/control
or a variant with proper privileges:
 sudo sh -c 'echo auto > /sys/bus/pci/devices/0000:01:00.0/power/control'
That does the trick as well, so PowerTop is not needed to enable it.

GREAT THING AND THE SOLUTION: after reading the 'Automated Setup' section in the nvidia manual above, I have found a way to automate that. No bbswitch, no tlp tools, no extra scripts/services! Just create a file named 80-nvidia-poweroff.rules in /lib/udev/rules.d/ directory with the following content:

# Enable runtime PM for NVIDIA VGA/3D controller devices by default (if the driver is not / will not be bound)
ACTION=="add", SUBSYSTEM=="pci", ATTR{vendor}=="0x10de", ATTR{class}=="0x030000", DRIVER=="", TEST=="power/control", ATTR{power/control}="auto"
ACTION=="add", SUBSYSTEM=="pci", ATTR{vendor}=="0x10de", ATTR{class}=="0x030200", DRIVER=="", TEST=="power/control", ATTR{power/control}="auto"

Save and reboot the system. Done! The nvidia chip will be in power off mode already when you open the PowerTop to check that. And that will work only when the intel is selected as an active controller by prime-select tool, so should be safe when nvidia is set as active instead.

P.S. I wish this to be done automatically when installing the nvidia driver... No magic for installer to create that file.

Revision history for this message
Tim Richardson (tim-richardson) wrote :

@vasyl: thanks, good comment. It pays to RTFM, apparently.

Revision history for this message
Richard Veale (richard-e-veale) wrote :

@vasyl: I want to add to your comment.

I am in 20.04 now but until last week was using 18.04 with the same problem. If you use the method you reported (activate runtime PM for nvidia chip) power usage is still higher than if the chip is powered off totally using bbswitch.

Runtime PM enabled, PRIME @ intel mode: 7.5~8.5 W power usage
bbswitch nvidia off method, PRIME @ intel mode: 6.0~7.0 W power usage

I think that maybe the PM method puts the nvidia chip in a "low power" mode (maybe level 8? level 12?) which does reduce power draw but still keeps it at 1 or 2 watts. Whereas switching it off entirely makes power draw minimal.

This is just based on a few days of realtime observations on my part, however.

Revision history for this message
Sebastien Bacher (seb128) wrote :

The bug is old and is getting a bit confusing, those still having issue on focal could you rather open a new report explaining clearly what you do, what you would expect and what happens instead? that should make easier to review the current status

Revision history for this message
Alberto Milone (albertomilone) wrote :

I am pretty sure I fixed this in Ubuntu 19.10. If you use 20.04, you shouldn't need bbswitch or any other tweaks.

Revision history for this message
Vasyl (exposight) wrote :

Hi Alberto, thank you for the reply! It motivated me to recheck the history of the changes for 'nvidia-prime' package.

On Ubuntu 18.04 the last released nvidia-prime package version is 0.8.8.2, it includes fixes for related bugs:
  https://bugs.launchpad.net/ubuntu/+source/nvidia-prime/+bug/1778011
  https://bugs.launchpad.net/ubuntu/+source/nvidia-prime/+bug/1797147
But the issue is still reproducible: NVIDIA GPU default power control mode is "on" in intel mode and PowerTop reports the chip as consuming energy.

By checking version history I did found you have made very similar fixes by udev rules in version 0.8.13, that looks as an even more extensive fix (NVIDIA GPU is not enabled completely instead of tweaking its power mode). Agree with you that users of Ubuntu 19.10 and newer should recheck whether the package version is at least 0.8.13.

Users of Ubuntu (18.04 18.10 19.04) versions are affected since the package is older for those distributions. Hope this info helps for others.

Revision history for this message
Mateusz Litwin (matlit) wrote :

I also have this bug. It seems that problem is on Ubuntu installer please check that comment:
https://bugs.launchpad.net/ubuntu/+source/nvidia-prime/+bug/1877727/comments/7

I reinstall Ubuntu and NOT checked to install proprietary driver. After Ubuntu install, I install Nvidia driver via the Additional Drivers application. After reboot, change graphic card to Intel and next reboot everything works great.

Revision history for this message
Alexey_C (alexey-acv) wrote :

Vasyl, your solution works, but it has a big disadvantage.
HDMI doesn't work.
I'm deleting the 80-nvidia-poweroff.rules file - HDMI works after rebooting.
Restore this file - HDMI is not working.

In general, there is a big problem with NVidia - all kinds of solutions to the power problem never take into account the presence of HDMI output on the NVidia chip.

In fact, the solution I gave above did not fix it too.
When I connected the HDMI monitor, I saw that the fight wasn't over.

Prime also injects a file with rules, and there is a situation where a user on a new Ubuntu installs NVidia drivers and has HDMI running, but after only one use of "prime select" he can never again turn on the HDMI monitor again until he reads the forums and deletes this file.
A particular cynicism is that the file is not deleted when drivers and prime are removed.

Unfortunately, I won't be able to name the file now, I deleted it, I also deleted all the shortcuts so that home users wouldn't be able to switch the adapter mode through the prime GUI, and I use what is configured in #66, and I switch adapters in the BIOS.
At the same time, my notebook consumes 3.5-6 watts of battery power while working for Intel, and after switching to NVidia, HDMI works.

Revision history for this message
Alexey_C (alexey-acv) wrote :

Probably the file name is /lib/udev/rules.d/50-pm-nvidia.rules

Revision history for this message
Nishan (roachx) wrote :

Prime select is not turning off the dgpu in Ubuntu 20.04

Laptop: MSI GE40
dGPU: GTX 760m
iGPU Intel HD4600

Driver: Nvidia 440 installed via "Additional Drivers" GUI from default 20.04 repos.

When using "prime-select intel" the iGPU is being used however the dGPU is still powered on resulting in considerably more power usage and heat generation.

Installing and loading the bbswitch module and running "echo "OFF">/proc/acpi/bbswitch" does successfully power down the dGPU drastically lower power usage.

Revision history for this message
Diana Shehu (roadrunner56) wrote :

I am also affected by this bug. I am on Kubuntu 20.04 on a Dell XPS L502x. When I am on my Intel card, my computer reports my consumption as around 22 W. I checked my 'nvidia-prime' package, and it is 0.8.14. According to Vasyl, the bug should be fixed in this version, but unfortunately it is not, at least not for me. Please fix this bug, as the excessive power consumption essentially renders prime-select useless.

Revision history for this message
mm79 (mm1379) wrote :

I have this problem on kubuntu 18.04 and ubuntu,kubuntu 20.04
dell inspiron 5110n
nvidia gt525m
nvidia driver-390

mm79 (mm1379)
Changed in nvidia-prime (Ubuntu):
status: Confirmed → In Progress
status: In Progress → Confirmed
Revision history for this message
Dan Robinson (dlrobinson) wrote :

Sebastien: I saw your request for a new bug report and it's 1912974.

Hope that helps clarify the issue.

Alberto: it isn't fixed.

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.