190.42 nvidia / evdev issue

Tonacatecuhtli · 11-17-09, 11:35 PM

I'm having an issue where X will freeze intermittently, although usually when some high-graphics-card-load applications e.g. Neverwinter Nights is running. This freeze will generally last about three seconds and then everything will continue normally.

X reports backtraces like:

Code:

Backtrace:
0: X (xorg_backtrace+0x28) [0x4676d8]
1: X (mieqEnqueue+0x1eb) [0x45f9eb]
2: X (xf86PostMotionEventP+0xc8) [0x46c088]
3: /usr/lib64/xorg/modules/input/evdev_drv.so (0x7faf9ada3000+0x41d9) [0x7faf9ada71d9]
4: X (0x400000+0x76107) [0x476107]
5: X (0x400000+0x10b379) [0x50b379]
6: /lib/libpthread.so.0 (0x7faf9f92d000+0xf260) [0x7faf9f93c260]
7: /lib/libc.so.6 (__sched_yield+0x7) [0x7faf9df68377]
8: //usr/lib64/opengl/nvidia/lib/libGLcore.so.1 (0x7faf9bb4b000+0xbce275) [0x7faf9c719275]
9: //usr/lib64/opengl/nvidia/lib/libGLcore.so.1 (0x7faf9bb4b000+0xbce3ab) [0x7faf9c7193ab]
10: //usr/lib64/opengl/nvidia/lib/libGLcore.so.1 (0x7faf9bb4b000+0x8f5daf) [0x7faf9c440daf]
11: //usr/lib64/opengl/nvidia/lib/libGLcore.so.1 (0x7faf9bb4b000+0x54ce06) [0x7faf9c097e06]
12: /usr/lib64/xorg/modules/extensions/libglx.so (0x7faf9cfa8000+0x22fdd3) [0x7faf9d1d7dd3]

And thus my theory that the problem has something to do with both evdev and nvidia. From what I've seen, the backtraces always go through the nvidia code to the evdev code to the point of failure.

Things that may set my system apart from the norm would be 2 GTX 260s in SLi and xorg 1.7.1. More details in bug report file.

Has anyone else seen anything like this?

mooninite · 11-18-09, 01:22 AM

I see you have TripleBuffering on. I had it on, too, and had stability issues immediately with Fedora 12 (xorg 1.7.1). As soon as I commented that option X became stable.

edit: I had very similar backtraces to yours, but X froze and would not let go. Sometimes it would flicker the image very rapidly when "frozen."

Tonacatecuhtli · 11-18-09, 01:44 AM

Thanks for the tip! Unfortunately it does not seem to have remedied my issue. I haven't had any problems with stability, per se, X hasn't locked up on me or crashed, just temporarily frozen.

Here's some example backtraces without triple buffering (in lieu of a whole new bug report file):

Code:

(WW) Nov 18 02:37:13 NVIDIA(0): WAIT (2, 6, 0x8000, 0x00007724, 0x00007734)
(WW) Nov 18 02:37:20 NVIDIA(0): WAIT (1, 6, 0x8000, 0x00007724, 0x00007734)
[mi] EQ overflowing. The server is probably stuck in an infinite loop.

Backtrace:
0: X (xorg_backtrace+0x28) [0x4676d8]
1: X (mieqEnqueue+0x1eb) [0x45f9eb]
2: X (xf86PostMotionEventP+0xc8) [0x46c088]
3: /usr/lib64/xorg/modules/input/evdev_drv.so (0x7f6726ed8000+0x41d9) [0x7f6726edc1d9]
4: X (0x400000+0x76107) [0x476107]
5: X (0x400000+0x10b379) [0x50b379]
6: /lib/libpthread.so.0 (0x7f672ba62000+0xf260) [0x7f672ba71260]
7: /lib/libc.so.6 (__sched_yield+0x7) [0x7f672a09d377]
8: //usr/lib64/opengl/nvidia/lib/libGLcore.so.1 (0x7f6727c80000+0xbce275) [0x7f672884e275]
9: //usr/lib64/opengl/nvidia/lib/libGLcore.so.1 (0x7f6727c80000+0xbce3ab) [0x7f672884e3ab]
10: //usr/lib64/opengl/nvidia/lib/libGLcore.so.1 (0x7f6727c80000+0x8f5daf) [0x7f6728575daf]
11: //usr/lib64/opengl/nvidia/lib/libGLcore.so.1 (0x7f6727c80000+0x54ce06) [0x7f67281cce06]
12: /usr/lib64/xorg/modules/extensions/libglx.so (0x7f67290dd000+0x22fdd3) [0x7f672930cdd3]

