Bug 70875 - [NVC1] runtime pm not auto-suspending card
Summary: [NVC1] runtime pm not auto-suspending card
Status: NEW
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/nouveau (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium major
Assignee: Nouveau Project
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-10-25 21:10 UTC by Marcin Zajaczkowski
Modified: 2015-10-22 04:47 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
/var/log/messages (a part) (5.18 KB, text/plain)
2013-10-25 21:10 UTC, Marcin Zajaczkowski
no flags Details
Xorg log (7.73 KB, text/plain)
2013-10-25 21:11 UTC, Marcin Zajaczkowski
no flags Details
Used xorg.conf provided by bumblebee (513 bytes, text/plain)
2013-10-25 21:12 UTC, Marcin Zajaczkowski
no flags Details
vgaswitcheroo without bumblebee (10.18 KB, text/plain)
2013-10-26 14:45 UTC, Marcin Zajaczkowski
no flags Details
Xorg log with descete card forced to use by switcheroo (32.95 KB, text/plain)
2013-10-26 14:47 UTC, Marcin Zajaczkowski
no flags Details
system log when switching cards with switcheroo (black screens) (17.83 KB, text/plain)
2013-10-26 14:50 UTC, Marcin Zajaczkowski
no flags Details
Xorg.0.log-3.13-rc1-without-bbswitch (49.76 KB, text/plain)
2013-11-30 00:01 UTC, Marcin Zajaczkowski
no flags Details
xrandr-q-3.13-rc1-without-bbswitch (1.50 KB, text/plain)
2013-11-30 00:01 UTC, Marcin Zajaczkowski
no flags Details
dmesg-3.13-rc1-without-bbswitch (81.29 KB, text/plain)
2013-11-30 00:02 UTC, Marcin Zajaczkowski
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Marcin Zajaczkowski 2013-10-25 21:10:53 UTC
Created attachment 88126 [details]
/var/log/messages (a part)

I'm unable to run X server with nouveau dirver.

[   480.562] (II) [drm] nouveau interface version: 1.1.1
[   480.562] (II) Loading sub module "dri2"
[   480.562] (II) LoadModule: "dri2"
[   480.562] (II) Module "dri2" already built-in
[   480.615] (EE) NOUVEAU(0): [drm] failed to set drm interface version.
[   480.615] (EE) NOUVEAU(0): [drm] error opening the drm
[   480.615] (EE) NOUVEAU(0): 835: 
[   480.615] (II) UnloadModule: "nouveau"
[   480.615] (EE) Screen(s) found, but none have a usable configuration.

System specification:
Asus N43SN
GeForce GT 550M + integrated Intel card using i915 driver (NVidia Optimus)
kernel-3.11.6-200.fc19.x86_64
xorg-x11-drv-nouveau-1.0.9-1.fc19.x86_64
xorg-x11-server-Xorg-1.14.3-1.fc19.x86_64

$ /sbin/lspci | egrep 'VGA'
00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09)
01:00.0 VGA compatible controller: NVIDIA Corporation GF108M [GeForce GT 550M] (rev a1)

X server works fine with the intel driver. A try to run it with NVidia card and the nouveau driver (using bumblebee bumblebee-3.2.1) causes mentioned error.

A comment in Fedora issue tracker suggests it is an issue with the nouveau driver and newer kernels, but I wasn't able to find a confirmation in other sources.
https://bugzilla.redhat.com/show_bug.cgi?id=964012#c13

Atached more detailed logs. I can provide more detailed information if needed.
Comment 1 Marcin Zajaczkowski 2013-10-25 21:11:24 UTC
Created attachment 88127 [details]
Xorg log
Comment 2 Marcin Zajaczkowski 2013-10-25 21:12:01 UTC
Created attachment 88128 [details]
Used xorg.conf provided by bumblebee
Comment 3 Ilia Mirkin 2013-10-25 21:22:57 UTC
Does this work without bumblebee (which I don't think was ever supported, as it's not part of the upstream kernel)? If so, report an issue to bumblebee? As of 3.12, you should also have runtime PM for nouveau, which should remove any need for using bumblebee.

