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

Newegg Daily Deals

Reply
 
Thread Tools
Old 06-29-08, 07:34 PM   #13
RossBoylan
Registered User
 
Join Date: Feb 2006
Posts: 12
Default Re: Spawning new session leads to crash

Quote:
Originally Posted by AaronP View Post
All of the reports of this problem seem to be with xserver 1.4.0.90, so my guess is that some change in that particular server version broke something. Also, I've seen reports of BackingStore causing crashes due to missing GC validation in the server somewhere. For those that have BackingStore enabled, does disabling it fix the problem? Also, please try the nv or vesa drivers to see if they have a similar problem.
How do I disable it (or, I guess as a first step, how do I find if it's enabled)? What is the effect of en/disabling it?

I can't check with nv, since the latter crashes immediately.

I guess I can try vesa as a test.
RossBoylan is offline   Reply With Quote
Old 06-29-08, 08:15 PM   #14
AaronP
NVIDIA Corporation
 
AaronP's Avatar
 
Join Date: Mar 2005
Posts: 2,487
Default Re: Spawning new session leads to crash

According to your log, you don't have it enabled, which leads me to believe that your crash is different from the rest. You'd see "Backing store enabled" in Xorg.0.log if it were enabled. Please do try the vesa driver, though, since the backtrace you pasted doesn't involve the NVIDIA driver at all.
AaronP is offline   Reply With Quote
Old 06-30-08, 12:03 AM   #15
drbloed
Registered User
 
Join Date: Feb 2007
Posts: 11
Default Re: Spawning new session leads to crash

I also did a nvdia-bug-report.sh (check attachment ).
Hope this somehow helps us outta here

Additional stuff from /var/log/kdm.log
Code:
...
Backtrace:
0: /usr/bin/X(xf86SigHandler+0x6a) [0x49019a]
1: /lib/libc.so.6 [0x3594833170]
2: /usr/lib64/xorg/modules/drivers//nvidia_drv.so [0x7ff80b0726b8]

Fatal server error:
Caught signal 11.  Server aborting
...

FYI, "Backing store" seems to be disabled here.
Code:
boris64 ~ # grep -i "Backing store" /var/log/Xorg.*
/var/log/Xorg.0.log:(==) NVIDIA(0): Backing store disabled
/var/log/Xorg.0.log.old:(==) NVIDIA(0): Backing store disabled
var/log/Xorg.1.log:(==) NVIDIA(0): Backing store disabled
/var/log/Xorg.1.log.old:(==) NVIDIA(0): Backing store disabled
Xorg version
[edit]boris64 log # X -version

X.Org X Server 1.4.2
Release Date: 11 June 2008
X Protocol Version 11, Revision 0
Build Operating System: Linux 2.6.26-rc8-2k8-PersianSteel-dirty x86_64
Current Operating System: Linux boris64 2.6.26-rc8-2k8-PersianSteel-00076-g1702b52-dirty #23 SMP PREEMPT Sun Jun 29 22:51:51 CEST 2008 x86_64
Build Date: 28 June 2008 05:40:02PM

Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Module Loader present
[/edit]
Attached Files
File Type: bz2 nvidia-bug-report.log.bz2 (25.7 KB, 106 views)

Last edited by drbloed; 06-30-08 at 12:09 AM. Reason: Xorg version info
drbloed is offline   Reply With Quote
Old 06-30-08, 01:22 PM   #16
RossBoylan
Registered User
 
Join Date: Feb 2006
Posts: 12
Default Re: Spawning new session leads to crash

Quote:
Originally Posted by AaronP View Post
According to your log, you don't have it enabled, which leads me to believe that your crash is different from the rest. You'd see "Backing store enabled" in Xorg.0.log if it were enabled. Please do try the vesa driver, though, since the backtrace you pasted doesn't involve the NVIDIA driver at all.
The problem seems to be specific to the nvidia driver; I get no crash when switching sessions using the VESA driver.

There are 2 related Debian bugs: bugs.debian.org/445322 and 432101. 445322 is mine. As you say, and as noted there, nvidia does not appear in the stack trace for me (it does for the other bug, and other reports in this thread). The Debian X maintainers thought it possible nvidia was on my stack in an obfuscated way. Or perhaps the driver writes somewhere else, but isn't on the stack when the crash occurs--or maybe nvidia is just exposing an issue elsewhere.

My initial report seems to have been with xorg 1.3, which predates the version you mentioned earlier.

I would love to fix this. Let me know what I can do.

Here's the backtrace from my latest crash (with nvidia driver):
(==) Log file: "/var/log/Xorg.1.log", Time: Mon Jun 30 09:33:16 2008
(==) Using config file: "/etc/X11/xorg.conf"
(II) Module "ddc" already built-in
(EE) Failed to load module "type1" (module does not exist, 0)
(II) Module "ramdac" already built-in

Backtrace:
0: /usr/bin/X(xf86SigHandler+0x7e) [0x80c913e]
1: [0xffffe420]
2: /usr/bin/X(ProcPolyPoint+0x13a) [0x808aeca]
3: /usr/bin/X [0x81547a4]
4: /usr/bin/X(Dispatch+0x314) [0x808dde4]
5: /usr/bin/X(main+0x4b5) [0x8074765]
6: /lib/i686/cmov/libc.so.6(__libc_start_main+0xe0) [0xb7d21450]
7: /usr/bin/X(FontFileCompleteXLFD+0x219) [0x8073a51]

Fatal server error:
Caught signal 11. Server aborting

Could not init font path element unix/:7100, removing from list!
Could not init font path element /usr/share/fonts/X11/cyrillic, removing from list!


I think that's about the same as before.

I suppose since it's the original session that's dying, Xorg.0.log would be more relevant. Unfortunately, it gets overwritten when the new session starts.
RossBoylan is offline   Reply With Quote
Old 07-08-08, 01:58 PM   #17
drbloed
Registered User
 
Join Date: Feb 2007
Posts: 11
Default Re: Spawning new session leads to crash

Are there any news? Is somebody still having an eye on this crash?
drbloed is offline   Reply With Quote
Old 08-06-08, 09:58 PM   #18
devsk
Registered User
 
Join Date: Jun 2006
Posts: 46
Default Re: Spawning new session leads to crash

Quote:
Originally Posted by drbloed View Post
Code:
...
Backtrace:
0: /usr/bin/X(xf86SigHandler+0x6a) [0x49019a]
1: /lib/libc.so.6 [0x3594833170]
2: /usr/lib64/xorg/modules/drivers//nvidia_drv.so [0x7ff80b0726b8]

Fatal server error:
Caught signal 11.  Server aborting
...
I get the same stack for the X server crash. But here is a twist and a possible hint at the problem. The problem (and the same stack) happens in two scenarios:
1. Start a second session on vt8 under a different. First session will die randomly after some time. Reproducible every time.
2. Resume from suspend-to-ram. After successful resume, the session is thrown back to KDM. Some of the times.

The commonality is that the crash is seen if USB was too slow to respond during resume and mouse wasn't ready and evdev returned ENOENT error for the device or in second case if the device was busy (RESOURCE BUSY is seen in the log, because the current session, which is session #2, is using it) for keyboard or mouse and evdev returned error EBUSY. Are there folks here seeing this crash and not using evdev?

Maybe NVIDIA folks need to see what nvidia driver's interaction with evdev is. Recent Xorg changes have sort of forced evdev on people. And I think something needs to change in the driver to handle different error return codes.

-devsk

PS: X saves the previous log in Xorg.0.log.old. So, you do have access to previous log file as well.
devsk is offline   Reply With Quote
Old 08-06-08, 10:02 PM   #19
devsk
Registered User
 
Join Date: Jun 2006
Posts: 46
Default Re: Spawning new session leads to crash

I think this is a serious issue. And someone at NVIDIA needs to look at it. A crash is showstopper in any form.

This is another (apart from the now infamous slowness bug) thing that stops KDE 4.1 testing on nvidia cards because you can't really run your test user session and your working 3.5 user session at the same time. Logging into one kills the other.

So, NVIDIA: please respond! And if you respect your customers: please create a bugzilla!
devsk is offline   Reply With Quote
Old 08-07-08, 02:36 AM   #20
Disappointed NV
Registered User
 
Join Date: Aug 2008
Posts: 1
Default Re: Spawning new session leads to crash

This workaround took days to isolate. I hope this helps someone else.

Debian sid AMD64 8800GT.

InitialPixmapPlacement must be 0 or 1. Leave it at 1. 2 or 4 leads to VT crashing occasionally when switching VT. IIRC message was something about EVO DMA exhausted. GlyphCache=1 appears to be safe and gives me a 3x performance improvement in gnome-terminal (still about two to four times slower than the integrated Intel graphics in my low-end laptop).

In addition, DFP-0 Flat Panel Scaling Force Full GPU Scaling must be DISABLED. I also set the GPU Scaling Method to Centered. Display will go momentarily black when making this change.

With these two changes loaded when opening a new session I can switch VTs without X crashing. Otherwise it is a lottery when pressing CTRL-ALT-F7/F8. X may crash (VT becomes a black terminal with an underscore flashing) and the keyboard locks up. It is usually possible to ssh into the box and chvt may or may not work to gain access to the remaining VT. Reboot usually necessary.

Good luck everyone! Please don't expect a reply whether this workaround works for you or not. I've seriously considered cutting my losses and purchasing an AMD/ATI card just so I can get some work done.
Disappointed NV is offline   Reply With Quote

Old 08-07-08, 12:45 PM   #21
devsk
Registered User
 
Join Date: Jun 2006
Posts: 46
Default Re: Spawning new session leads to crash

I am running 177 beta drivers now and with InitialPixmapPlacement=2, glyphcache=1, there is no longer a crash while switching between VTs. I haven't seen it so far.

Let's see if it stays that way.
devsk is offline   Reply With Quote
Old 08-08-08, 12:46 PM   #22
devsk
Registered User
 
Join Date: Jun 2006
Posts: 46
Default Re: Spawning new session leads to crash

Quote:
Originally Posted by devsk View Post
I am running 177 beta drivers now and with InitialPixmapPlacement=2, glyphcache=1, there is no longer a crash while switching between VTs. I haven't seen it so far.

Let's see if it stays that way.
it wasn't meant to be...:-( X died on VT7 today when I tried to switch to VT8.

Code:
Backtrace:
0: /usr/bin/X(xf86SigHandler+0x6a) [0x4a2fea]
1: /lib/libc.so.6 [0x7f2f38578010]
2: /usr/lib64/xorg/modules/drivers//nvidia_drv.so [0x7f2f3578f436]
3: /usr/lib64/xorg/modules/drivers//nvidia_drv.so [0x7f2f3578fc99]
4: /usr/lib64/xorg/modules/drivers//nvidia_drv.so [0x7f2f357900a5]
5: /usr/bin/X [0x533d65]
6: /usr/bin/X [0x4dbe5b]
7: /usr/bin/X [0x533d65]
8: /usr/bin/X [0x506091]
9: /usr/bin/X [0x506ec1]
10: /usr/bin/X [0x507bbd]
11: /usr/bin/X(Dispatch+0x351) [0x44e2b1]
12: /usr/bin/X(main+0x4b5) [0x4352b5]
13: /lib/libc.so.6(__libc_start_main+0xfa) [0x7f2f3856421a]
14: /usr/bin/X(FontFileCompleteXLFD+0x269) [0x4344b9]

Fatal server error:
Caught signal 11.  Server aborting
Still no comment from nvidia....:-(
devsk is offline   Reply With Quote
Old 08-11-08, 04:24 AM   #23
devsk
Registered User
 
Join Date: Jun 2006
Posts: 46
Default Re: Spawning new session leads to crash

So, I built the xorg-server with debug and after many chvt's, this is what I get in the debugger:

Code:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f642c5896f0 (LWP 9436)]
0x00007f6427ec2a11 in ?? () from /usr/lib64/xorg/modules/drivers//nvidia_drv.so
(gdb) bt
#0  0x00007f6427ec2a11 in ?? () from /usr/lib64/xorg/modules/drivers//nvidia_drv.so
#1  0x0000000000591e83 in damagePolyFillRect (pDrawable=0xb2e710, pGC=0xba9eb0, nRects=1, pRects=0xb4c2ac) at damage.c:1337
#2  0x000000000044edb1 in ProcPolyFillRectangle (client=0x919ad0) at dispatch.c:1795
#3  0x000000000044b382 in Dispatch () at dispatch.c:454
#4  0x0000000000430e54 in main (argc=9, argv=0x7fff345b7208, envp=0x7fff345b7258) at main.c:441
(gdb) frame 1
#1  0x0000000000591e83 in damagePolyFillRect (pDrawable=0xb2e710, pGC=0xba9eb0, nRects=1, pRects=0xb4c2ac) at damage.c:1337
1337    damage.c: No such file or directory.
        in damage.c
(gdb) p *pDrawable
$1 = {type = 0 '\0', class = 1 '\001', depth = 24 '\030', bitsPerPixel = 32 ' ', id = 39846038, x = 717, y = 53, width = 1198, height = 641, pScreen = 0x8dad60,
  serialNumber = 1703112}
(gdb) p *pGC
$2 = {pScreen = 0x8dad60, depth = 24 '\030', alu = 3 '\003', lineWidth = 0, dashOffset = 0, numInDashList = 2, dash = 0x837d28 "\004\004", lineStyle = 0, capStyle = 1,
  joinStyle = 0, fillStyle = 0, fillRule = 0, arcMode = 1, subWindowMode = 0, graphicsExposures = 0, clientClipType = 0, miTranslate = 1, tileIsPixel = 1, fExpose = 1,
  freeCompClip = 0, unused = 0, planemask = 18446744073709551615, fgPixel = 4294922577, bgPixel = 16777215, tile = {pixmap = 0x0, pixel = 0}, stipple = 0x915120,
  patOrg = {x = 0, y = 0}, font = 0x9e38c0, clipOrg = {x = 0, y = 0}, lastWinOrg = {x = 717, y = 53}, clientClip = 0x0, stateChanges = 0, serialNumber = 1703112,
  funcs = 0x7f64280752c0, ops = 0x7f642807b800, devPrivates = 0xba9fd0, pRotatedPixmap = 0x0, pCompositeClip = 0xb2e760}
(gdb) p *pRects
$3 = {x = 218, y = 127, width = 28, height = 14}
(gdb) frame 2
#2  0x000000000044edb1 in ProcPolyFillRectangle (client=0x919ad0) at dispatch.c:1795
1795    dispatch.c: No such file or directory.
        in dispatch.c
(gdb) p *client
$4 = {index = 19, clientAsMask = 39845888, requestBuffer = 0xb4c2a0, osPrivate = 0x91cfa0, swapped = 0, pSwapReplyFunc = 0x46e117 <CopySwap32Write>,
  errorValue = 39846056, sequence = 153259, closeDownMode = 0, clientGone = 0, noClientException = 0, saveSet = 0x0, numSaved = 0, screenPrivate = {0x0, 0x0,
    0x4d000000ff006200, 0x3900000044000000, 0x700000015000000, 0x1000000, 0x0, 0xff73e373ff006200, 0xff83eb83ff59d559, 0xf7a6eda6ff006200, 0xff006200ffbcfabc,
    0x1800000044000000, 0x20000000b000000, 0x0, 0x0, 0xff00620000000000}, requestVector = 0x835e60, req_len = 5, big_requests = 1, priority = 0,
  clientState = ClientStateRunning, devPrivates = 0x15b9750, xkbClientFlags = 32770, mapNotifyMask = 7, newKeyboardNotifyMask = 5, vMajor = 1, vMinor = 0,
  minKC = 8 '\b', maxKC = 255 '', replyBytesRemaining = 0, fontResFunc = 0, smart_priority = 20, smart_start_tick = 11680, smart_stop_tick = 11680,
  smart_check_tick = 11680}
(gdb) p *client->osPrivate
Attempt to dereference a generic pointer.
(gdb) p *client->requestBuffer
Attempt to dereference a generic pointer.
(gdb) p *client->devPrivates
$5 = {key = 0x83d3e8, value = 0x15b9768, next = 0x91ba80}
(gdb) p *client->devPrivates->next
$6 = {key = 0x0, value = 0x91ba98, next = 0x15b9710}
Can anyone make sense out of this? Of course, we don't have any debug info from the closed source binary, so GDB stops there.

We need to fix the crashes, Nvidia! I can provide more debugging info if someone can make a debug version of nvidia_drv.so for 177 beta drivers and attach here.
devsk is offline   Reply With Quote
Old 08-13-08, 05:52 PM   #24
devsk
Registered User
 
Join Date: Jun 2006
Posts: 46
Default Re: Spawning new session leads to crash

Hello! can someone please help me this issue? I built X in debug mode just to get a handle on this issue and now no one from nvidia wants to help me.

The problem is that the core dump happens inside nvidia code. And I don't know how to proceed because gdb stops there.
devsk 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


Similar Threads
Thread Thread Starter Forum Replies Last Post
Passion Leads Army: DX 11 and GPU PhysX Benchmark News Archived News Items 0 05-28-12 09:00 PM
Titan Supercomputer Session Showcases Science on GPUs News Archived News Items 0 05-16-12 04:30 AM
gf 6150se crash! oddhornedant NVIDIA Linux 2 05-05-12 06:30 AM
xvideo crash elanthis NVIDIA Linux 5 10-29-02 08:12 PM

All times are GMT -5. The time now is 04:08 PM.


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