Backtrace:
0: X (xorg_backtrace+0x28) [0x4676d8]
1: X (mieqEnqueue+0x1eb) [0x45f9eb]
2: X (xf86PostMotionEventP+0xc8) [0x46c088]
3: /usr/lib64/xorg/modules/input/evdev_drv.so (0x7f6726ed8000+0x41d9) [0x7f6726edc1d9]
4: X (0x400000+0x76107) [0x476107]
5: X (0x400000+0x10b379) [0x50b379]
6: /lib/libpthread.so.0 (0x7f672ba62000+0xf260) [0x7f672ba71260]
7: /lib/libc.so.6 (__sched_yield+0x7) [0x7f672a09d377]
8: //usr/lib64/opengl/nvidia/lib/libGLcore.so.1 (0x7f6727c80000+0xbce275) [0x7f672884e275]
9: //usr/lib64/opengl/nvidia/lib/libGLcore.so.1 (0x7f6727c80000+0xbce304) [0x7f672884e304]
10: //usr/lib64/opengl/nvidia/lib/libGLcore.so.1 (0x7f6727c80000+0x90404f) [0x7f672858404f]
11: //usr/lib64/opengl/nvidia/lib/libGLcore.so.1 (0x7f6727c80000+0x8f3686) [0x7f6728573686]
12: //usr/lib64/opengl/nvidia/lib/libGLcore.so.1 (0x7f6727c80000+0x5cbf74) [0x7f672824bf74]
13: //usr/lib64/opengl/nvidia/lib/libGLcore.so.1 (0x7f6727c80000+0x5cc3c6) [0x7f672824c3c6]
14: //usr/lib64/opengl/nvidia/lib/libGLcore.so.1 (0x7f6727c80000+0x5cc81f) [0x7f672824c81f]
15: /usr/lib64/xorg/modules/extensions/libglx.so (0x7f67290dd000+0x15ca69) [0x7f6729239a69]

Unfortunately without symbols they are remarkably useless to me. Has anyone seen the same pattern, evdev + nvidia?

piotrq__ · 11-18-09, 03:56 PM

I'd get rid of
this: Option "PixmapCacheSize" "10000000"
that: Option "DRI" "true" #you don't have the dri module anyway
that: Option "XAANoOffscreenPixmaps" "true"
these: Option "PixmapCacheSize" "10000000" #driver knows what to do
Option "AllowSHMPixmaps" "0" #off by default
Option "BackingStore" "true" #can cause a performance degradation
Option "HWcursor" "on" #on by default

And last but not least, put this into your config:
Option "UseEvents" "false" #something's broken with G8x or newer cards and latest drivers here, so make sure it is off

loftwyr · 11-20-09, 11:33 AM

Or better yet, reduce your xorg.conf to

Code:

Section "Device"
    Identifier     "VideoCard"
    Driver         "nvidia"
EndSection

and nothing more and see how it works

Tonacatecuhtli · 11-20-09, 05:06 PM

Quote:

Originally Posted by piotrq__

I'd get rid of
this: Option "PixmapCacheSize" "10000000"
that: Option "DRI" "true" #you don't have the dri module anyway
that: Option "XAANoOffscreenPixmaps" "true"
these: Option "PixmapCacheSize" "10000000" #driver knows what to do
Option "AllowSHMPixmaps" "0" #off by default
Option "BackingStore" "true" #can cause a performance degradation
Option "HWcursor" "on" #on by default

And last but not least, put this into your config:
Option "UseEvents" "false" #something's broken with G8x or newer cards and latest drivers here, so make sure it is off

Unfortunately it does not seem that all my xorg.conf cruft was the issue.

Quote:

Originally Posted by loftwyr

Or better yet, reduce your xorg.conf to

Code:

Section "Device"
    Identifier     "VideoCard"
    Driver         "nvidia"
EndSection

and nothing more and see how it works

This fixes it. Specifically, turning off SLI fixes it. The problem persists with both AFR and SFR. Thankfully, turning off SLI is a good enough temporary solution.

Thanks for the ideas, everyone!

ogetbilo · 11-21-09, 07:40 PM

I got the same problem and the proposed workaround, i.e. xorg.conf only with

Code:

Section "Device"
    Identifier     "VideoCard"
    Driver         "nvidia"
EndSection

did not fix it. Any other ideas?

Tonacatecuhtli · 11-22-09, 07:43 PM

I have noticed that I too do still get occasional freezes, but these come with no dmesg nor xorg log messages. And they're much rarer and thus I can ignore them that much more easily.

ogetbilo, are the errors you're getting without SLi (or any of the other options) showing the same evdev pattern in the xorg log traces?

ogetbilo · 11-23-09, 11:41 AM

Tonacatecuhtli, it's pretty much the same

Code:

