Bug 605432 - [NVaa] Xorg hangs with message: [mi] EQ overflowing. The server is probably stuck in an infinite loop
[NVaa] Xorg hangs with message: [mi] EQ overflowing. The server is probably s...
Status: CLOSED DUPLICATE of bug 465884
Product: Fedora
Classification: Fedora
Component: libdrm (Show other bugs)
13
i686 Linux
low Severity medium
: ---
: ---
Assigned To: Ben Skeggs
Fedora Extras Quality Assurance
: Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-06-17 18:16 EDT by fedoraproject
Modified: 2011-03-06 18:46 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-03-06 18:39:30 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Xorg log file (215.45 KB, text/plain)
2010-06-23 08:18 EDT, fedoraproject
no flags Details
log from dmesg (1.94 MB, text/plain)
2010-06-23 14:51 EDT, fedoraproject
no flags Details
var log messages (except dmesg) (88.02 KB, text/plain)
2010-06-23 14:53 EDT, fedoraproject
no flags Details
Script session with the end of dmesg, and Xorg.0.log (525.52 KB, text/plain)
2010-06-23 14:56 EDT, fedoraproject
no flags Details
clean boot Xorg log (150.29 KB, text/plain)
2010-07-29 19:47 EDT, Steve Walsh
no flags Details
dmesg (44.57 KB, text/plain)
2010-07-29 19:48 EDT, Steve Walsh
no flags Details
Xorg.log with crash data (173.36 KB, text/plain)
2010-07-29 19:48 EDT, Steve Walsh
no flags Details
dmesg output (33.29 KB, text/plain)
2010-10-27 07:43 EDT, John Sullivan
no flags Details

  None (edit)
Description fedoraproject 2010-06-17 18:16:00 EDT
Description of problem:

Xorg hangs.


Version-Release number of selected component (if applicable):

# rpm -qif /usr/include/nouveau/nouveau_pushbuf.h 
Name        : libdrm-devel                 Relocations: (not relocatable)
Version     : 2.4.20                            Vendor: Fedora Project
Release     : 1.fc13                        Build Date: Thu 08 Apr 2010 05:33:15 AM BRT

Name        : xorg-x11-drv-nouveau         Relocations: (not relocatable)
Version     : 0.0.16                            Vendor: Fedora Project
Release     : 6.20100423git13c1043.fc13     Build Date: Wed 12 May 2010 08:32:09 PM BRT

Name        : glibc                        Relocations: (not relocatable)
Version     : 2.12                              Vendor: Fedora Project
Release     : 2                             Build Date: Wed 02 Jun 2010 01:06:39 AM BRT

Name        : kernel-PAE                   Relocations: (not relocatable)
Version     : 2.6.33.5                          Vendor: Fedora Project
Release     : 112.fc13                      Build Date: Thu 27 May 2010 12:53:35 AM BRT

Name        : xorg-x11-server-Xorg         Relocations: (not relocatable)
Version     : 1.8.0                             Vendor: Fedora Project
Release     : 12.fc13                       Build Date: Sun 02 May 2010 11:58:36 AM BRT



How reproducible:


Steps to Reproduce:
1. Log in into gnome
2. Change wallpapers a few times
  
Actual results:
Xorg hangs.
No response from keyboard, but the mouse still moves.
SysRq still works, 
It is possible to login using ssh.
ctrl+alt+f2 , ctrl-alt-backspace don't work.
chvt don't work also.

