Bug 981686 - Xorg crash when using Xinerama in NVIDIA on multiple monitors
Summary: Xorg crash when using Xinerama in NVIDIA on multiple monitors
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11
Version: 19
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: X/OpenGL Maintenance List
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2013-07-05 13:30 UTC by Ricky
Modified: 2015-02-17 15:52 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2015-02-17 15:52:34 UTC
Type: Bug

Attachments (Terms of Use)
Functioning xorg.conf: starts multiple X screens, one per card (2.81 KB, text/plain)
2013-08-21 14:32 UTC, Tim Crone
no flags Details
Failing X config, as generated by the nvidia-xconfig tool. (111 bytes, text/plain)
2013-08-21 14:34 UTC, Tim Crone
no flags Details

Description Ricky 2013-07-05 13:30:39 UTC
Description of problem:

GNOME 3.8 require composite extension. However, when enabling Xinerama in NVIDIA driver with latest version 319.32, it doesn't support composite extension.

GDM can't be loaded if disable composite extension. Current workaround is to switch KDM.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. In Fedora 18, run Fedup --network 19
2. After installation, Xorg crashed with white screen.

Actual results:

Expected results:

Additional info:

Comment 1 Tim Crone 2013-08-21 14:30:16 UTC
I have been running 19 for a while, and I have a bit more information:

X will NEVER start with Xinerama configured when using the Nvidia closed-source driver.

- I get the crash (X startup failure screen) whenever I start X, whether I am using GDM, starting X from the command line, running a different WM, etc.  This is a 100% crash.

- If I kill X using the keyboard, I can sometimes restart it and get the crash; about 25% of the attempts to restart, however, I get a hard system hang with a white screen, and about 25% I get a soft hang with the same white screen that I can <ctrl-alt-del>.

- When I disable Xinerama, X correctly starts up with two windows, :.0 and :.1.  I am starting without GDM.

- There seems to be an issue in the interaction between the new kernel and the new Nvidia driver.  I have configs that have Composite enabled and disabled that fail in the same way so I believe that is a red herring.  Arch Linux users have discussed experimenting with changing kernel and driver versions.

- This has been true since I updated from FC17 to FC19 a couple months ago, using fedup.  I have run a number of kernel updates (3.9, currently 3.10) and a couple nvidia updates (currently 319.32) with no change in status.

- I will attach my working, non-Xinerama config, and a failing config, though as I mentioned the nvidia default config with two NVidia cards enabled causes the crash.

- Versions:
akmod-nvidia.x86_64               1:319.32-2.fc19     @rpmfusion-nonfree-updates
kernel.x86_64                     3.9.9-302.fc19      @updates                  
kernel.x86_64                     3.10.3-300.fc19     @updates                  
kernel.x86_64                     3.10.7-200.fc19     @updates                  
xorg-x11-drv-nvidia.x86_64        1:319.32-7.fc19     @rpmfusion-nonfree-updates
xorg-x11-drv-nvidia-libs.x86_64   1:319.32-7.fc19     @rpmfusion-nonfree-updates

Please feel free to contact me for any additional information.

Comment 2 Tim Crone 2013-08-21 14:32:00 UTC
Created attachment 788896 [details]
Functioning xorg.conf: starts multiple X screens, one per card

Comment 3 Tim Crone 2013-08-21 14:34:01 UTC
Created attachment 788897 [details]
Failing X config, as generated by the nvidia-xconfig tool.

Comment 4 Ricky 2013-08-21 14:45:41 UTC
I used twinview to workaround dual monitor problem. A sample xorg.conf is listed here http://rickyzhang.dyndns.org/blog/?p=84

It looks similar to your functioning one. Both disable Xinerama. But one difference is that you use two screens mine is one. I'm not sure if it means all render in the same buffer. 

Anyway, I read NVIDIA document. My dual GPU GTX590 card doesn't support MOSAIC. So it is possible that
Option "SLI" "Mosaic"
Option "BaseMosaic" "True"

doesn't play in role. I'm scratch my head now why it works in my box. The xorg log doesn't say anything.

Comment 5 Tim Crone 2013-08-23 20:06:29 UTC
Thanks Ricky.  TwinView works fine for two monitors on a single card, but it does not work across cards.  That's why I have two screens and you only need one in our respective working configs - I actually use three monitors running on two cards.

This does seem to be an Nvidia problem, so hopefully someone at RH knows someone at Nvidia.

The thread I mentioned above is here, by the way:

Comment 6 Ricky 2013-08-24 00:47:02 UTC
Sorry, my link is dead due to dyndns expire. Try this:


Although mine is single card, it got two gpus. I'm not so sure how it cooperate.

Regarding to your wish, I doubt this will happen. Linux is not targeted for desktop.


Comment 7 Tim Crone 2013-09-20 13:46:32 UTC
Because yours is a single card, the independent addressing is in the Nvidia driver.  When I updated yesterday, the Nvidia driver wasn't loading; I can still address both cards but only the first port of each - so I have lost a monitor again, but now a different one.  Without the Nvidia driver Xinerama works, of course; I don't do anything with 3D so I'm not sure how acceleration is.  Anyway you (and anyone else with one card, or a functional two-card setup) may not want to go to 3.11 yet.

All this is on a very fancy Lenovo ThinkStation at my office, as delivered.  This system is a server for most folks who use it [and, strictly, it is nominally a server for me, I just took the opportunity to supplement my Windows laptop with the extra CPU cycles :].  I'm not sure why they ship with 4 video ports, but they do, so there must be some non-desktop use case for it.

Comment 8 Fedora End Of Life 2015-01-09 18:41:16 UTC
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.

Comment 9 Fedora End Of Life 2015-02-17 15:52:34 UTC
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

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.