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 - Nouveau X server crashes shortly after GDM starts
Summary: Nouveau X server crashes shortly after GDM starts
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-nouveau
Version: rawhide
Hardware: All
OS: Linux
low
high
Target Milestone: ---
Assignee: Ben Skeggs
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: NeedsRetesting
Depends On:
Blocks: fedora-x-blocker
TreeView+ depends on / blocked
 
Reported: 2009-10-26 18:04 UTC by Ray Strode [halfline]
Modified: 2009-11-05 18:26 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-11-05 18:26:08 UTC
Type: ---
Embargoed:

Attachments (Terms of Use)
Xorg.0.log (deleted)
2009-10-26 18:04 UTC, Ray Strode [halfline] 		no flags Details
View All

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!
Note You need to log in before you can comment on or make changes to this bug.