If Xorg is killed (killall -9 Xorg), the image in the video became shifted, and the system hangs even more (no more ssh, but it's possible to reboot using SysRq+B).


Expected results:


Additional info:[   489.854] (II) NOUVEAU(0): Printing probed modes for output HDMI-1
[   489.854] (II) NOUVEAU(0): Modeline "1280x1024"x60.0  108.00  1280 1328 1440 1688  1024 1025 1028 1066 +hsync +vsync (64.0 k
Hz)
[   489.854] (II) NOUVEAU(0): Modeline "1152x864"x75.0  108.00  1152 1216 1344 1600  864 865 868 900 +hsync +vsync (67.5 kHz)
[   489.854] (II) NOUVEAU(0): Modeline "1024x768"x75.1   78.80  1024 1040 1136 1312  768 769 772 800 +hsync +vsync (60.1 kHz)
[   489.854] (II) NOUVEAU(0): Modeline "1024x768"x75.0   78.75  1024 1040 1136 1312  768 769 772 800 +hsync +vsync (60.0 kHz)
[   489.854] (II) NOUVEAU(0): Modeline "1024x768"x60.0   65.00  1024 1048 1184 1344  768 771 777 806 -hsync -vsync (48.4 kHz)
[   489.854] (II) NOUVEAU(0): Modeline "832x624"x74.6   57.28  832 864 928 1152  624 625 628 667 -hsync -vsync (49.7 kHz)
[   489.854] (II) NOUVEAU(0): Modeline "800x600"x75.0   49.50  800 816 896 1056  600 601 604 625 +hsync +vsync (46.9 kHz)
[   489.854] (II) NOUVEAU(0): Modeline "800x600"x60.3   40.00  800 840 968 1056  600 601 605 628 +hsync +vsync (37.9 kHz)
[   489.854] (II) NOUVEAU(0): Modeline "640x480"x75.0   31.50  640 656 720 840  480 481 484 500 -hsync -vsync (37.5 kHz)
[   489.854] (II) NOUVEAU(0): Modeline "640x480"x60.0   25.20  640 656 752 800  480 490 492 525 -hsync -vsync (31.5 kHz)
[   489.854] (II) NOUVEAU(0): Modeline "720x400"x70.1   28.32  720 738 846 900  400 412 414 449 -hsync +vsync (31.5 kHz)
[  7170.475] [mi] EQ overflowing. The server is probably stuck in an infinite loop.
[  7170.476] 
Backtrace:
[  7170.491] 0: /usr/bin/Xorg (xorg_backtrace+0x3c) [0x80e51dc]
[  7170.491] 1: /usr/bin/Xorg (mieqEnqueue+0x1b7) [0x80e4ae7]
[  7170.491] 2: /usr/bin/Xorg (xf86PostMotionEventP+0xd2) [0x80be302]
[  7170.491] 3: /usr/lib/xorg/modules/input/evdev_drv.so (0xa26000+0x30a2) [0xa290a2]
[  7170.491] 4: /usr/lib/xorg/modules/input/evdev_drv.so (0xa26000+0x3349) [0xa29349]
[  7170.491] 5: /usr/bin/Xorg (0x8047000+0x69aa0) [0x80b0aa0]
[  7170.491] 6: /usr/bin/Xorg (0x8047000+0x11f8f4) [0x81668f4]
[  7170.491] 7: (vdso) (__kernel_sigreturn+0x0) [0x669400]
[  7170.491] 8: /usr/lib/xorg/modules/drivers/nouveau_drv.so (0x2ee000+0x1c324) [0x30a324]
[  7170.491] 9: /usr/lib/xorg/modules/drivers/nouveau_drv.so (0x2ee000+0x1d840) [0x30b840]
[  7170.491] 10: /usr/lib/xorg/modules/drivers/nouveau_drv.so (0x2ee000+0x1d96f) [0x30b96f]
[  7170.491] 11: /usr/lib/libdrm_nouveau.so.1 (nouveau_pushbuf_flush+0x1dd) [0x1d802d]
[  7170.491] 12: /usr/lib/xorg/modules/drivers/nouveau_drv.so (0x2ee000+0x1b73f) [0x30973f]
[  7170.491] 13: /usr/lib/xorg/modules/libexa.so (0x826000+0x8ab3) [0x82eab3]
[  7170.491] 14: /usr/lib/xorg/modules/libexa.so (0x826000+0x9663) [0x82f663]
[  7170.491] 15: /usr/bin/Xorg (0x8047000+0xd5296) [0x811c296]
[  7170.491] 16: /usr/lib/xorg/modules/libexa.so (0x826000+0xa861) [0x830861]
[  7170.491] 17: /usr/bin/Xorg (0x8047000+0xd4d15) [0x811bd15]
[  7170.491] 18: /usr/bin/Xorg (CompositeGlyphs+0xa7) [0x81b5ba7]
[  7170.491] 19: /usr/bin/Xorg (0x8047000+0xcec7f) [0x8115c7f]
[  7170.491] 20: /usr/bin/Xorg (0x8047000+0xca824) [0x8111824]
[  7170.491] 21: /usr/bin/Xorg (0x8047000+0x26f37) [0x806df37]
[  7170.491] 22: /usr/bin/Xorg (0x8047000+0x1b675) [0x8062675]
[  7170.491] 23: /lib/libc.so.6 (__libc_start_main+0xe6) [0xc10cc6]
[  7170.491] 24: /usr/bin/Xorg (0x8047000+0x1b261) [0x8062261]

[root@localhost ~]# gdb /usr/bin/Xorg 
ESC[?1034hGNU gdb (GDB) Fedora (7.1-26.fc13)
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/bin/Xorg...Reading symbols from /usr/lib/debug/usr/bin/Xorg.debug...done.
done.
a(gdb) attach 1850
Attaching to program: /usr/bin/Xorg, process 1850
Reading symbols from /lib/libudev.so.0...warning: the debug information found in "/usr/lib/debug//lib/libudev.so.0.6.1.debug" does not match "/lib/libudev.so.0" (CRC mismatch).

warning: the debug information found in "/usr/lib/debug/lib/libudev.so.0.6.1.debug" does not match "/lib/libudev.so.0" (CRC mismatch).

0x0032c324 in OUT_RING (ppix=0x8ff1288, is_src=0) at /usr/include/nouveau/nouveau_pushbuf.h:67
67              *(chan->cur++) = (data);
Missing separate debuginfos, use: debuginfo-install libudev-151-10.fc13.i686 openssl-1.0.0a-1.fc13.i686
(gdb) bt
#0  0x0032c324 in OUT_RING (ppix=0x8ff1288, is_src=0) at /usr/include/nouveau/nouveau_pushbuf.h:67
#1  NV50EXAAcquireSurface2D (ppix=0x8ff1288, is_src=0) at nv50_exa.c:130
#2  0x0032d840 in NV50EXAPrepareSolid (pdpix=0x8ff1288, alu=3, planemask=4294967295, fg=0) at nv50_exa.c:235
#3  0x0032d96f in NV50EXAStateSolidResubmit (chan=0x87b3198) at nv50_exa.c:219
#4  0x00f9c02d in nouveau_pushbuf_flush (chan=0x87b3198, min=0) at nouveau_pushbuf.c:276
#5  0x0032b73f in FIRE_RING (pdpix=0x8ff1288, x1=0, y1=0, x2=56, y2=11) at /usr/include/nouveau/nouveau_pushbuf.h:121
#6  NV50EXASolid (pdpix=0x8ff1288, x1=0, y1=0, x2=56, y2=11) at nv50_exa.c:268
#7  0x00b80ab3 in exaFillRegionSolid (pDrawable=0x8ff1288, pRegion=0x8be9d30, pixel=0, planemask=4294967295, alu=3, clientClipType=0) at exa_accel.c:1038
#8  0x00b81663 in exaPolyFillRect (pDrawable=0x8ff1288, pGC=0x87ea780, nrect=1, prect=0xbfe0e910) at exa_accel.c:819
#9  0x0811c296 in damagePolyFillRect (pDrawable=0x8ff1288, pGC=0x87ea780, nRects=1, pRects=0xbfe0e910) at damage.c:1404
#10 0x00b82861 in exaGlyphs (op=3 '\003', pSrc=0x90524c0, pDst=0x9095578, maskFormat=0x87c7620, xSrc=61, ySrc=424, nlist=1, list=0xbfe0eec0, glyphs=0xbfe0eac0)
    at exa_glyphs.c:789
#11 0x0811bd15 in damageGlyphs (op=3 '\003', pSrc=0x90524c0, pDst=0x9095578, maskFormat=0x87c7620, xSrc=61, ySrc=424, nlist=1, list=0xbfe0eec0, glyphs=0xbfe0eac0)
    at damage.c:721
#12 0x081b5ba7 in CompositeGlyphs (op=3 '\003', pSrc=0x90524c0, pDst=0x9095578, maskFormat=0x87c7620, xSrc=61, ySrc=424, nlist=1, lists=0xbfe0eec0, glyphs=0xbfe0eac0)
    at glyph.c:619
#13 0x08115c7f in ProcRenderCompositeGlyphs (client=0x89fcb30) at render.c:1430
#14 0x08111824 in ProcRenderDispatch (client=0x89fcb30) at render.c:2056
#15 0x0806df37 in Dispatch () at dispatch.c:439
#16 0x08062675 in main (argc=9, argv=0xbfe0f384, envp=0xbfe0f3ac) at main.c:286
(gdb) info threads
* 1 Thread 0xb772db60 (LWP 1850)  0x0032c324 in OUT_RING (ppix=0x8ff1288, is_src=0) at /usr/include/nouveau/nouveau_pushbuf.h:67

(gdb) list
67              *(chan->cur++) = (data);
68      }
69      
70      static __inline__ void
71      OUT_RINGp(struct nouveau_channel *chan, const void *data, unsigned size)
72      {
73              memcpy(chan->cur, data, size * 4);
74              chan->cur += size;
75      }
76      
(gdb) up
#1  NV50EXAAcquireSurface2D (ppix=0x8ff1288, is_src=0) at nv50_exa.c:130
130                     OUT_RING  (chan, 0);
(gdb) list
125                     BEGIN_RING(chan, eng2d, mthd + 0x14, 1);
126                     OUT_RING  (chan, (uint32_t)exaGetPixmapPitch(ppix));
127             } else {
128                     BEGIN_RING(chan, eng2d, mthd, 5);
129                     OUT_RING  (chan, fmt);
130                     OUT_RING  (chan, 0);
131                     OUT_RING  (chan, bo->tile_mode << 4);
132                     OUT_RING  (chan, 1);
133                     OUT_RING  (chan, 0);
134             }
(gdb) up
#2  0x0032d840 in NV50EXAPrepareSolid (pdpix=0x8ff1288, alu=3, planemask=4294967295, fg=0) at nv50_exa.c:235
235             if (!NV50EXAAcquireSurface2D(pdpix, 0)) {
(gdb) list
230                     NOUVEAU_FALLBACK("rect format\n");
231     
232             if (MARK_RING(chan, 64, 4))
233                     NOUVEAU_FALLBACK("ring space\n");
234     
235             if (!NV50EXAAcquireSurface2D(pdpix, 0)) {
236                     MARK_UNDO(chan);
237                     NOUVEAU_FALLBACK("dest pixmap\n");
238             }
239     
(gdb) up
#3  0x0032d96f in NV50EXAStateSolidResubmit (chan=0x87b3198) at nv50_exa.c:219
219             NV50EXAPrepareSolid(pNv->pdpix, pNv->alu, pNv->planemask,
(gdb) list
214     NV50EXAStateSolidResubmit(struct nouveau_channel *chan)
215     {
216             ScrnInfoPtr pScrn = chan->user_private;
217             NVPtr pNv = NVPTR(pScrn);
218     
219             NV50EXAPrepareSolid(pNv->pdpix, pNv->alu, pNv->planemask,
220                                 pNv->fg_colour);
221     }
222     
223     Bool
(gdb) up
#4  0x00f9c02d in nouveau_pushbuf_flush (chan=0x87b3198, min=0) at nouveau_pushbuf.c:276
276                     chan->flush_notify(chan);
(gdb) list
271     
272             /* Allocate space for next push buffer */
273             assert(!nouveau_pushbuf_space(chan, min));
274     
275             if (chan->flush_notify)
276                     chan->flush_notify(chan);
277     
278             nvpb->marker = NULL;
279             return ret;
280     }
(gdb) up
#5  0x0032b73f in FIRE_RING (pdpix=0x8ff1288, x1=0, y1=0, x2=56, y2=11) at /usr/include/nouveau/nouveau_pushbuf.h:121
121             nouveau_pushbuf_flush(chan, 0);
(gdb) list
116     }
117     
118     static __inline__ void
119     FIRE_RING(struct nouveau_channel *chan)
120     {
121             nouveau_pushbuf_flush(chan, 0);
122     }
123     
124     static __inline__ void
125     BIND_RING(struct nouveau_channel *chan, struct nouveau_grobj *gr, unsigned sc)
(gdb) up
#6  NV50EXASolid (pdpix=0x8ff1288, x1=0, y1=0, x2=56, y2=11) at nv50_exa.c:268
268                     FIRE_RING (chan);
(gdb) list
263             OUT_RING  (chan, y1);
264             OUT_RING  (chan, x2);
265             OUT_RING  (chan, y2);
266     
267             if((x2 - x1) * (y2 - y1) >= 512)
268                     FIRE_RING (chan);
269     }
270     
271     void
272     NV50EXADoneSolid(PixmapPtr pdpix)
(gdb) up
#7  0x00b80ab3 in exaFillRegionSolid (pDrawable=0x8ff1288, pRegion=0x8be9d30, pixel=0, planemask=4294967295, alu=3, clientClipType=0) at exa_accel.c:1038
1038                (*pExaScr->info->Solid) (pPixmap, pBox->x1, pBox->y1, pBox->x2,
(gdb) list
1033            nbox = REGION_NUM_RECTS (pRegion);
1034            pBox = REGION_RECTS (pRegion);
1035    
1036            while (nbox--)
1037            {
1038                (*pExaScr->info->Solid) (pPixmap, pBox->x1, pBox->y1, pBox->x2,
1039                                         pBox->y2);
1040                pBox++;
1041            }
1042            (*pExaScr->info->DoneSolid) (pPixmap);
(gdb) up
#8  0x00b81663 in exaPolyFillRect (pDrawable=0x8ff1288, pGC=0x87ea780, nrect=1, prect=0xbfe0e910) at exa_accel.c:819
819                                     pGC->alu, pGC->clientClipType)) ||
(gdb) list
814              pGC->alu == GXnoop || pGC->alu == GXcopyInverted ||
815              pGC->alu == GXset)) {
816             if (((pGC->fillStyle == FillSolid || pGC->tileIsPixel) &&
817                  exaFillRegionSolid(pDrawable, pReg, pGC->fillStyle == FillSolid ?
818                                     pGC->fgPixel : pGC->tile.pixel, pGC->planemask,
819                                     pGC->alu, pGC->clientClipType)) ||
820                 (pGC->fillStyle == FillTiled && !pGC->tileIsPixel &&
821                  exaFillRegionTiled(pDrawable, pReg, pGC->tile.pixmap, &pGC->patOrg,
822                                     pGC->planemask, pGC->alu,
823                                     pGC->clientClipType))) {
(gdb) up
#9  0x0811c296 in damagePolyFillRect (pDrawable=0x8ff1288, pGC=0x87ea780, nRects=1, pRects=0xbfe0e910) at damage.c:1404
1404        (*pGC->ops->PolyFillRect)(pDrawable, pGC, nRects, pRects);
(gdb) liESC[Kst
1399    
1400            TRIM_AND_TRANSLATE_BOX(box, pDrawable, pGC);
1401            if(BOX_NOT_EMPTY(box))
1402                damageDamageBox (pDrawable, &box, pGC->subWindowMode);
1403        }
1404        (*pGC->ops->PolyFillRect)(pDrawable, pGC, nRects, pRects);
1405        damageRegionProcessPending (pDrawable);
1406        DAMAGE_GC_OP_EPILOGUE(pGC, pDrawable);
1407    }
1408    
(gdb) up
#10 0x00b82861 in exaGlyphs (op=3 '\003', pSrc=0x90524c0, pDst=0x9095578, maskFormat=0x87c7620, xSrc=61, ySrc=424, nlist=1, list=0xbfe0eec0, glyphs=0xbfe0eac0)
    at exa_glyphs.c:789
789             (*pGC->ops->PolyFillRect) (&pMaskPixmap->drawable, pGC, 1, &rect);
(gdb) list
784             ValidateGC (&pMaskPixmap->drawable, pGC);
785             rect.x = 0;
786             rect.y = 0;
787             rect.width = width;
788             rect.height = height;
789             (*pGC->ops->PolyFillRect) (&pMaskPixmap->drawable, pGC, 1, &rect);
790             FreeScratchGC (pGC);
791             x = -extents.x1;
792             y = -extents.y1;
793         }
(gdb) up
#11 0x0811bd15 in damageGlyphs (op=3 '\003', pSrc=0x90524c0, pDst=0x9095578, maskFormat=0x87c7620, xSrc=61, ySrc=424, nlist=1, list=0xbfe0eec0, glyphs=0xbfe0eac0)
    at damage.c:721
