Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.

Bug 531058

Summary: Nouveau X server crashes shortly after GDM starts
Product: [Fedora] Fedora Reporter: Ray Strode [halfline] <rstrode>
Component: xorg-x11-drv-nouveauAssignee: Ben Skeggs <bskeggs>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: low    
Version: rawhideCC: airlied, ajax, awilliam, bskeggs, jmccann, notting
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard: NeedsRetesting
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-11-05 18:26:08 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:
Bug Depends On:    
Bug Blocks: 530341    
Attachments:
Description Flags
Xorg.0.log none

Description Ray Strode [halfline] 2009-10-26 18:04:06 UTC
Created attachment 366133 [details]
Xorg.0.log

I got handed a laptop this morning with a crashing GDM login screen.  It seems to be the X server that's actually taking a nose dive though.  This is on a livecd.

Backtrace:
(gdb) t a a bt full

Thread 1 (Thread 0xb7823760 (LWP 2812)):
#0  0x00acf416 in __kernel_vsyscall ()
No symbol table info available.
#1  0x00afbad1 in raise () from /lib/libc.so.6
No symbol table info available.
#2  0x00afd39a in abort () from /lib/libc.so.6
No symbol table info available.
#3  0x00af4c78 in __assert_fail () from /lib/libc.so.6
No symbol table info available.
#4  0x0048c0ad in nouveau_pushbuf_emit_reloc (chan=<value optimized out>, ptr=<value optimized out>, bo=<value optimized out>, data=<value optimized out>, data2=<value optimized out>, 
    flags=<value optimized out>, vor=<value optimized out>, tor=<value optimized out>) at nouveau_pushbuf.c:81
        nvpb = 0x9f47b78
        r = <value optimized out>
        pbbo = <value optimized out>
        domains = 0
        __PRETTY_FUNCTION__ = "nouveau_pushbuf_emit_reloc"
#5  0x007a8f44 in xf86XVListGenericAdaptors () at xf86xv.c:156
No symbol table info available.
#6  0x00856d78 in exaFillRegionTiled (pDrawable=<value optimized out>, pRegion=<value optimized out>, pTile=<value optimized out>, pPatOrg=<value optimized out>, planemask=<value optimized out>, 
    alu=<value optimized out>, clientClipType=<value optimized out>) at exa_accel.c:1107
        pExaScr = <value optimized out>
        pPixmap = 0x6
        pExaPixmap = <value optimized out>
        xoff = <value optimized out>
        yoff = <value optimized out>
        tileWidth = 1920
        tileHeight = 1200
        nbox = 1
        pBox = 0xbfa2cd6c
        ret = 0
        i = <value optimized out>
#7  0x0085ce1a in exaComposite (op=<value optimized out>, pSrc=<value optimized out>, pMask=<value optimized out>, pDst=<value optimized out>, xSrc=<value optimized out>, ySrc=<value optimized out>, 
    xMask=<value optimized out>, yMask=<value optimized out>, xDst=<value optimized out>, yDst=<value optimized out>, width=<value optimized out>, height=<value optimized out>) at exa_render.c:990
        patOrg = {x = 0, y = 0}
        pExaScr = <value optimized out>
        ret = <value optimized out>
        saveSrcRepeat = <value optimized out>
        saveMaskRepeat = 0
        region = {extents = {x1 = 0, y1 = 0, x2 = 1920, y2 = 1920}, data = 0x0}
#8  0x0811b977 in damageComposite (op=<value optimized out>, pSrc=<value optimized out>, pMask=<value optimized out>, pDst=<value optimized out>, xSrc=<value optimized out>, ySrc=<value optimized out>, 
    xMask=<value optimized out>, yMask=<value optimized out>, xDst=<value optimized out>, yDst=<value optimized out>, width=<value optimized out>, height=<value optimized out>) at damage.c:643
        ps = 0x9f59cf0
        pScrPriv = <value optimized out>
#9  0x0810ee70 in CompositePicture (op=<value optimized out>, pSrc=<value optimized out>, pMask=<value optimized out>, pDst=<value optimized out>, xSrc=<value optimized out>, 
    ySrc=<value optimized out>, xMask=<value optimized out>, yMask=<value optimized out>, xDst=<value optimized out>, yDst=<value optimized out>, width=<value optimized out>, 
    height=<value optimized out>) at picture.c:1718
        ps = <value optimized out>
#10 0x081150a5 in ProcRenderComposite (client=<value optimized out>) at render.c:723
        pSrc = 0xa159040
        pMask = 0x0
        pDst = 0xa1593d8
#11 0x08111c34 in ProcRenderDispatch (client=<value optimized out>) at render.c:2056
No locals.
#12 0x0806e187 in Dispatch () at dispatch.c:445
        result = <value optimized out>
        client = 0xa11a6b8
        nready = <value optimized out>
        start_tick = 900
#13 0x08062875 in main (argc=<value optimized out>, argv=<value optimized out>, envp=<value optimized out>) at main.c:285
        i = <value optimized out>
        alwaysCheckForInput = {0, 1}


Frame 5 looks pretty bogus.

Laptop is a dell d800.

01:00.0 VGA compatible controller: nVidia Corporation NV34M [GeForce FX Go5200 64M] (rev a1)

I'll attach Xorg.0.log.

Adding to blocker list, but I don't know how widespread the problem is.

Relevant package versions:

gdm-2.28.1-9.fc12.i686
kernel-2.6.31.5-96.fc12.i686
libdrm-2.4.15-1.fc12.i686
xorg-x11-drv-nouveau-0.0.15-13.20090929gitdd8339f.fc12.i686

Comment 1 Ray Strode [halfline] 2009-10-26 18:20:07 UTC
It seems like this may related to the background crossfade that gnome-settings-daemon does shortly after gdm is started.

Comment 2 jmccann 2009-10-26 18:57:13 UTC
When booting with nomodeset this doesn't seem to occur.

Comment 3 Ray Strode [halfline] 2009-10-27 03:17:34 UTC

*** This bug has been marked as a duplicate of bug 530169 ***

Comment 4 Ben Skeggs 2009-11-02 08:07:20 UTC
I don't believe this is a duplicate of 530169, and more likely another symptom of an X server bug I fixed a while back.  To confirm, can you update to at least xorg-x11-server-1.7.0-5 from koji and see if the problem goes away?

Thanks!
Ben.

Comment 5 Adam Williamson 2009-11-02 22:01:07 UTC
ah, that one.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 6 Bill Nottingham 2009-11-03 21:02:22 UTC
Given comment #4, marking as MODIFIED. Can go to NEW/ASSIGNED if testing fails.

Comment 7 Ray Strode [halfline] 2009-11-03 21:15:46 UTC
it fails in exactly the same way with -5 unfortunately.

Comment 8 Adam Williamson 2009-11-04 23:57:32 UTC
I'm going to stick up some test packages Ben's sending over to me for you to test. They should hide this issue (they don't really fix it, but stuff should work). stand by, incoming in about a half hour i'd guess.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 9 Adam Williamson 2009-11-05 06:35:37 UTC
Actually, in the end we tagged them anyway. Can you please try:

http://koji.fedoraproject.org/koji/buildinfo?buildID=139807
(libdrm-2.4.15-4.fc12)
http://koji.fedoraproject.org/koji/buildinfo?buildID=139811
(xorg-x11-drv-nouveau-0.0.15-17)

and report back if they work? Thanks!

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 10 Ray Strode [halfline] 2009-11-05 18:26:08 UTC
Tested latest libdrm, nouveau and xorg.  They seem to work fine!