Is this a hardware mux setup, or a more common "optimus" configuration (see http://nouveau.freedesktop.org/wiki/Optimus/ for a description of the issues).

Did this system work in some previous configuration, or is this the first time you're setting it up?
Comment 4 Marcin Zajaczkowski 2013-10-26 14:41:22 UTC
Thanks for your reply!

This is the first time I try bumblebee mostly to disabled NVidia card to increase a battery work time.

It seems I can have a hardware mux.

$ xrandr --listproviders
Providers: number : 3
Provider 0: id: 0x8e cap: 0xb, Source Output, Sink Output, Sink Offload crtcs: 2 outputs: 4 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
(I don't know why NVidia card is listed twice)

and was able to start glxinfo with both card using Prime as described here:
http://nouveau.freedesktop.org/wiki/Optimus/#usingoptimusprime


A system log section before I installed bumblebee (more complete log attached):
kernel: [    1.703270] VGA switcheroo: detected Optimus DSM method \_SB_.PCI0.PEGR.GFX0 handle
kernel: [    1.703288] nouveau 0000:01:00.0: enabling device (0004 -> 0007)
kernel: [    1.739039] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
kernel: [    1.739040] [drm] Driver supports precise vblank timestamp query.
(...)
kernel: [    2.143215] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0
(...)
kernel: [    2.642413] vga_switcheroo: enabled
(...)
kernel: [    2.756832] [drm] Initialized nouveau 1.1.1 20120801 for 0000:01:00.0 on minor 1

*With* bumblebee I have later also:
kernel: [    5.951667] bbswitch: module verification failed: signature and/or required key missing - tainting kernel
kernel: [    5.952491] bbswitch: version 0.7
kernel: [    5.952499] bbswitch: Found integrated VGA device 0000:00:02.0: \_SB_.PCI0.GFX0
kernel: [    5.952505] bbswitch: Found discrete VGA device 0000:01:00.0: \_SB_.PCI0.PEGR.GFX0
kernel: [    5.952518] ACPI Warning: \_SB_.PCI0.PEGR.GFX0._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20130517/nsarguments-95)
kernel: [    5.952645] bbswitch: detected an Optimus _DSM function
kernel: [    5.952655] bbswitch: Succesfully loaded. Discrete card 0000:01:00.0 is on
kernel: [    5.984317] [TTM] Finalizing pool allocator
kernel: [    5.984324] [TTM] Finalizing DMA pool allocator
kernel: [    5.984564] [TTM] Zone  kernel: Used memory at exit: 0 kiB
kernel: [    5.984569] [TTM] Zone   dma32: Used memory at exit: 0 kiB
kernel: [    5.984572] vga_switcheroo: disabled
kernel: [    5.986835] [drm] Module unloaded
kernel: [    5.987886] bbswitch: disabling discrete graphics
kernel: [    5.987897] ACPI Warning: \_SB_.PCI0.PEGR.GFX0._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20130517/nsarguments-95)
kernel: [    5.998773] pci 0000:01:00.0: Refused to change power state, currently in D0

and:
xrandr --listproviders
Providers: number : 1
Provider 0: id: 0x45 cap: 0xb, Source Output, Sink Output, Sink Offload crtcs: 2 outputs: 4 associated providers: 0 name:Intel
(which is fine if I just want to have NVidia card disabled to increase battery work time)


I also tried to use switcheroo to force X server to use discrete graphics after X restart using instructions from:
https://fedoraproject.org/wiki/QA:Testcase_vga_switcheroo
but I ended with black both screens (even switching to a text console was not visible - an external monitor had not imput signal).