721         (*ps->Glyphs) (op, pSrc, pDst, maskFormat, xSrc, ySrc, nlist, list, glyphs);
(gdb) list
716             TRIM_PICTURE_BOX (box, pDst);
717             if (BOX_NOT_EMPTY(box))
718                 damageDamageBox (pDst->pDrawable, &box, pDst->subWindowMode);
719         }
720         unwrap (pScrPriv, ps, Glyphs);
721         (*ps->Glyphs) (op, pSrc, pDst, maskFormat, xSrc, ySrc, nlist, list, glyphs);
722         damageRegionProcessPending (pDst->pDrawable);
723         wrap (pScrPriv, ps, Glyphs, damageGlyphs);
724     }
725     
(gdb) up
#12 0x081b5ba7 in CompositeGlyphs (op=3 '\003', pSrc=0x90524c0, pDst=0x9095578, maskFormat=0x87c7620, xSrc=61, ySrc=424, nlist=1, lists=0xbfe0eec0, glyphs=0xbfe0eac0)
    at glyph.c:619
619         (*ps->Glyphs) (op, pSrc, pDst, maskFormat, xSrc, ySrc, nlist, lists, glyphs);
(gdb) list
614     {
615         PictureScreenPtr    ps = GetPictureScreen(pDst->pDrawable->pScreen);
616     
617         ValidatePicture (pSrc);
618         ValidatePicture (pDst);
619         (*ps->Glyphs) (op, pSrc, pDst, maskFormat, xSrc, ySrc, nlist, lists, glyphs);
620     }
621     
622     Bool
623     miRealizeGlyph (ScreenPtr pScreen,
(gdb) up 
#13 0x08115c7f in ProcRenderCompositeGlyphs (client=0x89fcb30) at render.c:1430
1430        CompositeGlyphs (stuff->op,
(gdb) list
1425            }
1426        }
1427        if (buffer > end)
1428            return BadLength;
1429    
1430        CompositeGlyphs (stuff->op,
1431                         pSrc,
1432                         pDst,
1433                         pFormat,
1434                         stuff->xSrc,
(gdb) up
#14 0x08111824 in ProcRenderDispatch (client=0x89fcb30) at render.c:2056
2056            return (*ProcRenderVector[stuff->data]) (client);
(gdb) list
2051    ProcRenderDispatch (ClientPtr client)
2052    {
2053        REQUEST(xReq);
2054        
2055        if (stuff->data < RenderNumberRequests)
2056            return (*ProcRenderVector[stuff->data]) (client);
2057        else
2058            return BadRequest;
2059    }
2060    
(gdb) up
#15 0x0806df37 in Dispatch () at dispatch.c:439
439                             result = (* client->requestVector[MAJOROP])(client);
(gdb) list
434                     if (result > (maxBigRequestSize << 2))
435                         result = BadLength;
436                     else {
437                         result = XaceHookDispatch(client, MAJOROP);
438                         if (result == Success)
439                             result = (* client->requestVector[MAJOROP])(client);
440                         XaceHookAuditEnd(client, result);
441                     }
442     #ifdef XSERVER_DTRACE
443                     XSERVER_REQUEST_DONE(LookupMajorName(MAJOROP), MAJOROP,
(gdb) up
#16 0x08062675 in main (argc=9, argv=0xbfe0f384, envp=0xbfe0f3ac) at main.c:286
286             Dispatch();
(gdb) list
281         pthread_mutex_unlock(&serverInitCompleteMutex);
282     #endif
283             
284             NotifyParentProcess();
285     
286             Dispatch();
287     
288             UndisplayDevices();
289     
290             /* Now free up whatever must be freed */
(gdb) up
Initial frame selected; you cannot go up.
(gdb) bt
#0  0x0032c324 in OUT_RING (ppix=0x8ff1288, is_src=0) at /usr/include/nouveau/nouveau_pushbuf.h:67
#1  NV50EXAAcquireSurface2D (ppix=0x8ff1288, is_src=0) at nv50_exa.c:130
#2  0x0032d840 in NV50EXAPrepareSolid (pdpix=0x8ff1288, alu=3, planemask=4294967295, fg=0) at nv50_exa.c:235
#3  0x0032d96f in NV50EXAStateSolidResubmit (chan=0x87b3198) at nv50_exa.c:219
#4  0x00f9c02d in nouveau_pushbuf_flush (chan=0x87b3198, min=0) at nouveau_pushbuf.c:276
#5  0x0032b73f in FIRE_RING (pdpix=0x8ff1288, x1=0, y1=0, x2=56, y2=11) at /usr/include/nouveau/nouveau_pushbuf.h:121
#6  NV50EXASolid (pdpix=0x8ff1288, x1=0, y1=0, x2=56, y2=11) at nv50_exa.c:268
#7  0x00b80ab3 in exaFillRegionSolid (pDrawable=0x8ff1288, pRegion=0x8be9d30, pixel=0, planemask=4294967295, alu=3, clientClipType=0) at exa_accel.c:1038
#8  0x00b81663 in exaPolyFillRect (pDrawable=0x8ff1288, pGC=0x87ea780, nrect=1, prect=0xbfe0e910) at exa_accel.c:819
#9  0x0811c296 in damagePolyFillRect (pDrawable=0x8ff1288, pGC=0x87ea780, nRects=1, pRects=0xbfe0e910) at damage.c:1404
#10 0x00b82861 in exaGlyphs (op=3 '\003', pSrc=0x90524c0, pDst=0x9095578, maskFormat=0x87c7620, xSrc=61, ySrc=424, nlist=1, list=0xbfe0eec0, glyphs=0xbfe0eac0)
    at exa_glyphs.c:789
#11 0x0811bd15 in damageGlyphs (op=3 '\003', pSrc=0x90524c0, pDst=0x9095578, maskFormat=0x87c7620, xSrc=61, ySrc=424, nlist=1, list=0xbfe0eec0, glyphs=0xbfe0eac0)
    at damage.c:721
#12 0x081b5ba7 in CompositeGlyphs (op=3 '\003', pSrc=0x90524c0, pDst=0x9095578, maskFormat=0x87c7620, xSrc=61, ySrc=424, nlist=1, lists=0xbfe0eec0, glyphs=0xbfe0eac0)
    at glyph.c:619
#13 0x08115c7f in ProcRenderCompositeGlyphs (client=0x89fcb30) at render.c:1430
#14 0x08111824 in ProcRenderDispatch (client=0x89fcb30) at render.c:2056
#15 0x0806df37 in Dispatch () at dispatch.c:439
#16 0x08062675 in main (argc=9, argv=0xbfe0f384, envp=0xbfe0f3ac) at main.c:286
(gdb) quit
A debugging session is active.

        Inferior 1 [process 1850] will be detached.

Quit anyway? (y or n) y
Detaching from program: /usr/bin/Xorg, process 1850
ESC]0;root@localhost:~^G[root@localhost ~]# rpm -qif /usr/include/nouveau/no^Guveau_pushbuf.h 
Name        : libdrm-devel                 Relocations: (not relocatable)
Version     : 2.4.20                            Vendor: Fedora Project
Release     : 1.fc13                        Build Date: Thu 08 Apr 2010 05:33:15 AM BRT
Install Date: Mon 14 Jun 2010 02:05:39 PM BRT      Build Host: xb-01.phx2.fedoraproject.org
Group       : Development/Libraries         Source RPM: libdrm-2.4.20-1.fc13.src.rpm
Size        : 756288                           License: MIT
Signature   : RSA/8, Thu 08 Apr 2010 06:20:02 AM BRT, Key ID 7edc6ad6e8e40fde
Packager    : Fedora Project
URL         : http://dri.sourceforge.net
Summary     : Direct Rendering Manager development package
Description :
Direct Rendering Manager development package
ESC]0;root@localhost:~^G[root@localhost ~]# chvt 2




