Bug 528005 - X server crash
Summary: X server crash
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-nouveau
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Ben Skeggs
QA Contact: Fedora Extras Quality Assurance
Whiteboard: card_GeForce8600MGT
Depends On:
Blocks: fedora-x-blocker
TreeView+ depends on / blocked
Reported: 2009-10-08 15:14 UTC by David Woodhouse
Modified: 2009-11-02 21:34 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2009-11-02 21:34:38 UTC
Type: ---

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
FreeDesktop.org 24555 0 None None None Never

Description David Woodhouse 2009-10-08 15:14:33 UTC
gmpc's on-screen display plugin triggers a nouveau crash:

Program received signal SIGABRT, Aborted.
0x0000003a95e33575 in raise (sig=<value optimized out>)
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
64	  return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);
(gdb) bt
#0  0x0000003a95e33575 in raise (sig=<value optimized out>)
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x0000003a95e34d55 in abort () at abort.c:92
#2  0x0000003a95e2c655 in __assert_fail (assertion=0x7f26b358288a "ret == 0", 
    file=<value optimized out>, line=289, 
    function=0x7f26b3582910 "nouveau_pushbuf_flush") at assert.c:81
#3  0x00007f26b35810d1 in nouveau_pushbuf_flush (chan=0x902c50, min=951)
    at nouveau_pushbuf.c:289
#4  0x00007f26b37e8376 in WAIT_RING (size=<value optimized out>, chan=0x902c50)
    at /usr/include/nouveau/nouveau_pushbuf.h:79
#5  NV50EXAUploadSIFC (size=<value optimized out>, chan=0x902c50)
    at nv50_exa.c:399
#6  0x00007f26b37b9675 in nouveau_exa_upload_to_screen (pdpix=0x15edfd0, 
    x=<value optimized out>, y=4, w=950, h=1, 
    src=0x182ae48 "Dq\206\377Hu\212\377Kz\217\377L{\220\377M|\222\377P\177\225\377P\201\227\377M~\224\377R\203\231\377Q\202\230\377P\201\227\377O\200\226\377O\200\226\377P\201\227\377P\201\227\377Q\202\230\377Q\203\227\377O\201\225\377O~\223\377O~\223\377R\202\224\377T\204\226\377S\203\225\377S\201\223\377Q\177\220\377R~\217\377O{\214\377Kw\210\377Fr\203\377@l}\377=hy\377:ev\377:ev\377\065`q\377\064\\n\377\066^p\377\070`r\377\071as\377;cu\377=ew\377<bt\377<bt\377:`r\377\071_q\377:`r\377?ew\377Bhz\377Ci{\377@ey\377=bv\377"..., 
    src_pitch=<value optimized out>) at nouveau_exa.c:516
#7  0x00007f26b197a50f in exaCopyDirty (migrate=<value optimized out>, 
---Type <return> to continue, or q <return> to quit---
    pValidDst=<value optimized out>, pValidSrc=<value optimized out>, 
    transfer=0x7f26b37b9400 <nouveau_exa_upload_to_screen>, 
    fallback_index=<value optimized out>, sync=<value optimized out>)
    at exa_migration_classic.c:217
#8  0x00007f26b197c350 in exaDoMigration_mixed (pixmaps=<value optimized out>, 
    npixmaps=1, can_accel=<value optimized out>) at exa_migration_mixed.c:103
#9  0x00007f26b197c223 in exaMoveInPixmap_mixed (pPixmap=<value optimized out>)
    at exa_migration_mixed.c:120
#10 0x00007f26b1979032 in exaFinishAccess (pDrawable=<value optimized out>, 
    index=0) at exa.c:421
#11 0x00007f26b1984963 in ExaCheckPolyGlyphBlt (pDrawable=0x15edfd0, 
    pGC=0x15e43c0, x=906, y=23, nglyph=<value optimized out>, 
    ppci=<value optimized out>, pglyphBase=<value optimized out>)
    at exa_unaccel.c:286
#12 0x00000000004d51ea in damageText (pDrawable=<value optimized out>, 
    pGC=0x15e43c0, x=906, y=<value optimized out>, 
    count=<value optimized out>, chars=<value optimized out>, 
    fontEncoding=<value optimized out>, textType=<value optimized out>)
    at damage.c:1536
#13 0x00000000004d56d0 in damagePolyText8 (pDrawable=0x15edfd0, pGC=0x15e43c0, 
    x=<value optimized out>, y=23, count=1, chars=<value optimized out>)
    at damage.c:1554
#14 0x000000000042f4ac in doPolyText (client=0x15c4850, c=0x7fff0aba25b0)
---Type <return> to continue, or q <return> to quit---
    at dixfonts.c:1394
#15 0x000000000042fa50 in PolyText (client=<value optimized out>, 
    pDraw=<value optimized out>, pGC=<value optimized out>, 
    pElt=<value optimized out>, endReq=<value optimized out>, 
    xorg=<value optimized out>, yorg=<value optimized out>, 
    reqType=<value optimized out>, did=<value optimized out>)
    at dixfonts.c:1467
#16 0x000000000042ae4f in ProcPolyText (client=0x15c4850) at dispatch.c:2348
#17 0x000000000042c60c in Dispatch () at dispatch.c:445
#18 0x0000000000421c9a in main (argc=<value optimized out>, 
    argv=<value optimized out>, envp=<value optimized out>) at main.c:285

Macbook Pro, GeForce 8600M GT


Comment 1 David Woodhouse 2009-10-12 15:07:03 UTC
Problem persists with

Comment 2 David Woodhouse 2009-10-12 15:14:36 UTC
[drm] nouveau 0000:01:00.0: validate: -85

Comment 3 David Woodhouse 2009-10-12 21:33:57 UTC
That -ERESTART comes from ttm_bo_wait_cpu(). If I make it convert it to -EAGAIN instead (as nouveau_gem_ioctl_cpu_prep() does), the X server doesn't crash, but just goes into an endless loop doing the ioctl over and over again.

Comment 4 Adam Williamson 2009-10-23 21:24:05 UTC
Ben, have you had a minute to look? This is on the blocker list, and we (blocker bug review meeting) agree with that designation; please take a look at this before final code freeze for F12. the backtrace seems to provide enough info to look into this. thanks!

Fedora Bugzappers volunteer triage team

Comment 5 Ben Skeggs 2009-10-26 22:28:25 UTC
Yeah, I already looked :)  The issue is fixed as of xorg-x11-server-1.7.0-5.fc12 (http://koji.fedoraproject.org/koji/buildinfo?buildID=138021).

Comment 6 Adam Williamson 2009-10-30 21:24:33 UTC
David, could you please test that build and let us know ASAP? This is listed as an F12 blocker, we need to confirm and tag builds for F12 final in the next few days. Thanks a lot.

Fedora Bugzappers volunteer triage team

Comment 7 David Woodhouse 2009-10-31 10:04:08 UTC
Sorry for the delay. Yes, that build seems to fix it. Thanks.

Comment 8 Adam Williamson 2009-10-31 19:15:12 UTC
I submitted a tag request:


Fedora Bugzappers volunteer triage team

Comment 9 Bill Nottingham 2009-11-02 21:22:11 UTC
This build has been tagged - can we close this out?

Comment 10 Adam Williamson 2009-11-02 21:34:38 UTC
yes, indeed.

Fedora Bugzappers volunteer triage team

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