I have a Lenovo T430 laptop with both Intel IGD and Nvidia GF108. I've enabled Optimus in BIOS. Distro currently is Fedora 18 x86_64 with Linux kernel 3.10.4. I had the same problem with earlier kernel versions aswell. It seems the nouveau output connector names in xrandr are inconsistent and change between reboots, depending "how" the laptop is rebooted (DVI cabled plugged in or not). I'm using a Lenovo docking station, which has DVI connectors for external monitors. These DVI connectors are actually connected to the DisplayPort outputs on nouveau. Laptop is in the docking station during all these tests. If DVI cable is NOT connected to docking station at laptop boot time then nouveau outputs are called DP-1, DP-2 and DP-3 in xrandr output. This is reliable and consistent, and it's the same on every reboot without DVI cable plugged in. All fine so far. But when the DVI cable actually *is* plugged in to the dock at laptop boot time things get more weird.. During most reboots (but not all, see below) there are zero outputs reported for nouveau in xrandr! In /sys/class/drm/card*/status files I can still see correct outputs and their status, it's only xrandr that doesn't show anything for nouveau. Any ideas why this happens? Also in this case I can see some weird black/white pattern on the external DVI monitor.. even when the DVI output is not supposed to be enabled/activated.. and there's no way to actually activate it myself because xrandr doesn't show any outputs for nouveau. As mentioned above there's the more rare case aswell.. during *some* reboots with DVI cable plugged in to the dock, maybe one out of five reboots, there's no black/white pattern on the external DVI monitor, it's all black like it should be, and xrandr actually shows the nouveau output connector names! But they're called Displayport-0, DisplayPort-1 and DisplayPort-2 in xrandr output. So not DP-1, DP-2 and DP-3 like when the laptop is booted without DVI cable.. Why the difference in output names? And any guesses why on most reboots there are zero outputs detected? I can pretty reliably reproduce this and I'm willing to do more debugging as needed. also in the rare case when the outputs are called DisplayPort-0, DisplayPort-1, DisplayPort-2 in xrandr output actually enabling them crashes the kernel, but that's probably a separate issue, and I've filed a separate bug about the kernel crash: https://bugs.freedesktop.org/show_bug.cgi?id=64774 . xrandr output with *no* DVI cable connected at boot time: Screen 0: minimum 320 x 200, current 1600 x 900, maximum 8192 x 8192 LVDS1 connected 1600x900+0+0 (normal left inverted right x axis y axis) 309mm x 174mm 1600x900 60.0*+ 40.0 1024x768 60.0 800x600 60.3 56.2 640x480 59.9 VGA1 disconnected (normal left inverted right x axis y axis) LVDS-2 disconnected (normal left inverted right x axis y axis) VGA-2 disconnected (normal left inverted right x axis y axis) DP-1 disconnected (normal left inverted right x axis y axis) DP-2 disconnected (normal left inverted right x axis y axis) DP-3 disconnected (normal left inverted right x axis y axis) xrandr output with DVI cable connected at boot time (the rare case when nouveau outputs are actually detected): Screen 0: minimum 320 x 200, current 1600 x 900, maximum 8192 x 8192 LVDS1 connected 1600x900+0+0 (normal left inverted right x axis y axis) 309mm x 174mm 1600x900 60.0*+ 40.0 1024x768 60.0 800x600 60.3 56.2 640x480 59.9 VGA1 disconnected (normal left inverted right x axis y axis) LVDS-1 disconnected VGA-1 disconnected DisplayPort-0 disconnected DisplayPort-1 connected 1920x1080 59.9 + 1600x1200 60.0 1680x1050 59.9 1280x1024 60.0 1440x900 59.9 1280x960 60.0 1280x800 59.9 1024x768 60.0 800x600 60.3 56.2 640x480 60.0 DisplayPort-2 disconnected 1024x768 (0x47) 65.0MHz h: width 1024 start 1048 end 1184 total 1344 skew 0 clock 48.4KHz v: height 768 start 771 end 777 total 806 clock 60.0Hz 800x600 (0x48) 40.0MHz h: width 800 start 840 end 968 total 1056 skew 0 clock 37.9KHz v: height 600 start 601 end 605 total 628 clock 60.3Hz 800x600 (0x49) 36.0MHz h: width 800 start 824 end 896 total 1024 skew 0 clock 35.2KHz v: height 600 start 601 end 603 total 625 clock 56.2Hz
The list of connectors is supplied by KMS. For each "type" of boot (no dvi, dvi with DisplayPort, dvi with nothing), please attach a dmesg and output of "ls /sys/class/drm". Just to avoid more back and forths, please boot (each time) with nouveau.debug=PDISP=debug as that might provide some useful information.
Created attachment 84030 [details] nouveau-inconsistent-output-names-logs.tar.gz
Logs added for 3 different scenarios. Kernel booted with "nouveau.debug=PDISP=debug" in all cases. For each case there is: - kernel dmesg. - output of "xrandr" command in Xorg. - output of "ls /sys/class/drm" command. - output of "grep conn /sys/class/drm/card*/status" command.
Created attachment 84031 [details] 02-dvi_connected-xrandr_does_not_show_nouveau_outputs-corrupted_pattern_on_dvi_monitor.jpg
I also attached a screenshot of the black/white pattern on DVI monitor on the second case when the DVI cable is connected but xrandr does not show any nouveau outputs.. So the DVI monitor is not really enabled/activated, because there's no way to do it.. but some corrupted pattern is still visible there. It should be all black instead.
As far as I can see, everything's working totally fine from the kernel end. There is one difference between the two "dvi plugged in at boot" cases, in that in one, nouveau ends up as card0, in the other i915 does. All the connectors seem fine, and are properly reporting status. There's nothing funny in dmesg. So... I think we should shift our attention to X. Can you attach your Xorg.0.log for the same three cases? Although let's amend the first case ("no dvi plugged in") to "no dvi plugged in at boot, then plugged in later" (since that still functions, right).
Created attachment 84407 [details] nouveau debug Xorg logs
Xorg logs (also with dmesg and xrandr output) attached. Summary about each test-case: 01-dvi-not-connected-at-boot-but-is-connected-later: - DVI monitor is not connected to nouveau at boot time, but I connect the DVI cable later while in Xorg session. - xrandr shows nouveau outputs as DP-1, DP-2 and DP-3. - I am able to successfully enable and disable DVI monitor connected to nouveau adapter. - xrandr shows correct connected/disconnected state for the DVI output. - Graphics on the DVI monitor are corrupted, for example moving xterm around the DVI display leaves trace of the xterm contents behind, but let's not focus on that on this bug :) it kind of works. 02-dvi-connected-at-boot-no-nouveau-outputs-detected-in-xrandr: - DVI cable is connected to nouveau at boot time. - xrandr does *not* show any nouveau outputs, so it's not possible to enable/disable DVI monitor. - DVI monitor shows black/white corrupted pattern, even when it should be all empty/black in this case because it's not in use. - Screenshot of the DVI monitor included in the .tar.gz. 03-dvi-connected-at-boot-nouveau-outputs-detected-as-displayport-in-xrandr: - DVI cable is connected to nouveau at boot time. - xrandr shows nouveau outputs as DisplayPort-0, DisplayPort-1 and DisplayPort-2. - Trying to enable DVI monitor connected to nouveau results in hard kernel crash (but we have the other bug open about the kernel crash issue).
Also worth noting that in the problematic 02 and 03 test-cases there's a segfault and traceback in the Xorg.0.log .. that can't be good. Xorg is usable though..
You're using optimus and xorg 1.13. I believe that support for optimus is much improved in 1.14 -- please try upgrading and see if that alters the situation at all.
So I updated from Fedora 18 to Fedora 19, which has xorg-1.14.2, and now it looks better. I haven't seen the "changing nouveau connector names" issue anymore.. but I can't be completely certain yet, because there are other problems now with xorg 1.14 that prevent proper testing (Xorg crashes with segfault when running for example "xrandr --output DP-2 --off")..
Can you provide the segfault backtrace? Is it in nouveau code, or in xorg code? (Would be great if you could also make sure to get the segfault on binaries with debug symbols.) Are you still getting the original issue of "no outputs detected"... or whatever it was (sorry, I'm being lazy about re-reading the old notes)
I haven't seen so far the "no nouveau outputs detected" or "nouveau output names are changing" issues anymore with xorg-1.14. So that's good. But when disabling nouveau output with "xrandr --output DP-2 --off" I get this Xorg crash: [ 138.763] reporting 5 7 17 134 [ 139.048] have a master to look out for [ 139.048] (EE) [ 139.048] (EE) Backtrace: [ 139.052] (EE) 0: /usr/bin/X (OsLookupColor+0x129) [0x46ee59] [ 139.052] (EE) 1: /lib64/libpthread.so.0 (__restore_rt+0x0) [0x36f2e0ef9f] [ 139.053] (EE) 2: /lib64/libdrm_intel.so.1 (drm_intel_bufmgr_fake_init+0xe3b) [0x7f2bd9ff2f3b] [ 139.054] (EE) 3: /lib64/libdrm_intel.so.1 (drm_intel_bufmgr_fake_init+0x2924) [0x7f2bd9ff6134] [ 139.055] (EE) 4: /usr/lib64/xorg/modules/drivers/intel_drv.so (_init+0x9f22) [0x7f2bda22cf12] [ 139.055] (EE) 5: /usr/lib64/xorg/modules/drivers/intel_drv.so (_init+0x6075) [0x7f2bda225285] [ 139.056] (EE) 6: /usr/bin/X (xf86PruneDuplicateModes+0x1df7) [0x4c84e7] [ 139.056] (EE) 7: /usr/bin/X (RRCrtcSet+0x589) [0x502b39] [ 139.056] (EE) 8: /usr/bin/X (ProcRRSetCrtcConfig+0x3d9) [0x503c99] [ 139.056] (EE) 9: /usr/bin/X (SendErrorToClient+0x3f7) [0x436fe7] [ 139.057] (EE) 10: /usr/bin/X (_init+0x3aaa) [0x429b8a] [ 139.058] (EE) 11: /lib64/libc.so.6 (__libc_start_main+0xf5) [0x36f2621b75] [ 139.058] (EE) 12: /usr/bin/X (_start+0x29) [0x4267f1] [ 139.059] (EE) 13: ? (?+0x29) [0x29] [ 139.059] (EE) [ 139.059] (EE) Segmentation fault at address 0x8 [ 139.059] (EE) Fatal server error: [ 139.059] (EE) Caught signal 11 (Segmentation fault). Server aborting [ 139.059] (EE) [ 139.059] (EE) Please consult the Fedora Project support at http://wiki.x.org for help. [ 139.059] (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information. [ 139.059] (EE) [ 139.060] (II) AIGLX: Suspending AIGLX clients for VT switch [ 139.543] (EE) Server terminated with error (1). Closing log file.
Call me crazy, but that sure doesn't _seem_ like a nouveau bug, unless it's corrupting something in the intel stuff. Reroute to intel people, or file a new bug there?
Yep, I know, Intel strings in the traceback :) But it happens when disabling a nouveau output.. But I agree, it's better to open a separate bug report about that issue..
"segfault in OsLookupColor": https://bugzilla.redhat.com/show_bug.cgi?id=957915 I guess that bugzilla entry is why I'm now getting crashes in Xorg. So I think we can close this bug, the "changing connector names" nouveau bug seems to be gone in xorg-1.14. Thanks!
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.