^C
ESC]0;root@localhost:~^G[root@localhost ~]# time chvt 3



^C

real    0m5.884s
user    0m0.000s
sys     0m0.001s

[root@localhost ~]# lspci|tail -n 1
02:00.0 VGA compatible controller: nVidia Corporation C77 [GeForce 8200] (rev a2)
[root@localhost ~]# 
[root@localhost ~]# cat /proc/cpuinfo |head -n 10
processor	: 0
vendor_id	: AuthenticAMD
cpu family	: 16
model		: 2
model name	: AMD Phenom(tm) 8650 Triple-Core Processor
stepping	: 3
cpu MHz		: 1150.000
cache size	: 512 KB
physical id	: 0
siblings	: 3
[root@localhost ~]# uname -a
Linux localhost.localdomain 2.6.33.5-124.fc13.i686.PAE #1 SMP Fri Jun 11 09:42:24 UTC 2010 i686 i686 i386 GNU/Linux
[root@localhost ~]#
Comment 1 Matěj Cepl 2010-06-22 18:46:03 EDT
Thanks for the bug report.  We have reviewed the information you have provided above, and there is some additional information we require that will be helpful in our diagnosis of this issue.

Please add drm.debug=0x04 to the kernel command line, restart computer, and attach

* your X server config file (/etc/X11/xorg.conf, if available),
* X server log file (/var/log/Xorg.*.log)
* output of the dmesg command, and
* system log (/var/log/messages)

to the bug report as individual uncompressed file attachments using the bugzilla file attachment link above.

We will review this issue again once you've had a chance to attach this information.

Thanks in advance.
Comment 2 fedoraproject 2010-06-23 08:13:02 EDT
* your X server config file (/etc/X11/xorg.conf, if available),

There is no such file (/etc/X11/xorg.conf).
Just one for the keyboard:
[root@localhost ~]# ls /etc/X11/{X*,x*};find /etc/X11/xorg.conf.d/
/etc/X11/Xmodmap  /etc/X11/Xresources

/etc/X11/xinit:
Xclients  Xclients.d  xinitrc  xinitrc-common  xinitrc.d  xinput.d  xinputrc  Xsession

/etc/X11/xorg.conf.d:
00-system-setup-keyboard.conf
/etc/X11/xorg.conf.d/
/etc/X11/xorg.conf.d/00-system-setup-keyboard.conf
[root@localhost ~]# cat /etc/X11/xorg.conf.d/00-system-setup-keyboard.conf
# This file is autogenerated by system-setup-keyboard. Any 
# modifications will be lost.

Section "InputClass"
	Identifier	"system-setup-keyboard"
	MatchIsKeyboard	"on"
	Option		"XkbModel"	"abnt2"
	Option		"XkbLayout"	"br"
#	Option		"XkbVariant"	"(null)"
	Option		"XkbOptions"	"terminate:ctrl_alt_bksp,"
EndSection
[root@localhost ~]#
Comment 3 fedoraproject 2010-06-23 08:18:13 EDT
Created attachment 426249 [details]
Xorg log file
Comment 4 fedoraproject 2010-06-23 08:25:25 EDT
I forgot to show this:
[root@localhost ~]# cat /etc/rc.local 
#!/bin/sh
#
# This script will be executed *after* all the other init scripts.
# You can put your own initialization stuff in here if you don't
# want to do the full Sys V style init stuff.

touch /var/lock/subsys/local
amixer -c 0 sset 'Master Front' 80%

echo 0x3ff > /sys/module/nouveau/parameters/reg_debug 
echo 1 > /sys/module/drm/parameters/debug

echo 1 > /proc/sys/kernel/sysrq

