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.
Created attachment 88127 [details] Xorg log
Created attachment 88128 [details] Used xorg.conf provided by bumblebee
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?
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?
Created attachment 88151 [details] vgaswitcheroo without bumblebee
Created attachment 88152 [details] Xorg log with descete card forced to use by switcheroo
Created attachment 88153 [details] system log when switching cards with switcheroo (black screens)
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.)
(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.
(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.]
> 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.
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?)
Without bbswitch, just 3.13-rc1 (or rc2 if you prefer), can you provide your dmesg and Xorg.0.log and xrandr -q outputs?
Created attachment 90007 [details] Xorg.0.log-3.13-rc1-without-bbswitch
Created attachment 90008 [details] xrandr-q-3.13-rc1-without-bbswitch
Created attachment 90009 [details] dmesg-3.13-rc1-without-bbswitch
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).
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.
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).
-- 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/66.
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.