Bug 86503 - Discrete card seems to be powered on even if reported as Off
Summary: Discrete card seems to be powered on even if reported as Off
Status: RESOLVED MOVED
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/nouveau (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Nouveau Project
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-11-21 00:01 UTC by Marcin Zajaczkowski
Modified: 2019-12-04 08:52 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments

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.