Take 3: Unable to share pixmap, random X crash

This is my third attempt to fix this problem, and I was just redirected back here. Really feel like I’m alone on this one :( Here’s the last thread:


System: MSI Apache Pro G70 with a GeForce GTX 860M (01:00.0) and a Intel 4th-gen integrated graphics controller (00:02.0). Nvidia driver is 346.16. OS is a late beta Fedora 21, kernel 3.17.4-301.fc21.x86_64 stock.

Problem, short summary: new laptop, purchased to do graphics work, trying to get the nvidia driver working for X with optimus, it starts up without a backlight, and when I use xrandr to connect it, X crashes or otherwise refuses to work.

The current status: I’m using the following xorg config:

Section “ServerLayout”
Identifier “Layout0”
Screen 0 “nvidia”
Inactive “intel”

Section “Monitor”
Identifier “Monitor0”
VendorName “Unknown”
ModelName “Unknown”
HorizSync 28.0 - 33.0
VertRefresh 43.0 - 72.0
Option “DPMS”

Section “Device”
Identifier “nvidia”
Driver “nvidia”
VendorName “NVIDIA Corporation”
BusID “PCI:1:0:0”

Section “Device”
Identifier “intel”
Driver “modesetting”
BusID “PCI:0:2:0”

Section “Screen”
Identifier “nvidia”
Device “nvidia”
Option “UseDisplayDevice” “none”
Option “AddARGBGLXVisuals” “True”

Section “Screen”
Identifier “intel”
Device “intel”
Monitor “Monitor0”

So, your standard modesetting config. Which of course requires the following xrandr lines at startup:

xrandr --setprovideroutputsource modesetting NVIDIA-0
xrandr --auto

I’ve taken to issuing them of the form “DISPLAY=:0 xrandr…” so that I can control the timing and see the output.

I’ve gotten things to the point that X starts up without crashing (but, of course, without the backlight). And now I can even issue the first statement - no error returned. X somewhat randomly either continues, continues for a while then crashes, or crashes immediately. The second line fails with:

DISPLAY=:0 xrandr --auto

X Error of failed request: BadMatch (invalid parameter attributes)
Major opcode of failed request: 139 (RANDR)
Minor opcode of failed request: 7 (RRSetScreenSize)
Serial number of failed request: 29
Current serial number in output stream: 30

xrandr with no arguments yields:

Screen 0: minimum 8 x 8, current 640 x 480, maximum 16384 x 16384
eDP-1-0 connected (normal left inverted right x axis y axis)
1920x1080 60.01 +
1400x1050 59.98
1280x1024 60.02
1280x960 60.00
1024x768 60.04 60.00
960x720 60.00
928x696 60.05
896x672 60.01
800x600 60.00 60.32 56.25
700x525 59.98
640x512 60.02
640x480 60.00 59.94
512x384 60.00
400x300 60.32 56.34
320x240 60.05
VGA-1-0 disconnected (normal left inverted right x axis y axis)
HDMI-1-0 disconnected (normal left inverted right x axis y axis)

The problem seems to be NVidia trying to shared a non-shared pixmap. The relevant parts of the Xorg.0.log:

[ 82.586] (II) modesetting(G0): RandR 1.2 enabled, ignore the following RandR disabled message.
[ 82.586] (==) modesetting(G0): DPMS enabled
[ 82.586] (WW) modesetting(G0): Option “UseDisplayDevice” is not used
[ 82.872] (II) NVIDIA: Using 3072.00 MB of virtual memory for indirect memory
[ 82.872] (II) NVIDIA: access.
[ 82.881] (II) NVIDIA(0): Setting mode “NULL”
[ 82.902] (II) NVIDIA(0): Built-in logo is bigger than the screen.
[ 82.906] (==) NVIDIA(0): Disabling shared memory pixmaps
[ 82.906] (==) NVIDIA(0): Backing store enabled
[ 82.906] (==) NVIDIA(0): Silken mouse enabled
[ 82.906] (==) NVIDIA(0): DPMS enabled

And then, when I get a crash…

[ 114.855] reporting 3 3 20 149
[ 114.855] reporting 3 3 20 149
[ 114.855] reporting 3 3 20 149
[ 114.857] reporting 3 3 20 149
[ 116.086] reporting 3 3 20 149
[ 118.157] reporting 3 3 20 149
[ 118.158] have a master to look out for
[ 118.158] (EE) NVIDIA(0): The X server tried to share a non-shareable pixmap
[ 118.158] need to create shared pixmap 0(EE)
[ 133.239] (EE) Backtrace:
[ 133.239] (EE) 0: /usr/libexec/Xorg.bin (OsLookupColor+0x119) [0x59bfd9]
[ 133.240] (EE) 1: /lib64/libc.so.6 (__restore_rt+0x0) [0x7f052dbac94f]
[ 133.240] (EE) 2: /usr/lib64/xorg/modules/drivers/nvidia_drv.so (nvidiaAddDrawableHandler+0x3dcd0) [0x7f05273e8650]
[ 133.240] (EE) 3: /usr/lib64/xorg/modules/libwfb.so (wfbBlt+0x13d) [0x7f0526ca066d]
[ 133.240] (EE) 4: /usr/lib64/xorg/modules/libwfb.so (wfbCopyNtoN+0x30b) [0x7f0526ca48bb]
[ 133.240] (EE) 5: /usr/libexec/Xorg.bin (miCopyRegion+0x1a7) [0x5773e7]
[ 133.240] (EE) 6: /usr/libexec/Xorg.bin (miDoCopy+0x45e) [0x57798e]
[ 133.240] (EE) 7: /usr/lib64/xorg/modules/libwfb.so (wfbCopyArea+0x2d) [0x7f0526ca5a5d]
[ 133.240] (EE) 8: /usr/lib64/xorg/modules/drivers/nvidia_drv.so (nvidiaAddDrawableHandler+0x514259) [0x7f0527d950a9]
[ 133.240] (EE) 9: /usr/libexec/Xorg.bin (DamageRegionAppend+0x33ed) [0x52495d]
[ 133.275] (EE) 10: /usr/libexec/Xorg.bin (CompositeRegisterImplicitRedirectionException+0x26d5) [0x4cdd25]
[ 133.275] (EE) 11: /usr/libexec/Xorg.bin (CompositeRegisterImplicitRedirectionException+0x34f5) [0x4cfb15]
[ 133.275] (EE) 12: /usr/libexec/Xorg.bin (CompositeRegisterImplicitRedirectionException+0x1fcd) [0x4cd0bd]
[ 133.275] (EE) 13: /usr/libexec/Xorg.bin (SwapConnClientPrefix+0x1e96) [0x464656]
[ 133.275] (EE) 14: /usr/libexec/Xorg.bin (MapWindow+0x117) [0x465697]
[ 133.275] (EE) 15: /usr/libexec/Xorg.bin (ProcBadRequest+0x5f5) [0x433d95]
[ 133.275] (EE) 16: /usr/libexec/Xorg.bin (SendErrorToClient+0x2f7) [0x439037]
[ 133.275] (EE) 17: /usr/libexec/Xorg.bin (remove_fs_handlers+0x416) [0x43d196]
[ 133.275] (EE) 18: /lib64/libc.so.6 (__libc_start_main+0xf0) [0x7f052db97fe0]
[ 133.276] (EE) 19: /usr/libexec/Xorg.bin (_start+0x29) [0x42761e]
[ 133.276] (EE) 20: ? (?+0x29) [0x29]
[ 133.276] (EE)
[ 133.276] (EE) Segmentation fault at address 0x0
[ 133.276] (EE)
Fatal server error:
[ 133.276] (EE) Caught signal 11 (Segmentation fault). Server aborting
[ 133.276] (EE)
[ 133.276] (EE)
Please consult the Fedora Project support
at http://wiki.x.org
for help.
[ 133.276] (EE) Please also check the log file at “/var/log/Xorg.0.log” for additional information.
[ 133.276] (EE)
[ 133.326] (EE) Server terminated with error (1). Closing log file.

But why is NVIDIA disabling it? That seems to be the question, no?

Xorg.0.log (29.1 KB)
nvidia-bug-report.log.gz (170 KB)

Are you trying to issue those xrandr command while switched away from the X server? They don’t work if you VT switch – they have to be executed from within the X session. Usually this means that you need to issue them from your display manager’s setup scripts, not from the console.

The error messages are a little confusing, sorry. The message

is referring to pixmaps that use POSIX shared memory to share data between the X server and its clients. That has nothing to do with the sharing mechanism that RandR 1.4 uses for its display offloading stuff.

For display offload, the X server is expected to create a shareable pixmap by calling the CreatePixmap function with the CREATE_PIXMAP_USAGE_SHARED hint. Then, it actually shares the pixmap by calling SharePixmapBacking. The message

means that the X server called SharePixmapBacking on a pixmap that was not created with the USAGE_SHARED flag. That indicates an X server bug.

Oh thank you so much for responding! I was starting to worry that nobody monitored these forums - this makes me really glad and hopeful that I’ll eventually be able to get a solution and use my laptop for what I bought it for! :)

