Bug 219377 – nv lockup (from jorris@)

Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.

Bug 219377 - (nv-sync-of-doom) nv lockup (from jorris@)

Summary:	nv lockup (from jorris@)

Status:	CLOSED WONTFIX

Aliases:	nv-sync-of-doom

Product:	Fedora
Classification:	Fedora
Component:	xorg-x11-drv-nv (Show other bugs)
Sub Component:
Version:	9
Hardware:	x86_64 Linux

Priority	medium Severity medium
Target Milestone:	---
Target Release:	---
Assigned To:	Adam Jackson
QA Contact:
Docs Contact:

URL:
Whiteboard:
Keywords:

Duplicates:	210584 248373 315861 (view as bug list)
Depends On:
Blocks:
	Show dependency tree / graph

Reported:	2006-12-12 15:38 EST by Adam Jackson
Modified:	2018-04-11 03:55 EDT (History)
CC List:	8 users (show)

See Also:
Fixed In Version:
Doc Type:	Bug Fix
Doc Text:
Story Points:	---
Clone Of:
Environment:
Last Closed:	2009-07-14 12:48:03 EDT
Type:	---
Regression:	---
Mount Type:	---
Documentation:	---
CRM:
Verified Versions:
Category:	---
oVirt Team:	---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---

Attachments	(Terms of Use)
Add an attachment (proposed patch, testcase, etc.)

Groups: None (edit)

Description Adam Jackson 2006-12-12 15:38:28 EST

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...

Comment 1 Adam Jackson 2006-12-12 15:42:37 EST

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

Comment 5 Jon Orris 2007-01-31 15:03:12 EST

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.

Comment 6 Adam Jackson 2007-04-30 16:57:04 EDT

Moving to devel, this seems like a problem there too.

Comment 7 Chris Lumens 2007-04-30 17:01:13 EDT

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

Comment 8 Nate Straz 2007-07-25 12:04:01 EDT

*** Bug 248373 has been marked as a duplicate of this bug. ***

Comment 9 Chris Lumens 2007-09-11 15:36:03 EDT

I haven't seen this in quite a while now.  Removing myself from the CC...

Comment 10 Adam Jackson 2007-10-02 15:51:08 EDT

*** Bug 315861 has been marked as a duplicate of this bug. ***

Comment 11 Matěj Cepl 2007-10-02 16:22:57 EDT

*** Bug 210584 has been marked as a duplicate of this bug. ***

Comment 12 Don Zickus 2007-10-12 15:10:34 EDT

just hit this twice within 10 minutes.
both times i was using gitk and scrolling the the kernel commit history.

Comment 13 Don Zickus 2007-10-12 15:22:36 EDT

make it a third time while browsing my mail with mutt

Comment 15 Don Zickus 2008-02-10 23:48:31 EST

In case anyone cares, I can reproduce this at will by ssh'ing into my box and
running mutt.

Comment 16 Charlie Brady 2008-02-13 10:16:40 EST

(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.

Comment 17 Don Zickus 2008-02-13 10:32:00 EST

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.

Comment 18 Bug Zapper 2008-05-13 22:29:56 EDT

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

Comment 19 Nate Straz 2008-10-20 09:14:49 EDT

I seem to be hitting this more often with the RHEL 5.3 Client Beta bits.

Comment 20 Don Zickus 2008-10-20 11:01:50 EDT

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

Comment 21 Bug Zapper 2009-06-09 18:22:16 EDT

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

Comment 22 Bug Zapper 2009-07-14 12:48:03 EDT

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.

Note You need to log in before you can comment on or make changes to this bug.