Bug 86503

Summary:	Discrete card seems to be powered on even if reported as Off
Product:	xorg	Reporter:	Marcin Zajaczkowski <mszpak>
Component:	Driver/nouveau	Assignee:	Nouveau Project <nouveau>
Status:	RESOLVED MOVED	QA Contact:	Xorg Project Team <xorg-team>
Severity:	normal
Priority:	medium
Version:	unspecified
Hardware:	Other
OS:	All
Whiteboard:
i915 platform:		i915 features:

Description Marcin Zajaczkowski 2014-11-21 00:01:09 UTC

Following up Bug 70895.

On Fedora 21 with 3.17.3-300.fc21.x86_64 when booting with nouveau.runpm=0 I have both cards on:
$ $ sudo cat /sys/kernel/debug/vgaswitcheroo/switch
0:IGD:+:Pwr:0000:00:02.0
1:DIS: :Pwr:0000:01:00.0

and after:
# echo OFF > /sys/kernel/debug/vgaswitcheroo/switch

I have:
0:IGD:+:Pwr:0000:00:02.0
1:DIS: :Off:0000:01:00.0

Looks ok, but I still see 3 providers:
$ xrandr --listproviders
Providers: number : 3
Provider 0: id: 0x90 cap: 0xb, Source Output, Sink Output, Sink Offload crtcs: 3 outputs: 5 associated providers: 2 name:Intel
Provider 1: id: 0x63 cap: 0x7, Source Output, Sink Output, Source Offload crtcs: 2 outputs: 2 associated providers: 2 name:nouveau
Provider 2: id: 0x63 cap: 0x7, Source Output, Sink Output, Source Offload crtcs: 2 outputs: 2 associated providers: 2 name:nouveau

and system temperature could suggest that the card is still on.

When I use (on the second kernel) bbswitch with bumblebee I see only one provider and the temperature is a few (~6) degrees lower.

I see no messages from VGA switcheroo in the system log (as there were in 3.11.6). Can I make output more verbose or do something else to provide more details about the situation?


System specification:
Asus N43SN
GeForce GT 550M + integrated Intel card using i915 driver (NVidia Optimus)
kernel-3.17.3-300.fc21.x86_64
xorg-x11-drv-nouveau-1.0.11-1.fc21.x86_64
xorg-x11-server-Xorg-1.16.1-1.fc21.x86_64

Btw, on that system there is also problem with auto-suspending (with not disabled nouveau.runpm) - a card is always in DynPwr - Bug 70875.

Comment 1 fredgib 2018-07-25 19:15:31 UTC

I have the same problem but found a workaround that may give a hint to developers.

My system is an up-to-date Kali Linux (kernel 4.16, nouveau package: 'xserver-xorg-video-nouveau/kali-rolling,now 1:1.0.15-2 amd64'). I don't have bumblebee or prime installed.

If I don't blacklist nouveau in /etc/modprobe.d/, there are 2 possibilities:
- either I disable runtime management in the kernel options of /etc/default/grub, then the discrete card will be on (vgaswitcheroo would say 'Pwr') and I can turn it off by writing in vgaswitcheroo/switch.
- or I don't disable runtime management, then vgaswitcheroo indicates "DynPwr" and whatever I do, I cannot change that state.

In both cases, the power consumption remains the same, typical of when the discrete card is on.

Now my preferred scenario, explaining the workaround:

If I blacklist nouveau in /etc/modprobe.d/ and reboot, I still have a high consumption, typical of when the discrete card is on. I have only one provider indicated by xrandr (the integrated i915 in modesetting) and /sys/kernel/debug/vgaswitcheroo/switch does not exist. THEN I launch nouveau ("sudo modprobe nouveau") and that's it: my consumption is 5 Watts less (typical of what I had with bumblebee and bbswitch before), vgaswitcheroo indicates "DynOff".

There is however a limitation: if I connect an HDMI screen (knowing the HDMI port of my laptop is fostered by the discrete card) and use it with 'xrandr --setprovideroutputsource 1 0', nouveau will automatically turn on the discrete card (and switcheroo will indicate "DynPwr"), but there is no return; the discrete card will remain ON, whatever I do (I even tried to 'sudo modprobe bbswitch' at that point and write "OFF" in /proc/acpi/bbswitch).

Comment 2 Martin Peres 2019-12-04 08:52:17 UTC

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-nouveau/issues/152.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.