As mentioned, I’ve been issuing the xrandr statements as:

DISPLAY=:0 xrandr --setprovideroutputsource modesetting NVIDIA-0
DISPLAY=:0 xrandr --auto

So that I can execute them on the X session :0 but still get to see the output and control the timing. I once had them in an .xinitrc; I’ll give it a try again, it’s been a while since I last tried that and a lot has changed since then.

So there’s an X server bug? Okay, I guess after I’m done trying the above I need to go track down how to report a bug for X. :)

Just tried issuing the commands from within .xinitrc rather than commandline as above… same result, just with less useful debugging info, as with last time.

Okay, off to find out how to make an X bug report!

Update: Bug reported here:


Wouldn’t be surprised if they bounce it back and try to blame NVidia, as I know how these sort of things usually go. But hopefully someone will find and fix the problem eventually - and I’ll do whatever I can to assist!

Ooh, finally a couple responses on the X bug report! :) Dave Airlie wrote:

Chris Wilson wrote:

Does any of this make any sense to you?

I looked at the driver a bit more and it really does look like it should be correctly failing CreatePixmap if for some reason it can’t create a shareable pixmap, but in theory it could be somehow failing to create a shareable pixmap and then falling back to creating an unshareable pixmap. However, even if that were happening, SharePixmapBacking returns FALSE if it can’t share the pixmap, so the X server should be handling that gracefully too.

The only other thing I can think of is that Fedora could be applying some weird patch to the server that’s causing problems.