Go Back   nV News Forums > Linux Support Forums > NVIDIA Linux

Newegg Daily Deals

Reply
 
Thread Tools
Old 05-05-11, 01:36 PM   #1
pjwhite
Registered User
 
Join Date: May 2009
Posts: 7
Default Xorg lockup under high openGL load with newest 270.41.06 driver. ( repeatable )

Under high openGL load I repeatably get Xorg lockups that are recoverable only by a reboot. This is very damaging because I am trying to support a product that is affected by this issue.

I am using ubuntu 10.04, and have tried a few different drivers ( 260.19.x series, and the latest 270.41.06 ), and the issue exists. This particular system has GTS 450s, or another fermi based card. I can easily reproduce this with a 2 monitor, 2 GPU setup with one monitor plugged into each GPU, and spanning them with xinerama. The problem is not exclusively with xinerama, and I have reproduced it on a 2 monitor system using twinview.

Using GTS 250s I have so far been unable to reproduce this, however.

I have a test program, using Qt OpenGL that will open up and move itself from one monitor to the other every 2 seconds. If I run a few of these I will end up locking up the system almost every time withing 10 or 20 seconds of the programs starting and moving.

I have tried a number of Xorg.conf parameters:
- Option "UserEvents" "1"
- Option "TripleBuffer" "1"
- Option "BackingStore" "1"

The openGL parameter __GL_YIELD=USLEEP seemed to make a pretty good difference, and typically the test scenario does not lock up Xorg about 2/3 of the time. However 1/3 of the time Xorg still locks up and requires a reboot.

I can ssh into the system and I run a "strace -p `pidof X`" and for default __GL_YIELD i get the following ( repeated forever ):

Code:
rt_sigreturn(0xe)                       = 140470336774144
--- SIGALRM (Alarm clock) @ 0 (0) ---
rt_sigreturn(0xe)                       = 2147483648
--- SIGALRM (Alarm clock) @ 0 (0) ---
rt_sigreturn(0xe)                       = 140470336774144
--- SIGALRM (Alarm clock) @ 0 (0) ---
rt_sigreturn(0xe)                       = 140470336774144
--- SIGALRM (Alarm clock) @ 0 (0) ---
rt_sigreturn(0xe)                       = 2147483648
with __GL_YIELD set to USLEEP this is the more rare strace ( repeated forever ):

Code:
rt_sigprocmask(SIG_BLOCK, [ALRM CHLD TSTP TTIN TTOU VTALRM WINCH IO], [IO], 8) = 0
rt_sigprocmask(SIG_SETMASK, [IO], NULL, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [IO], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, [IO], [], 8)  = 0
rt_sigprocmask(SIG_UNBLOCK, [IO], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, [IO], [], 8)  = 0
rt_sigprocmask(SIG_UNBLOCK, [IO], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, [IO], [], 8)  = 0
rt_sigprocmask(SIG_UNBLOCK, [IO], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, [IO], [], 8)  = 0

I have two log incidents of this occuring, the first (nvidia-bug-report-1.log.gz) is with normal __GL_YIELD and the second is with __GL_YIELD=USLEEP (nvidia-bug-report-2.log.gz).


If anyone is interested, and has a 10.04 system I could also attach a binary and script that I can use to reproduce it on any 10.04 system, just let me know.
Attached Files
File Type: gz nvidia-bug-report-1.log.gz (67.2 KB, 109 views)
File Type: gz nvidia-bug-report-2.log.gz (68.5 KB, 101 views)
pjwhite is offline   Reply With Quote
Old 05-06-11, 01:13 AM   #2
rvijayarahavan
Registered User
 
Join Date: May 2011
Posts: 1
Default Re: Xorg lockup under high openGL load with newest 270.41.06 driver. ( repeatable )

Hi Pjwhite,

Please share your script and binary, Let me check in my system..
rvijayarahavan is offline   Reply With Quote
Old 05-06-11, 11:09 AM   #3
pjwhite
Registered User
 
Join Date: May 2009
Posts: 7
Default Re: Xorg lockup under high openGL load with newest 270.41.06 driver. ( repeatable )

Sure, I attached the binary and script as a bzip2'd tar'd folder.