kernel: [ 1321.653945] vga_switcheroo: client 1 refused switch
kernel: [ 1321.653950] vga_switcheroo: setting delayed switch to client 1
(... - X restart)
kernel: [ 1360.615922] vga_switcheroo: processing delayed switch to 1
kernel: [ 1360.615931] vga_switcheroo: client 1 refused switch
kernel: [ 1360.616169] vga_switcheroo: processing delayed switch to 1
kernel: [ 1360.764972] fbcon: Remapping primary device, fb0, to tty 1-63
kernel: [ 1360.854562] i915: switched off

A complete log from that time period attached.

After a restart I checked old Xorg log (attached) and it seems that X server was able to start with nouveau driver without mentioned drm error.

In that case maybe you have a suspicion what can cause a mentioned "[drm] failed to set drm interface version" when using bumblebee?

The second question could be - Why did I end with black screens after that operation?
Comment 5 Marcin Zajaczkowski 2013-10-26 14:45:36 UTC
Created attachment 88151 [details]
vgaswitcheroo without bumblebee
Comment 6 Marcin Zajaczkowski 2013-10-26 14:47:14 UTC
Created attachment 88152 [details]
Xorg log with descete card forced to use by switcheroo
Comment 7 Marcin Zajaczkowski 2013-10-26 14:50:12 UTC
Created attachment 88153 [details]
system log when switching cards with switcheroo (black screens)
Comment 8 Ilia Mirkin 2013-11-26 05:59:28 UTC
I don't see anything that suggests that you have a hardware mux. The VGA/DVI connectors appear to be on the nvidia card -- they're inaccessible from intel, right? (A bit hard to tell from your logs...)

So... please try the following:

linux 3.13-rc1 -- this has some fixes for nvc1 as well as runtime pm.

don't touch bumblebee
don't touch vga_switcheroo

The nvidia card should automatically suspend when you're not using its VGA/DVI outputs (and not using it for 3d rendering).

If you now run

xrandr --setprovideroutputsource nouveau Intel