With those parameters, I got that response on dmesg (last line is near the moment when the system hangs):
[root@localhost ~]# 
Jun 17 11:34:34 localhost kernel: [drm:drm_ioctl], pid=1850, cmd=0xc01c64a3, nr=0xa3, dev 0xe200, auth=1
Jun 17 11:34:34 localhost kernel: [drm:drm_ioctl], pid=1850, cmd=0xc01c64a3, nr=0xa3, dev 0xe200, auth=1
Jun 17 11:34:34 localhost kernel: [drm:drm_ioctl], pid=1850, cmd=0xc01c64a3, nr=0xa3, dev 0xe200, auth=1
Jun 17 11:34:34 localhost kernel: [drm:drm_ioctl], pid=1850, cmd=0xc01c64a3, nr=0xa3, dev 0xe200, auth=1
Jun 17 11:34:34 localhost kernel: [drm:drm_ioctl], pid=1850, cmd=0xc01c64a3, nr=0xa3, dev 0xe200, auth=1
Jun 17 11:34:34 localhost kernel: [drm:drm_ioctl], pid=1850, cmd=0xc01c64a3, nr=0xa3, dev 0xe200, auth=1
Jun 17 11:34:34 localhost kernel: [drm:drm_ioctl], pid=1850, cmd=0xc01c64a3, nr=0xa3, dev 0xe200, auth=1
Jun 17 11:34:34 localhost kernel: [drm:drm_ioctl], pid=1850, cmd=0xc01c64a3, nr=0xa3, dev 0xe200, auth=1
Jun 17 11:34:34 localhost kernel: [drm:drm_ioctl], pid=1850, cmd=0xc01c64a3, nr=0xa3, dev 0xe200, auth=1
Jun 17 11:34:34 localhost kernel: [drm:drm_ioctl], pid=1850, cmd=0xc01c64a3, nr=0xa3, dev 0xe200, auth=1
Jun 17 11:34:34 localhost kernel: [drm:drm_ioctl], pid=1850, cmd=0xc01c64a3, nr=0xa3, dev 0xe200, auth=1
Jun 17 11:34:34 localhost kernel: [drm:drm_ioctl], pid=1850, cmd=0xc01c64a3, nr=0xa3, dev 0xe200, auth=1
Jun 17 11:34:34 localhost kernel: [drm] nouveau 0000:02:00.0: Ch-1/0x00000a3c: 0x0004089c
Jun 17 11:34:34 localhost kernel: [drm] nouveau 0000:02:00.0: Ch-1/0x00000a40: 0x01000000
Jun 17 11:34:34 localhost kernel: [drm] nouveau 0000:02:00.0: Ch-1/0x00000a44: 0x00080880
Jun 17 11:34:34 localhost kernel: [drm] nouveau 0000:02:00.0: Ch-1/0x00000a48: 0x85000000
Jun 17 11:34:34 localhost kernel: [drm] nouveau 0000:02:00.0: Ch-1/0x00000a4c: 0x00002200
Jun 17 11:34:34 localhost kernel: [drm] nouveau 0000:02:00.0: Ch-1/0x00000a50: 0x00040080
Jun 17 11:34:34 localhost kernel: [drm] nouveau 0000:02:00.0: Ch-1/0x00000a54: 0x00000000
Jun 17 11:34:34 localhost kernel: [drm] nouveau 0000:02:00.0: Ch-1/0x00000a58: PUSH!
Jun 17 11:34:34 localhost kernel: [drm:drm_ioctl], pid=1850, cmd=0xc01c64a3, nr=0xa3, dev 0xe200, auth=1
Jun 17 11:34:34 localhost kernel: [drm] nouveau 0000:02:00.0: Ch-1/0x00000a58: 0x00080c80
Jun 17 11:34:34 localhost kernel: [drm] nouveau 0000:02:00.0: Ch-1/0x00000a5c: 0x05000000
Jun 17 11:34:34 localhost kernel: [drm] nouveau 0000:02:00.0: Ch-1/0x00000a60: 0x00000000
Jun 17 11:34:34 localhost kernel: [drm] nouveau 0000:02:00.0: Ch-1/0x00000a64: 0x00040c9c
Jun 17 11:34:34 localhost kernel: [drm] nouveau 0000:02:00.0: Ch-1/0x00000a68: 0x00000000
Jun 17 11:34:34 localhost kernel: [drm] nouveau 0000:02:00.0: Ch-1/0x00000a6c: 0x00040080
Jun 17 11:34:34 localhost kernel: [drm] nouveau 0000:02:00.0: Ch-1/0x00000a70: 0x00000000
Jun 17 11:34:34 localhost kernel: [drm] nouveau 0000:02:00.0: Ch-1/0x00000a74: PUSH!
Jun 17 11:34:34 localhost kernel: [drm:drm_ioctl], pid=1850, cmd=0xc01c64a3, nr=0xa3, dev 0xe200, auth=1
Jun 17 11:34:34 localhost kernel: [drm:drm_ioctl], pid=1850, cmd=0xc01c64a3, nr=0xa3, dev 0xe200, auth=1
Jun 17 11:34:34 localhost kernel: [drm:drm_ioctl], pid=1850, cmd=0xc01c64a3, nr=0xa3, dev 0xe200, auth=1
Jun 17 11:34:34 localhost kernel: [drm:drm_ioctl], pid=1850, cmd=0xc01c64a3, nr=0xa3, dev 0xe200, auth=1
Jun 17 11:34:34 localhost kernel: [drm:drm_ioctl], pid=1850, cmd=0xc01c64a3, nr=0xa3, dev 0xe200, auth=1
Jun 17 11:34:34 localhost kernel: [drm:drm_ioctl], pid=1850, cmd=0xc01c64a3, nr=0xa3, dev 0xe200, auth=1
Jun 17 11:34:34 localhost kernel: [drm:drm_ioctl], pid=1850, cmd=0xc01c64a3, nr=0xa3, dev 0xe200, auth=1
Jun 17 11:34:34 localhost kernel: [drm:drm_ioctl], pid=1850, cmd=0xc01c64a3, nr=0xa3, dev 0xe200, auth=1
Jun 17 11:34:34 localhost kernel: [drm:drm_ioctl], pid=1850, cmd=0xc01c64a3, nr=0xa3, dev 0xe200, auth=1
Jun 17 11:34:34 localhost kernel: [drm:drm_ioctl], pid=1850, cmd=0xc01c64a3, nr=0xa3, dev 0xe200, auth=1
Jun 17 11:34:34 localhost kernel: [drm:drm_ioctl], pid=1850, cmd=0xc01c64a3, nr=0xa3, dev 0xe200, auth=1
Jun 17 11:34:34 localhost kernel: [drm:drm_ioctl], pid=1850, cmd=0xc01c64a3, nr=0xa3, dev 0xe200, auth=1
Jun 17 11:34:35 localhost kernel: [drm:drm_ioctl], pid=1850, cmd=0xc01c64a3, nr=0xa3, dev 0xe200, auth=1
Jun 17 11:34:35 localhost kernel: [drm:drm_ioctl], pid=1850, cmd=0xc01c64a3, nr=0xa3, dev 0xe200, auth=1
ESC]0;root@localhost:~^G[root@localhost ~]#
Comment 5 fedoraproject 2010-06-23 08:27:56 EDT
I've changed /etc/rc.local to this:

[root@localhost ~]# cat /etc/rc.local 
#!/bin/sh
#
# This script will be executed *after* all the other init scripts.
# You can put your own initialization stuff in here if you don't
# want to do the full Sys V style init stuff.

touch /var/lock/subsys/local
amixer -c 0 sset 'Master Front' 80%

#echo 0x3ff > /sys/module/nouveau/parameters/reg_debug 
echo 0x04 > /sys/module/drm/parameters/debug

echo 1 > /proc/sys/kernel/sysrq
[root@localhost ~]# 

And will clean the logs and do it all over.
Comment 6 fedoraproject 2010-06-23 14:46:51 EDT
I've redirected the kernel messages to another file, so look for dmesg stuff in kerneldmesg.
[root@localhost ~]# grep dmesg /etc/rsyslog.conf 
kern.*                                                 /var/log/kerneldmesg

I'm attaching /var/log/messages too, and a script session with the Xorg log, and the last output from dmesg after the X crashed.

If there is anything that I can do to help fix the bug, please let me know.

Thanks for helping.
Comment 7 fedoraproject 2010-06-23 14:51:58 EDT
Created attachment 426356 [details]
log from dmesg
Comment 8 fedoraproject 2010-06-23 14:53:38 EDT
Created attachment 426357 [details]
var log messages (except dmesg)
Comment 9 fedoraproject 2010-06-23 14:56:39 EDT
Created attachment 426361 [details]
Script session with the end of dmesg, and Xorg.0.log
Comment 10 Steve Walsh 2010-07-29 19:45:54 EDT
I'm adding a "me too" to this bug. Occurring on both a Dell Precision M4500 Laptop with Nvidia Quadro FX880M and a Dell Optiplex Desktop with a Nvidia GeForce GT 220 Video card. Desktop is i386, laptop is x86_64

Most recent lockup on desktop occurred when arriving for work in the morning. Log in, open browser, scroll down a page, machine locks up.

Attaching dmesg & Xorg.log.0*, nothing shows in /var/log/messages between 1am (DHCP renewal) and machine being restarted following crash.

Desktop only at this point;

Name        : xorg-x11-drv-nouveau         Relocations: (not relocatable)
Version     : 0.0.16                            Vendor: Fedora Project
Release     : 7.20100423git13c1043.fc13     Build Date: Sat 26 Jun 2010 11:31:19 AM EST

Name        : glibc                        Relocations: (not relocatable)
Version     : 2.12                              Vendor: Fedora Project
Release     : 3                             Build Date: Tue 06 Jul 2010 11:59:44 PM EST

Name        : xorg-x11-server-Xorg         Relocations: (not relocatable)
Version     : 1.8.2                             Vendor: Fedora Project
Release     : 2.fc13                        Build Date: Tue 20 Jul 2010 12:12:20 PM EST

$ uname -a
Linux sjw-dt.apl 2.6.33.6-147.fc13.i686.PAE #1 SMP Tue Jul 6 22:24:44 UTC 2010 i686 i686 i386 GNU/Linux
Comment 11 Steve Walsh 2010-07-29 19:47:31 EDT
Created attachment 435430 [details]
clean boot Xorg log
Comment 12 Steve Walsh 2010-07-29 19:48:03 EDT
Created attachment 435431 [details]
dmesg
Comment 13 Steve Walsh 2010-07-29 19:48:30 EDT
Created attachment 435432 [details]
Xorg.log with crash data
Comment 14 Arnold Sutter 2010-08-16 16:21:39 EDT
Hi, 

it looks that I'm having exactly the same problem on my new HP 8540w laptop with an nVidia graphics option. 

