Bug 219377 (nv-sync-of-doom)
| Summary: | nv lockup (from jorris@) | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Adam Jackson <ajax> |
| Component: | xorg-x11-drv-nv | Assignee: | Adam Jackson <ajax> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 9 | CC: | charlieb-fedora-bugzilla, djansa, duffy, dzickus, jorris, mcepl, nstraz, xgl-maint |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2009-07-14 16:48:03 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Also of note is that gdb is trash and won't let you inspect *pNv->REGS, at least with: gdb-6.5-15.el5 kernel-xen-2.6.18-1.2767.el5 Gives you something special like: (gdb) set debug target 1 (gdb) print *pNv->REGS child:target_xfer_partial (2, (null), 0x2afadd0, 0x0, 0x9f7818, 8) = 8, bytes = 00 50 af ac aa 2a 00 00 child:target_xfer_partial (2, (null), 0x2da61b0, 0x0, 0x2aaaacaf5000, 4) = 0 exec:target_xfer_partial (2, (null), 0x2da61b0, 0x0, 0x2aaaacaf5000, 4) = 0 None:target_xfer_partial (2, (null), 0x2da61b0, 0x0, 0x2aaaacaf5000, 4) = -1 Cannot access memory at address 0x2aaaacaf5000 The machine may make me a liar in a minute, but it seems more stable now that I've booted into the non-xen 2.6.18-6.el5 kernel. Running xen, its crashed on me 4 times today within 10-15 minutes. Moving to devel, this seems like a problem there too. Updated backtrace, as it looks like a different codepath.
#0 0x008de652 in NVSync () from /usr/lib/xorg/modules/drivers//nv_drv.so
#1 0x00e65379 in XAAGetImage (pDraw=0xa0aadc0, sx=503, sy=66, w=8, h=24,
format=2, planemask=4294967295, pdstLine=0xbfa2b390 "\035") at xaaInit.c:321
#2 0x08119758 in miBSGetImage (pDrawable=0xa0aadc0, sx=503, sy=66, w=8, h=24,
format=2, planemask=4294967295, pdstLine=0xbfa2b390 "\035") at mibstore.c:609
#3 0x08173113 in cwGetImage (pSrc=0xa0aadc0, x=503, y=66, w=8, h=24, format=2,
planemask=4294967295, pdstLine=0xbfa2b390 "\035") at cw.c:357
#4 0x0812e1dd in miSpriteGetImage (pDrawable=0xa0aadc0, sx=503, sy=66, w=8,
h=24, format=2, planemask=4294967295, pdstLine=0xbfa2b390 "\035") at misprite.c:299
#5 0x08086e75 in DoGetImage (client=0x96ddb38, format=2, drawable=41374925,
x=503, y=66, width=8, height=10448, planemask=4294967295, im_return=0x0) at
dispatch.c:2233
#6 0x08087076 in ProcGetImage (client=0xb75db044) at dispatch.c:2326
#7 0x0814ec91 in XaceCatchDispatchProc (client=0x96ddb38) at xace.c:281
#8 0x0808930a in Dispatch () at dispatch.c:457
#9 0x08071045 in main (argc=9, argv=0xbfa2bca4, envp=Cannot access memory at
address 0xb75db04c
) at main.c:445
*** Bug 248373 has been marked as a duplicate of this bug. *** I haven't seen this in quite a while now. Removing myself from the CC... *** Bug 315861 has been marked as a duplicate of this bug. *** *** Bug 210584 has been marked as a duplicate of this bug. *** just hit this twice within 10 minutes. both times i was using gitk and scrolling the the kernel commit history. make it a third time while browsing my mail with mutt In case anyone cares, I can reproduce this at will by ssh'ing into my box and running mutt. (In reply to comment #15) > In case anyone cares, I can reproduce this at will by ssh'ing into my box and > running mutt. I certainly hope that someone cares, since this is a flaw which requires power cycle restart to work around. I work around it by killing the X server. Usually I am already remotely logged in when the problem happens so a 'kill -p <pid>' fixes my problem. Then later I just have to login as usual and painfully setup my work environment again. Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping I seem to be hitting this more often with the RHEL 5.3 Client Beta bits. I'm not sure what happened but upgrading to Fedora 9 (and using a newer proprietary NV driver) has made this problem go away for me (I was using Fedora 7/8). Of course this doesn't solve the RHEL-5 problems, but just something to note. -Don This message is a reminder that Fedora 9 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 9. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '9'. 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 prior to Fedora 9's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 9 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 please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. 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. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 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. Thank you for reporting this bug and we are sorry it could not be fixed. |
Description of problem: Lockup while switching desktops. Something like: #0 0x00002aaaac054c49 in NVSync (pScrn=0x9f6f40) at nv_xaa.c:305 pNv = (NVPtr) 0x9f7670 #1 0x00002aaaae14dbb6 in XAACopyAreaFallback (pSrc=0x1f04ba0, pDst=0x107a6f0, pGC=0x1db3360, srcx=0, srcy=0, width=1280, height=24, dstx=0, dsty=0) at xaaFallback.c:84 infoRec = (XAAInfoRecPtr) 0xa27840 ret = (RegionPtr) 0x2200 pGCPriv = (XAAGCPtr) 0x1db3450 oldFuncs = (GCFuncs *) 0x7b6cc0 #2 0x0000000000512b94 in cwCopyArea (pSrc=0x1f04ba0, pDst=0x107a6f0, pGC=0x1db3360, srcx=0, srcy=0, w=1280, h=24, dstx=0, dsty=0) at cw_ops.c:202 pGCPrivate = (cwGCPtr) 0x1db3498 dst_off_x = 0 dst_off_y = 0 pBackingDst = (DrawablePtr) 0x107a6f0 pBackingGC = (GCPtr) 0x1db3360 src_off_x = 0 src_off_y = 0 pBackingSrc = (DrawablePtr) 0x1f04ba0 #3 0x000000000050e713 in damageCopyArea (pSrc=0x1f04ba0, pDst=0x107a6f0, pGC=0x1db3360, srcx=0, srcy=0, width=1280, height=24, dstx=0, dsty=0) at damage.c:790 ret = (RegionPtr) 0x2200 pGCPriv = (DamageGCPrivPtr) 0x1db3488 oldFuncs = (GCFuncs *) 0x7b7720 #4 0x00000000004480ae in ProcCopyArea (client=0xab1f70) at dispatch.c:1743 pDst = (DrawablePtr) 0x107a6f0 pSrc = (DrawablePtr) 0x9f6f40 pGC = (GC *) 0x1db3360 pRgn = <value optimized out> #5 0x0000000000449c9a in Dispatch () at dispatch.c:459 clientReady = <value optimized out> result = <value optimized out> client = <value optimized out> nready = 0 start_tick = 1089520 #6 0x00000000004325d5 in main (argc=10, argv=0x7fffd14afe08, envp=<value optimized out>) at main.c:447 pScreen = <value optimized out> i = 1 error = 0 xauthfile = <value optimized out> alwaysCheckForInput = {0, 1} xorg-x11-server-Xorg-1.1.1-48.5.el5 xorg-x11-drv-nv-1.2.0-4.fc6 On amd64, but doesn't look platform specific. nv_xaa.c:305 is just the infinite loop waiting for the instruction breadcrumb to catch up. Don't have an immediate solution for this, but it looks like there's been a bit of work in this area in nouveau. In particular the "dma" queue is sized differently, and there's some timeout code for when things go south. That plus a GPU reset could be good enough...