Description of problem: Xorg segfaults when running "xrandr --output DP-2 --off" to disable an output on *nouveau* card. Backtrace in Xorg.0.log has Intel strings in it, but the crash is triggered by disabling an output on nouveau/optimus adapter. I'm using Fedora 19 on Lenovo T430 laptop in Optimus mode (Intel Ivy Bridge + Nouveau GF108): Version-Release number of selected component (if applicable): Fedora 19 with latest updates installed. How reproducible: Very often. Steps to Reproduce: 1. Enable Optimus in BIOS on Lenovo T430 laptop. 2. Connect laptop to docking station. 3. Connect external DVI monitor to docking station DVI port. 4. Start Fedora 19, login to (mate) desktop. 5. Start a terminal and run "xrandr --output DP-2 --off". Actual results: Xorg crashes with segfault/backtrace. Expected results: Xorg doesn't crash and nouveau output (DVI monitor) gets disabled. Additional info: [ 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.
Created attachment 793335 [details] Xorg.0.log with the segfault backtrace
This crash is probably related to: "segfault in OsLookupColor": https://bugzilla.redhat.com/show_bug.cgi?id=957915
I also filed upstream bugreport to: "[uxa optimus] Xorg server crashes with segfault when disabling nouveau optimus output with xrandr": https://bugs.freedesktop.org/show_bug.cgi?id=70008
I can confirm this bug also happens on the Lenovo T420 with NVidia Optimus (NVS4100), running under the default Nouveau driver. It is extremely easy to reproduce, as OP mentioned. In my case, I'm using KDE4 and the "Display Configuration" front-end to XRandR. Simply disabling the external display segfaults X, and it goes back to the KDM greeter, completely eradicating my existing session. It also occurs even with the built-in DisplayPort adapter when I'm not docked. So the issue isn't solely related to the docking station. My workaround: log out, undock, alt-E to restart the X server. Then log back in, un-docked, and suspend the laptop prior to stuffing it in a bag for travel. Side note: at least the digital ports work now, and for that, I am grateful! I used to have to use my VGA ports only in F17. This particular fault has been the only post-install flaw I've found in Fedora 19 on the T420.
Correction, the card is an NVidia Quadro NVS4200. The Intel card is the integrated card on the i7-2640M processor.
With the latest Fedora 19 updates, as of today, I can't reproduce the crash anymore. It seems to work OK now. Versions I have now: Linux kernel 3.11.2-201.fc19.x86_64, xorg-x11-server-Xorg-1.14.3-1.fc19.x86_64, xorg-x11-drv-intel-2.21.12-2.fc19.x86_64, xorg-x11-drv-nouveau-1.0.9-1.fc19.x86_64.
I still can. Here's today's backtrace. Note that I have the same kernel, intel and nouveau drivers, and Xorg server as you. [ 43.715] (EE) [ 43.715] (EE) Backtrace: [ 43.720] (EE) 0: /usr/bin/X (OsLookupColor+0x129) [0x46ee59] [ 43.720] (EE) 1: /lib64/libpthread.so.0 (__restore_rt+0x0) [0x3fa720ef9f] [ 43.721] (EE) 2: /lib64/libdrm_intel.so.1 (drm_intel_bufmgr_fake_init+0xe3b) [0x7fcf14757f3b] [ 43.722] (EE) 3: /lib64/libdrm_intel.so.1 (drm_intel_bufmgr_fake_init+0x2924) [0x7fcf1475b134] [ 43.724] (EE) 4: /usr/lib64/xorg/modules/drivers/intel_drv.so (_init+0x9f22) [0x7fcf14991f12] [ 43.725] (EE) 5: /usr/lib64/xorg/modules/drivers/intel_drv.so (_init+0x6075) [0x7fcf1498a285] [ 43.727] (EE) 6: /usr/bin/X (xf86PruneDuplicateModes+0x1df7) [0x4c84e7] [ 43.727] (EE) 7: /usr/bin/X (RRCrtcSet+0x589) [0x502b39] [ 43.727] (EE) 8: /usr/bin/X (ProcRRSetCrtcConfig+0x3d9) [0x503c99] [ 43.727] (EE) 9: /usr/bin/X (SendErrorToClient+0x3f7) [0x436fe7] [ 43.728] (EE) 10: /usr/bin/X (_init+0x3aaa) [0x429b8a] [ 43.730] (EE) 11: /lib64/libc.so.6 (__libc_start_main+0xf5) [0x3fa6a21b75] [ 43.730] (EE) 12: /usr/bin/X (_start+0x29) [0x4267f1] [ 43.731] (EE) 13: ? (?+0x29) [0x29] [ 43.731] (EE) [ 43.731] (EE) Segmentation fault at address 0x8 [ 43.731] (EE) Fatal server error: [ 43.731] (EE) Caught signal 11 (Segmentation fault). Server aborting
So, on a lark, I figured it might be related to my ~/.kde data somehow. Made a new user, tried to disable the output, and it was fine? So perhaps this bug *can* be marked closed.. Going to try a fresh ~/.kde and see what happens.
Busy with work, and didn't have time to really investigate this bug deeply. So, at this time, the bug is very much reproducible. If I want to segfault X, here's what I do: 1) boot laptop 2) dock, or plug into displayport, an external monitor. 3) login via KDM to KDE. 4) open the display manager 5) undock or disconnect the monitor. 6) untick the check box for the external monitor. 7) click apply or ok 8) segfault. I tried this all on a fresh new user that didn't have all of my crufty old KDE configs from back in the KDE 4.0 days. I had trouble reproducing the segfault for a bit, but then managed to change the monitor offset, and it crashed. I took a snapshot of my .kde folder before and after the segfault, and attached the diff. The key for me, was that once I got it to segfault once, no matter what I did inside the Display Manager too, it would segfault once I made a change and exited. That lead me to believe it was somehow related to a file on-disk. The diff showed me a file, ~/.kde/share/apps/kscreen/<randomhashvalue>, and the significant difference was that the starting Y coordinate for that file was non-zero. As long as that was zero, it didn't seem to crash. (or so I thought.) To test that, I marked the file immutable, and then tried to reproduce the crash. Sadly, with a little effort, I was able to do so. Perhaps that file is a red herring, I don't know. But I do know that once the bug is triggered once, its significantly easier to trigger it a second time.
Created attachment 824318 [details] differences in ~/.kde from a normal install, compared to one that segfaulted every time.
The above commentary was with my laptop running the following: kernel-3.11.7-200.fc19.x86_64 xorg-x11-server-Xorg-1.14.3-2.fc19.x86_64 kde-runtime-4.11.2-1.fc19.x86_64 There's a bunch of updates to KDE, so I'm updating and will try to reproduce again.
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.