01:00.0 VGA compatible controller: nVidia Corporation GT216 [Quadro FX 880M] (rev a2) (prog-if 00 [VGA controller])
	Subsystem: Hewlett-Packard Company Device 1521
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 16
	Region 0: Memory at d2000000 (32-bit, non-prefetchable) [size=16M]
	Region 1: Memory at c0000000 (64-bit, prefetchable) [size=256M]
	Region 3: Memory at d0000000 (64-bit, prefetchable) [size=32M]
	Region 5: I/O ports at 5000 [size=128]
	Expansion ROM at d3080000 [disabled] [size=512K]
	Capabilities: [60] Power Management version 3
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [68] MSI: Enable- Count=1/1 Maskable- 64bit+
		Address: 0000000000000000  Data: 0000
	Capabilities: [78] Express (v2) Endpoint, MSI 00
		DevCap:	MaxPayload 128 bytes, PhantFunc 0, Latency L0s unlimited, L1 <64us
			ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
			RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
			MaxPayload 128 bytes, MaxReadReq 256 bytes
		DevSta:	CorrErr+ UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
		LnkCap:	Port #0, Speed 2.5GT/s, Width x16, ASPM L0s L1, Latency L0 <256ns, L1 <4us
			ClockPM+ Surprise- LLActRep- BwNot-
		LnkCtl:	ASPM L0s L1 Enabled; RCB 128 bytes Disabled- Retrain- CommClk+
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 2.5GT/s, Width x16, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
		DevCap2: Completion Timeout: Not Supported, TimeoutDis+
		DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-
		LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-, Selectable De-emphasis: -6dB
			 Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
			 Compliance De-emphasis: -6dB
		LnkSta2: Current De-emphasis Level: -6dB
	Capabilities: [b4] Vendor Specific Information: Len=14 <?>
	Capabilities: [100 v1] Virtual Channel
		Caps:	LPEVC=0 RefClk=100ns PATEntrySize=0
		Arb:	Fixed- WRR32- WRR64- WRR128- 100ns- - - onfig- TableOffset=0
		Ctrl:	ArbSelect=Fixed
		Status:	InProgress-
		VC0:	Caps:	PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
			Arb:	Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256- Fixed- RR32-
			Ctrl:	Enable+ ID=0 ArbSelect=Fixed TC/VC=ff
			Status:	NegoPending- InProgress-
	Capabilities: [128 v1] Power Budgeting <?>
	Capabilities: [600 v1] Vendor Specific Information: ID=0001 Rev=1 Len=024 <?>
	Kernel driver in use: nouveau
	Kernel modules: nouveau, nvidiafb


Excerpt from the /var/log/Xorg.0.log.old file: 

[  2662.352] (II) NOUVEAU(0): Modeline "640x350"x59.8   17.50  640 664 720 800  350 353 363 366 -hsync +vsync (21.9 kHz)
[  2662.451] (II) NOUVEAU(0): EDID for output DP-1
[  2662.549] (II) NOUVEAU(0): EDID for output DP-2
[  2662.552] (II) NOUVEAU(0): EDID for output eDP-1
[  2662.650] (II) NOUVEAU(0): EDID for output DP-3
[  2662.748] (II) NOUVEAU(0): EDID for output VGA-1
[  3792.850] [mi] EQ overflowing. The server is probably stuck in an infinite loop.
[  3792.852] 
Backtrace:
[  3792.852] 0: /usr/bin/Xorg (xorg_backtrace+0x28) [0x45cef8]
[  3792.852] 1: /usr/bin/Xorg (mieqEnqueue+0x1f4) [0x49a4c4]
[  3792.852] 2: /usr/bin/Xorg (xf86PostMotionEventP+0xc4) [0x46f0e4]
[  3792.852] 3: /usr/lib64/xorg/modules/input/evdev_drv.so (0x7fa921ef6000+0x3dbf) [0x7fa921ef9dbf]
[  3792.853] 4: /usr/bin/Xorg (0x400000+0x6d747) [0x46d747]
[  3792.853] 5: /usr/bin/Xorg (0x400000+0x11ccf3) [0x51ccf3]
[  3792.853] 6: /lib64/libc.so.6 (0x7fa925d85000+0x32a20) [0x7fa925db7a20]
[  3792.853] 7: /lib64/libc.so.6 (ioctl+0x7) [0x7fa925e5e5a7]
[  3792.853] 8: /usr/lib64/libdrm.so.2 (drmIoctl+0x28) [0x7fa9243d6388]
[  3792.853] 9: /usr/lib64/libdrm.so.2 (drmCommandWrite+0x1b) [0x7fa9243d660b]
[  3792.853] 10: /usr/lib64/libdrm_nouveau.so.1 (0x7fa923d9a000+0x2dfd) [0x7fa923d9cdfd]
[  3792.853] 11: /usr/lib64/libdrm_nouveau.so.1 (nouveau_bo_map_range+0xfe) [0x7fa923d9cfee]
[  3792.853] 12: /usr/lib64/libdrm_nouveau.so.1 (0x7fa923d9a000+0x207a) [0x7fa923d9c07a]
[  3792.853] 13: /usr/lib64/libdrm_nouveau.so.1 (nouveau_pushbuf_flush+0x190) [0x7fa923d9c450]
[  3792.853] 14: /usr/lib64/xorg/modules/libexa.so (0x7fa923128000+0x9655) [0x7fa923131655]
[  3792.853] 15: /usr/lib64/xorg/modules/libexa.so (0x7fa923128000+0xa1fa) [0x7fa9231321fa]
[  3792.853] 16: /usr/bin/Xorg (0x400000+0xde91b) [0x4de91b]
[  3792.853] 17: /usr/lib64/xorg/modules/libexa.so (0x7fa923128000+0xb470) [0x7fa923133470]
[  3792.853] 18: /usr/bin/Xorg (0x400000+0xde32a) [0x4de32a]
[  3792.853] 19: /usr/bin/Xorg (0x400000+0xd2bce) [0x4d2bce]
[  3792.854] 20: /usr/bin/Xorg (0x400000+0x3619c) [0x43619c]
[  3792.854] 21: /usr/bin/Xorg (0x400000+0x2189a) [0x42189a]
[  3792.854] 22: /lib64/libc.so.6 (__libc_start_main+0xfd) [0x7fa925da3c5d]
[  3792.854] 23: /usr/bin/Xorg (0x400000+0x21449) [0x421449]


Is there anything I can add solving this bug?

Thanks & Regards, 

Arnold
Comment 15 fedoraproject 2010-08-16 17:20:04 EDT
I forgot to mention before, but if I disable video acceleration, the bug doesn't trigger.
I've added the parameter:
nouveau.noaccel=1
in the grub configuration file.

I've also noticed that it "fixed" some random drawing errors. I've spotted them using the audio player amarok. Since I use gnome as a desktop, maybe is something related to the drawing of the kde, but I'm really uncertain about this.
Comment 16 Arnold Sutter 2010-08-23 11:05:33 EDT
Hi again, 

I had to switch to the Closed-Source driver from nVidia in order to get a stable, working system. 

Please ping me if I can be of any help with my hardware in order to fix this/these bugs so I can test your findings on my box in order to get stable "nouveau" relase on the latest hardware. 

Best Regards, 

Arnold
Comment 17 Steve Walsh 2010-08-29 18:51:34 EDT
I've been running both desktop and laptop with the 'nouveau.noaccel=1' option added to the grub.conf for ~14 days, and the system has been more stable. It will still freeze every now and again, but it's for 1-2 seconds, then it recovers.

One annoying side effect of this on the desktop (which has dual screens) is that the mouse pointer will only draw on the screen it was on when the freeze happened. The point does not drawer on the other screen, but I can still select things if I'm patient enough to try and click blindly all over the screen. The Mouse will continue to draw inside a VNC or RDP session on the affected screen.
Comment 18 Arnold Sutter 2010-08-30 03:09:16 EDT
Hi, 

I've also reverted back to the nouveau driver and added the "nouveau.noaccel=1" boot option (I've had a misspelling at my first attempt, that's why it didn't work right away).

It looks that I now have a stable system, at least on the display side. 

Has anybody an idea how things like this usually evolve? - Will the upstream code that eventually flows down to the release1 fix things like this automatically over time?

Will this driver support accelleration eventually?

Best Regards, 