you should be able to use your intel card to show images on the nvidia-connected screens. (You can also reverse this logic to use the nvidia card as the 'main' card.)
Comment 9 Marcin Zajaczkowski 2013-11-26 10:07:07 UTC
(In reply to comment #8)
> I don't see anything that suggests that you have a hardware mux. The VGA/DVI
> connectors appear to be on the nvidia card -- they're inaccessible from
> intel, right? (A bit hard to tell from your logs...)

Hmm, I thought I have one (or maybe I don't understand a problem :) ). Currently with bumblebee I have NVidia card off and still can use both screen (though VGA or HDMI output).

$ cat /proc/acpi/bbswitch
0000:01:00.0 OFF
$ lsmod | grep nouveau
$ lsmod | grep nv

> So... please try the following:
> 
> linux 3.13-rc1 -- this has some fixes for nvc1 as well as runtime pm.

Ok, I will try to get this kernel and let you know.
Comment 10 Ilia Mirkin 2013-11-26 18:44:05 UTC
(In reply to comment #9)
> (In reply to comment #8)
> > I don't see anything that suggests that you have a hardware mux. The VGA/DVI
> > connectors appear to be on the nvidia card -- they're inaccessible from
> > intel, right? (A bit hard to tell from your logs...)
> 
> Hmm, I thought I have one (or maybe I don't understand a problem :) ).
> Currently with bumblebee I have NVidia card off and still can use both
> screen (though VGA or HDMI output).

Oh, if you can get to all your outputs from the intel card, but can also get them from the nvidia card, then you do have a hardware mux. My bad. But I think you can still use the xrandr offload stuff in that case, as shown on http://nouveau.freedesktop.org/wiki/Optimus/. In the end, what are you looking for from your nvidia card? If it's the occasional 3d game/whatever, you can use DRI_PRIME=1 for that, at which point it should turn on and then turn back off when you're done due to runtime pm. [Make sure that your kernel is configured with CONFIG_RUNTIME_PM.]
Comment 11 Marcin Zajaczkowski 2013-11-28 21:00:31 UTC
> But I think you can still use the xrandr offload stuff in that case, as shown
> on http://nouveau.freedesktop.org/wiki/Optimus/. In the end, what are you
> looking for from your nvidia card? If it's the occasional 3d game/whatever,
> you can use DRI_PRIME=1 for that, at which point it should turn on and then
> turn back off when you're done due to runtime pm. [Make sure that your
> kernel is configured with CONFIG_RUNTIME_PM.]

You are right. DRI_PRIME=1 works fine on my hardware. If CONFIG_RUNTIME_PM would turn off my NVidia card when not used it would enough. I haven't found RPMS for 3.13-rc1 for Fedora, so probably I would need to refresh my knowledge about kernel building (I haven't been doing it for years :) ).

Thanks for your support.
Comment 12 Marcin Zajaczkowski 2013-11-29 23:23:57 UTC
I managed to build and install 3.13-rc1 with CONFIG_PM_RUNTIME on my Fedora, but I have two issues.

1. I can't determine if NVidia card is disabled when become not used (basing on a system temperature it's not). vga_switchero always returns DynPwr - can vgaswitcheroo be more verbose?

$ sudo cat /sys/kernel/debug/vgaswitcheroo/switch
0:IGD:+:Pwr:0000:00:02.0
1:DIS: :DynPwr:0000:01:00.0

I need to build and install patched for 3.13 bbswitch version which shows:
$ cat /proc/acpi/bbswitch
0000:01:00.0 ON

and I cannot disable it using bbswitch.
bbswitch: device 0000:01:00.0 is in use by driver 'nouveau', refusing OFF

I also cannot unload nouveau driver. There is nothing more in the kernel log.

2. I tried to boot with bbswitch (then vgaswitcheroo become disabled) and a discrete is turn off. Unfortunately and cannot tell Prime to use it for offloading because xrandr --listproviders returns only Intel card. Even when I manually enable discrete card and later load nouveau driver xrandr returns the second card with modesetting instead of nouveau (can I do something in that case?)
Comment 13 Ilia Mirkin 2013-11-29 23:32:27 UTC
Without bbswitch, just 3.13-rc1 (or rc2 if you prefer), can you provide your dmesg and Xorg.0.log and xrandr -q outputs?
Comment 14 Marcin Zajaczkowski 2013-11-30 00:01:17 UTC
Created attachment 90007 [details]
Xorg.0.log-3.13-rc1-without-bbswitch
Comment 15 Marcin Zajaczkowski 2013-11-30 00:01:43 UTC
Created attachment 90008 [details]
xrandr-q-3.13-rc1-without-bbswitch
Comment 16 Marcin Zajaczkowski 2013-11-30 00:02:04 UTC
Created attachment 90009 [details]
dmesg-3.13-rc1-without-bbswitch
Comment 17 Marcin Zajaczkowski 2013-11-30 00:05:21 UTC
Attached.

Besides a possible deadlock I wonder what is it?
> VGA-2 connected (normal left inverted right x axis y axis)
>   1024x768 

I have only a laptop display and and external monitor (VGA-1).
Comment 18 Ilia Mirkin 2013-11-30 00:48:49 UTC
Well, I have no clue why runpm isn't triggering. I think Dave Airlie was going to make a "why is my card not suspending" diagnostic of some sort. I'm guessing it has something to do with that phantom VGA-2, perhaps you're getting interrupts/whatever as a result.

To go back to the old way, I think adding nouveau.runpm=0 to the kernel command line should let you use vgaswitcheroo/bbswitch the same way you did before.
Comment 19 Ilia Mirkin 2015-10-22 04:47:56 UTC
There were a lot of fixes to runpm that happened after 3.13-rc. Please retest with a fresh kernel.

If the issue with the phantom VGA-2 connector persists, try disabling it (e.g. boot with video=VGA-2:d).


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.