Inside there is a binary called RandomMove and a script test.sh, which by default launch 10 of the RandomMove's and wait for input to quit. The RandomMove does have dependency on Qt4 openGL so that must be installed in 10.04

With 10 instances it crashes my computer about half the time, and with 4 or so it crashes probably every 1/4 of the time. ( note, my computer is a quad core i7 workstation with 6 GB of ram, so fairly fast and can keep up to this heavy of a load ).


If there is anything wrong or any questions or helpful hints I'm all ears!

(note the file was slightly too big for the attachments here so I put it on my public dropbox)

http://dl.dropbox.com/u/10710966/test.tar.bz2
pjwhite is offline   Reply With Quote
Old 05-06-11, 09:33 PM   #4
Licaon
Registered User
 
Licaon's Avatar
 
Join Date: Nov 2004
Location: Between the keyboard and the chair.
Posts: 490
Default Re: Xorg lockup under high openGL load with newest 270.41.06 driver. ( repeatable )

well, i had to switch to a VT and kill the instances in htop cause i could not bring Yakuake down, but the system did not crash or misbehave in any way.
but i'm on a single monitor, single card, GTX460, X 1.10.1, 270.41.06.
Licaon is offline   Reply With Quote
Old 05-06-11, 09:58 PM   #5
Deanjo
Registered User
 
Join Date: Aug 2004
Posts: 301
Default Re: Xorg lockup under high openGL load with newest 270.41.06 driver. ( repeatable )

No issue here on 8800GT, GTX-275 or GTX-580 using twinview ran it for well over 10 minutes on each setup (270.41.06 drivers).
Deanjo is offline   Reply With Quote
Old 05-09-11, 10:39 AM   #6
pjwhite
Registered User
 
Join Date: May 2009
Posts: 7
Default Re: Xorg lockup under high openGL load with newest 270.41.06 driver. ( repeatable )

hmmmm, Thanks for testing guys.

I am now curious as to why it doesn't seem to happen more on my system. Though sometimes it doesn't happen every run, and on a twinview setup I typically only get a lockup every 10 tests or so ( I would stop a running test after a minute or 2 ).

The three panel setup is what locks up probably every second time.
pjwhite is offline   Reply With Quote
Old 05-09-11, 01:59 PM   #7
thefirstm
Registered User
 
Join Date: Feb 2009
Posts: 226
Default Re: Xorg lockup under high openGL load with newest 270.41.06 driver. ( repeatable )

It doesn't lock my TwinView setup either (8600m GT, 1680x1050 laptop display, 1024x768 external monitor). However, I did get quite a large amount of visual corruption on the screen while it was running.
thefirstm is offline   Reply With Quote
Old 07-06-11, 12:12 PM   #8
fastdruid
Registered User
 
Join Date: Jul 2011
Posts: 1
Default Re: Xorg lockup under high openGL load with newest 270.41.06 driver. ( repeatable )

I wonder if I'm running into the same issue, nvidia driver version 260.19.06 and Ubuntu 10.10, two GPU, 4 monitors, individual X sessions.

I hit the issue when unlocking from using the screensaver (which is on random and to show off amongst my Windows running colleagues is typically something pretty and graphics intensive). The cursor flickers between two screens and I end up with X looping with the strace identical to your second example.

I've raised a bug for it but nothing has happened as yet
https://bugs.launchpad.net/ubuntu/+s...rg/+bug/780424

In my case if I leave it long enough X consumes all memory, the OOM killer then steps in and kills off X, at which point I can log in again.

Your script doesn't trigger it however.
fastdruid is offline   Reply With Quote

Old 08-04-11, 04:18 PM   #9
msch
Registered User
 
Join Date: Feb 2004
Posts: 16
Default Re: Xorg lockup under high openGL load with newest 270.41.06 driver. ( repeatable )

I'm running into what appears to be the same bug. I'm on Debian with newest NVIDIA-Linux-x86_64-280.13, but the issue appears to be related to multi gpu. I'm running 3 GT 430's with 3 monitors (one attached to each.)
Attached Files
File Type: gz nvidia-bug-report.log.gz (83.1 KB, 77 views)
msch is offline   Reply With Quote
Reply


Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT -5. The time now is 06:51 PM.


Powered by vBulletin® Version 3.7.1
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Copyright 1998 - 2014, nV News.