Arnold
Comment 19 John Sullivan 2010-10-18 14:11:47 EDT
Been getting this recently since I upgraded from F12 to F13 (F12 was fine, with the latest updates) - about once or twice a day. I briefly tried the noaccel option, but it makes the whole desktop annoyingly slower (which suggests that this kernel, also the latest F13 update, doesn't have this option on by default).

kernel-2.6.34.7-56.fc13.x86_64
xorg-x11-drv-nouveau-0.0.16-8.20100423git13c1043.fc13.x86_64
xorg-x11-server-Xorg-1.8.2-4.fc13.x86_64

Backtrace from a previous crash:

#0  0x00000030008329a5 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x0000003000834185 in abort () at abort.c:92
#2  0x000000000045db1e in OsAbort () at utils.c:1335
#3  0x000000000045ac1d in FatalError (f=0x7fb5f96af3b1 "Detected GPU lockup\n") at log.c:555
#4  0x00007fb5f9695d9d in NVLockedUp (pScrn=0x26551e0) at nv_dma.c:37
#5  NVSync (pScrn=0x26551e0) at nv_dma.c:66
#6  0x00007fb5f969620c in NVLeaveVT (scrnIndex=<value optimized out>, flags=<value optimized out>) at nv_driver.c:350
#7  0x000000000046d2b3 in AbortDDX () at xf86Init.c:1284
#8  0x000000000045a40d in AbortServer () at log.c:425
#9  0x000000000045ac60 in FatalError (f=0x575048 "Caught signal %d (%s). Server aborting\n") at log.c:553
#10 0x000000000046355e in OsSigHandler (signo=11, sip=<value optimized out>, unused=<value optimized out>) at osinit.c:156
#11 <signal handler called>
#12 0x00000030008d95d7 in ioctl () at ../sysdeps/unix/syscall-template.S:82
#13 0x0000003013803388 in drmIoctl (fd=10, request=1074291842, arg=0x7fff5ece3890) at xf86drm.c:184
#14 0x000000301380360b in drmCommandWrite (fd=<value optimized out>, drmCommandIndex=<value optimized out>, data=<value optimized out>, 
    size=<value optimized out>) at xf86drm.c:2361
#15 0x00007fb5f944ddfd in nouveau_bo_wait (bo=0x2677500, cpu_write=<value optimized out>, no_wait=<value optimized out>, 
    no_block=<value optimized out>) at nouveau_bo.c:385
#16 0x00007fb5f944dfee in nouveau_bo_map_range (bo=0x2677500, delta=0, size=<value optimized out>, flags=8) at nouveau_bo.c:428
#17 0x00007fb5f968f498 in NVAccelUploadM2MF (pdpix=0x4776450, x=0, y=0, w=<value optimized out>, h=4, 
    src=0x52805c0 "\226\377\377\377\377\377\226", src_pitch=8) at nouveau_exa.c:197
#18 nouveau_exa_upload_to_screen (pdpix=0x4776450, x=0, y=0, w=<value optimized out>, h=4, src=0x52805c0 "\226\377\377\377\377\377\226", 
    src_pitch=8) at nouveau_exa.c:469
#19 0x00007fb5f901a23f in exaCopyDirty (migrate=<value optimized out>, pValidDst=0x46df800, pValidSrc=0x46df7f0, 
    transfer=0x7fb5f968f2b0 <nouveau_exa_upload_to_screen>, fallback_index=0, sync=0) at exa_migration_classic.c:220
#20 0x00007fb5f901c494 in exaDoMigration_mixed (pixmaps=<value optimized out>, npixmaps=3, can_accel=<value optimized out>)
    at exa_migration_mixed.c:113
#21 0x00007fb5f9022117 in exaTryDriverComposite (op=3 '\003', pSrc=0x38d9e90, pMask=0x4648f90, pDst=0x4731150, xSrc=4, ySrc=964, xMask=0, 
    yMask=0, xDst=<value optimized out>, yDst=<value optimized out>, width=7, height=4) at exa_render.c:735
#22 0x00007fb5f90230b2 in exaComposite (op=3 '\003', pSrc=0x38d9e90, pMask=0x4648f90, pDst=0x4731150, xSrc=4, ySrc=964, xMask=0, yMask=0, 
    xDst=4, yDst=964, width=7, height=4) at exa_render.c:1034
#23 0x00000000004d0d80 in damageComposite (op=3 '\003', pSrc=0x38d9e90, pMask=0x4648f90, pDst=0x4731150, xSrc=<value optimized out>, 
    ySrc=<value optimized out>, xMask=0, yMask=0, xDst=4, yDst=964, width=7, height=4) at damage.c:643
#24 0x00007fb5f9d614ef in vncHooksComposite (op=3 '\003', pSrc=0x38d9e90, pMask=0x4648f90, pDst=0x4731150, xSrc=4, ySrc=964, xMask=0, yMask=0, 
    xDst=4, yDst=964, width=7, height=4) at vncHooks.cc:534
#25 0x00007fb5f9021d08 in exaTrapezoids (op=3 '\003', pSrc=0x38d9e90, pDst=0x4731150, maskFormat=0x2677958, xSrc=4, ySrc=964, ntrap=0, 
    traps=0x52f80c8) at exa_render.c:1183
#26 0x00000000004c9077 in ProcRenderTrapezoids (client=0x2ec4460) at render.c:780
#27 0x000000000042dbdc in Dispatch () at dispatch.c:439
#28 0x000000000042189a in main (argc=<value optimized out>, argv=0x7fff5ece4188, envp=<value optimized out>) at main.c:286

