| Summary: | nouveau inconsistent changing output connector names in xrandr | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | xorg | Reporter: | Pasi Kärkkäinen <pasik> | ||||||||
| Component: | Driver/nouveau | Assignee: | Nouveau Project <nouveau> | ||||||||
| Status: | RESOLVED FIXED | QA Contact: | Xorg Project Team <xorg-team> | ||||||||
| Severity: | major | ||||||||||
| Priority: | medium | ||||||||||
| Version: | unspecified | ||||||||||
| Hardware: | x86-64 (AMD64) | ||||||||||
| OS: | Linux (All) | ||||||||||
| Whiteboard: | |||||||||||
| i915 platform: | i915 features: | ||||||||||
| Attachments: |
|
||||||||||
|
Description
Pasi Kärkkäinen
2013-08-13 18:04:12 UTC
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.