Backtrace:
0: /usr/bin/X (xorg_backtrace+0x28) [0x49e8d8]
1: /usr/bin/X (mieqEnqueue+0x1f4) [0x49e2a4]
2: /usr/bin/X (xf86PostMotionEventP+0xce) [0x478f0e]
3: /usr/lib64/xorg/modules/input/evdev_drv.so (0x7fb041f59000+0x50bf) [0x7fb041f5e0bf]
4: /usr/bin/X (0x400000+0x6be17) [0x46be17]
5: /usr/bin/X (0x400000+0x116b13) [0x516b13]
6: /lib64/libpthread.so.0 (0x3c1fe00000+0xefa0) [0x3c1fe0efa0]
7: /usr/lib64/xorg/modules/drivers/nvidia_drv.so (0x7fb06277b000+0xa4a51) [0x7fb06281fa51]
8: /usr/lib64/xorg/modules/libwfb.so (wfbBlt+0x1045) [0x7fb062346495]
9: /usr/lib64/xorg/modules/libwfb.so (wfbCopyNtoN+0x25e) [0x7fb06234a1ee]
10: /usr/bin/X (miCopyRegion+0x28d) [0x54575d]
11: /usr/bin/X (miDoCopy+0x44a) [0x545c6a]
12: /usr/lib64/xorg/modules/libwfb.so (wfbCopyArea+0x4c) [0x7fb0623494cc]
13: /usr/lib64/xorg/modules/libwfb.so (wfb_image_from_pict+0x302) [0x7fb06234e8f2]
14: /usr/lib64/xorg/modules/libwfb.so (wfbComposite+0xd4) [0x7fb06234ebd4]
15: /usr/lib64/xorg/modules/drivers/nvidia_drv.so (0x7fb06277b000+0x33e817) [0x7fb062ab9817]
16: /usr/bin/X (0x400000+0xd1c80) [0x4d1c80]
17: /usr/bin/X (0x400000+0x15e459) [0x55e459]
18: /usr/bin/X (0x400000+0x15e725) [0x55e725]
19: /usr/bin/X (0x400000+0xa2366) [0x4a2366]
20: /usr/bin/X (0x400000+0x4edde) [0x44edde]
21: /usr/bin/X (MapWindow+0x179) [0x452ec9]
22: /usr/bin/X (0x400000+0x2bdc6) [0x42bdc6]
23: /usr/bin/X (0x400000+0x2c69c) [0x42c69c]
24: /usr/bin/X (0x400000+0x21cfa) [0x421cfa]
25: /lib64/libc.so.6 (__libc_start_main+0xfd) [0x3c1f21eb1d]
26: /usr/bin/X (0x400000+0x218a9) [0x4218a9]

Dizzle7677 · 11-23-09, 04:35 PM

Debugging the Xserver

http://www.x.org/wiki/Development/Documentation/ServerDebugging

11-18-09, 01:22 AM	#2
mooninite Registered User Join Date: May 2006 Posts: 477	Re: 190.42 nvidia / evdev issue I see you have TripleBuffering on. I had it on, too, and had stability issues immediately with Fedora 12 (xorg 1.7.1). As soon as I commented that option X became stable. edit: I had very similar backtraces to yours, but X froze and would not let go. Sometimes it would flicker the image very rapidly when "frozen."

11-18-09, 03:56 PM	#4
piotrq__ Registered User Join Date: Jan 2006 Posts: 193	Re: 190.42 nvidia / evdev issue I'd get rid of this: Option "PixmapCacheSize" "10000000" that: Option "DRI" "true" #you don't have the dri module anyway that: Option "XAANoOffscreenPixmaps" "true" these: Option "PixmapCacheSize" "10000000" #driver knows what to do Option "AllowSHMPixmaps" "0" #off by default Option "BackingStore" "true" #can cause a performance degradation Option "HWcursor" "on" #on by default And last but not least, put this into your config: Option "UseEvents" "false" #something's broken with G8x or newer cards and latest drivers here, so make sure it is off

11-20-09, 11:33 AM	#5
loftwyr Registered User Join Date: Mar 2005 Posts: 10	Re: 190.42 nvidia / evdev issue Or better yet, reduce your xorg.conf to Code: Section "Device" Identifier "VideoCard" Driver "nvidia" EndSection and nothing more and see how it works

11-21-09, 07:40 PM	#7
ogetbilo Registered User Join Date: May 2004 Posts: 52	Re: 190.42 nvidia / evdev issue I got the same problem and the proposed workaround, i.e. xorg.conf only with Code: Section "Device" Identifier "VideoCard" Driver "nvidia" EndSection did not fix it. Any other ideas?

11-22-09, 07:43 PM	#8
Tonacatecuhtli Registered User Join Date: Dec 2007 Posts: 15	Re: 190.42 nvidia / evdev issue I have noticed that I too do still get occasional freezes, but these come with no dmesg nor xorg log messages. And they're much rarer and thus I can ignore them that much more easily. ogetbilo, are the errors you're getting without SLi (or any of the other options) showing the same evdev pattern in the xorg log traces?

11-23-09, 04:35 PM	#10
Dizzle7677 Registered User Join Date: May 2008 Location: Relativity Posts: 194	Re: 190.42 nvidia / evdev issue Debugging the Xserver http://www.x.org/wiki/Development/Documentation/ServerDebugging __________________ Elephants can fly but they have no reason to. ------------------------------------------ Phenom II X3 720 @ 3.5Ghz \| Asus M4A785-M \| 2 Gig Crucial DDR2 @ 960 Mhz \| GeForce GT 440 1024 MB \| Linux 3.6.1 / Ubuntu 12.04 / W.I.N.E v1.5.14