(Frame #12 was where it was sat in the same SIGALRM/ioctl loop others have reported, until I manually sent it SIGSEGV to get it to dump core.)

I see the same EQ overflowing message and backtrace in the Xorg.0.log file, and at about the time it wedged I see in /var/log/messages the single drm message:

kernel: [drm] nouveau 0000:0f:00.0: PFIFO_DMA_PUSHER - Ch 1

I didn't have the drm debugging turned up at the time this happened; I now have so will see if any more output appears there the next time I get this.

(Once I've killed off the Xorg process it also leaves the VT hung, so that when it restarts automatically it does so on the next higher available VT and so on.)
Comment 20 John Sullivan 2010-10-19 10:48:04 EDT
Nope, running with drm.debug=0x04, the only thing that appears in the dmesg output at the time of the lockup is that PFIFO_DMA_PUSHER line, and that is the only time it appears.

(I was running kernel-2.6.32.21-168.fc12.x86_64 under F12 without this problem.)

Card is:

0f:00.0 VGA compatible controller [0300]: nVidia Corporation G72 [GeForce 7300 SE/7200 GS] [10de:01d3] (rev a1) (prog-if 00 [VGA controller])
	Subsystem: Giga-byte Technology Device [1458:3470]
	Physical Slot: 2
	Flags: bus master, fast devsel, latency 0, IRQ 24
	Memory at e0000000 (32-bit, non-prefetchable) [size=16M]
	Memory at d0000000 (64-bit, prefetchable) [size=256M]
	Memory at e1000000 (64-bit, non-prefetchable) [size=16M]
	Expansion ROM at <unassigned> [disabled]
	Capabilities: [60] Power Management version 2
	Capabilities: [68] MSI: Enable- Count=1/1 Maskable- 64bit+
	Capabilities: [78] Express Endpoint, MSI 00
	Capabilities: [100] Virtual Channel
	Capabilities: [128] Power Budgeting <?>
	Kernel driver in use: nouveau
	Kernel modules: nouveau, nvidiafb
Comment 21 John Sullivan 2010-10-22 08:10:11 EDT
Just got something slightly different on this one: dmesg shows the following:

[drm] nouveau 0000:0f:00.0: PFIFO_DMA_PUSHER - Ch 1
[drm] nouveau 0000:0f:00.0: PGRAPH_ERROR - nSource: DATA_ERROR, nStatus: BAD_ARGUMENT
[drm] nouveau 0000:0f:00.0: PGRAPH_ERROR - Ch 1/5 Class 0x4497 Mthd 0x1840 Data 0x00000000:0x000a00a7

Same backtrace as before.

(Is the problem understood at all? Or is there any extra information that would track it down? I could probably go as far as gdbing the wedged X server and digging around, *if* I knew what I was looking for, and assuming there is anything diagnostic present in user space rather than the driver itself.)
Comment 22 John Sullivan 2010-10-27 07:43:13 EDT
Created attachment 455952 [details]
dmesg output

After upgrading to kernel-2.6.34.7-61.fc13.x86_64 on Monday I haven't seen the lockup - at a previous rate of 1-3 per day I think that's likely gone.

What I am seeing now is occasional font corruption, often a single glyph gets trashed wherever that one character/font combination appears on the desktop, for a few minutes before recovering.

dmesg shows a flurry of new output, PGRAPH_ERROR and PFIFO_DMA_PUSHER, attached.

(It's my impression that instances of corruption coincide with the appearance of new dmesg messages.)
Comment 23 Ben Skeggs 2010-11-01 23:02:13 EDT
Ah, that's good to know.  The kernel you're using has better GPU error handling implemented, so it probably is indeed the same bug, just with less severe consequences now.
Comment 24 John Sullivan 2010-11-18 09:19:39 EST
Just had another hang (after 3 weeks continuous running), which looks a little different now:

[2082340.099] [mi] EQ overflowing. The server is probably stuck in an infinite loop.
[2082340.128] 
Backtrace:
[2082340.441] 0: /usr/bin/Xorg (xorg_backtrace+0x28) [0x460d18]
[2082340.441] 1: /usr/bin/Xorg (mieqEnqueue+0x1f4) [0x45a0a4]
[2082340.441] 2: /usr/bin/Xorg (xf86PostMotionEventP+0xc4) [0x473f84]
[2082340.441] 3: /usr/lib64/xorg/modules/input/evdev_drv.so (0x7f77b2f73000+0x3dbf) [0x7f77b2f76dbf]
[2082340.441] 4: /usr/bin/Xorg (0x400000+0x664f7) [0x4664f7]
[2082340.441] 5: /usr/bin/Xorg (0x400000+0x112263) [0x512263]
[2082340.451] 6: /lib64/libc.so.6 (0x7f77b6edb000+0x32a20) [0x7f77b6f0da20]
[2082340.451] 7: /lib64/libc.so.6 (ioctl+0x7) [0x7f77b6fb45b7]
[2082340.451] 8: /usr/lib64/libdrm.so.2 (drmIoctl+0x28) [0x3013803388]
[2082340.451] 9: /usr/lib64/libdrm.so.2 (drmCommandWrite+0x1b) [0x301380360b]
[2082340.451] 10: /usr/lib64/libdrm_nouveau.so.1 (0x7f77b5900000+0x2dfd) [0x7f77b5902dfd]
[2082340.452] 11: /usr/lib64/libdrm_nouveau.so.1 (nouveau_bo_map_range+0xfe) [0x7f77b5902fee]
[2082340.452] 12: /usr/lib64/libdrm_nouveau.so.1 (0x7f77b5900000+0x207a) [0x7f77b590207a]
[2082340.452] 13: /usr/lib64/libdrm_nouveau.so.1 (nouveau_pushbuf_flush+0x190) [0x7f77b5902450]
[2082340.452] 14: /usr/lib64/xorg/modules/libexa.so (0x7f77b54ca000+0x9655) [0x7f77b54d3655]
[2082340.452] 15: /usr/lib64/xorg/modules/libexa.so (0x7f77b54ca000+0xa1fa) [0x7f77b54d41fa]
[2082340.452] 16: /usr/bin/Xorg (0x400000+0xd169b) [0x4d169b]
[2082340.452] 17: /usr/lib64/xorg/modules/extensions/libvnc.so (0x7f77b61a5000+0x379c5) [0x7f77b61dc9c5]
[2082340.452] 18: /usr/lib64/xorg/modules/libexa.so (0x7f77b54ca000+0xb470) [0x7f77b54d5470]
[2082340.452] 19: /usr/bin/Xorg (0x400000+0xd10aa) [0x4d10aa]
[2082340.452] 20: /usr/bin/Xorg (0x400000+0xc775e) [0x4c775e]
[2082340.452] 21: /usr/bin/Xorg (0x400000+0x2dbdc) [0x42dbdc]
[2082340.452] 22: /usr/bin/Xorg (0x400000+0x2189a) [0x42189a]
[2082340.452] 23: /lib64/libc.so.6 (__libc_start_main+0xfd) [0x7f77b6ef9c5d]
[2082340.452] 24: /usr/bin/Xorg (0x400000+0x21449) [0x421449]

dmesg reports:

Nov 18 12:47:11 kernel: [drm] nouveau 0000:0f:00.0: PFIFO_DMA_PUSHER - Ch 1 Get 0x1f340000 Put 0x0001f978 State 0xc002780c Push 0x00000000
Nov 18 12:47:21 kernel: [drm] nouveau 0000:0f:00.0: PFIFO_DMA_PUSHER - Ch 1 Get 0x3e0ccccc Put 0x00016db0 State 0xc0022054 Push 0x00000000
Nov 18 12:47:21 kernel: [drm] nouveau 0000:0f:00.0: PFIFO_DMA_PUSHER - Ch 1 Get 0x00026044 Put 0x000175e0 State 0x20022054 Push 0x00000000
Nov 18 12:47:21 kernel: nouveau_ratelimit: 12 callbacks suppressed
Nov 18 12:47:21 kernel: [drm] nouveau 0000:0f:00.0: PGRAPH_ERROR - nSource: METHOD_CNT, nStatus: INVALID_STATE BAD_ARGUMENT PROTECTION_FAULT
Nov 18 12:47:21 kernel: [drm] nouveau 0000:0f:00.0: PGRAPH_ERROR - Ch 1/3 Class 0x004a Mthd 0x0c70 Data 0x00000000:0x00606c70
Nov 18 12:47:21 kernel: [drm] nouveau 0000:0f:00.0: PGRAPH_ERROR - nSource: METHOD_CNT, nStatus: INVALID_STATE BAD_ARGUMENT PROTECTION_FAULT
Nov 18 12:47:21 kernel: [drm] nouveau 0000:0f:00.0: PGRAPH_ERROR - Ch 1/3 Class 0x004a Mthd 0x0c74 Data 0x00000000:0x00606c70
[the above two lines repeat another 18 times]
Nov 18 12:47:21 kernel: [drm] nouveau 0000:0f:00.0: PFIFO_DMA_PUSHER - Ch 1 Get 0x001f0b10 Put 0x00017ba0 State 0x404a6070 Push 0x00000000

In particular, I don't recall having seen the ratelimit line before.

These problems (old hangs, the new glitches, and this new hang) subjectively seem to occur during vertical scrolling. Mostly this is paging down in firefox, this hang happened while a large build was spewing a lot of output in a gnome-terminal window, which I've also seen before. The terminal window (normally black-on-white) went entirely black and the X server wedged (mouse movement but no other activity, including VT switching possible. Requires ssh from outside to kill the X server, which then restarts and recovers.)
Comment 25 John Sullivan 2010-11-18 09:26:45 EST
Although grepping /var/log/messages* shows 7 other instances of the ratelimit line, all after the kernel upgrade, none from before. The earliest instance had a massive 1189 callbacks suppressed (working backwards the others are 12,4,13,75,140,62,6,1189).

This appears far less frequently that the glitches are happening though.
Comment 26 Anthony Messina 2010-11-18 13:54:33 EST
(In reply to comment #24)
> In particular, I don't recall having seen the ratelimit line before.
> These problems (old hangs, the new glitches, and this new hang) subjectively
> seem to occur during vertical scrolling. Mostly this is paging down in firefox,
> this hang happened while a large build was spewing a lot of output in a
> gnome-terminal window, which I've also seen before. The terminal window
> (normally black-on-white) went entirely black and the X server wedged (mouse
> movement but no other activity, including VT switching possible. Requires ssh
> from outside to kill the X server, which then restarts and recovers.)

I can confirm that I mostly see and can intermittently reproduce this issue with vertical scrolling in firefox.  It occurs whether I use the Page Down key or use the scroll wheel on the mouse (though it seems to happen more with the mouse wheel).
Comment 27 John Sullivan 2010-11-19 10:45:14 EST
Just got another hang after 24 hours. On the basis that this may indicate progressive damage within the kernel driver worsening the situation, I have rebooted rather than just restarted the X server. Hopefully this will give me another 3 weeks without lockups.

This was during a lot of text output in gnome-terminal again. Tying this together with the font corruption I think this may be happening:

Presumably the font server is rendering fonts internally then copying them to off-screen video memory, then applications (whether themselves or by asking the X server, or the font server, I don't know the exact mechanics) can blit between that buffer and the screen on-demand. (My metacity config isn't set for compositing, compositing_manager is unchecked in gconf-editor, so it would be between off-screen and screen, I think.)

So the fact that individual glyphs get corrupted throughout the screen indicates the font server is failing to copy into the off-screen texture correctly. This persists for a short while, until the glyph is either evicted or otherwise expired from the cache I assume. The corruption tends to happen during vertical scrolling (whether firefox or a terminal), but I don't think it's the scrolling itself that is the problem. I don't think firefox caches the view itself, so will be rendering each glyph anew as they are scrolled into view. Similarly with the terminal. This will involve a huge number of very small blits from off-screen to -onscreen, presumably in a heavily optimised path so they can all be queued up in rapid succession. This process probably (given the corruption) involves a lot of font server glyph cache replacement too, so there will a lot of traffic both in and out of the off-screen buffer. So I think that is the trigger.
Comment 28 John Sullivan 2010-11-19 11:36:18 EST
Apparently not. After an hour the machine hung again with *massive* corruption in the terminal window. (All black-and-white artifacts, not generic random-colour/noise graphics corruption, looks like lots of over-drawn glyphs and some blocks overdrawn with horizontal stripes.)

This time it hard locked: no mouse pointer, and no network access. (Same kernel as before, 2.6.34.7-61.) No details of the event survived in any log files.
Comment 29 Matěj Cepl 2011-03-06 18:39:30 EST
CLosing as duplicate of bug 465884 for reasons explained there. Please, file a bug for each separate issue here (crashes etc.), message "EQ overflowing ..." etc. is so generic that it actually doesn't mean much.

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

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