Bug 14365 - [965] clutter tests result in X lockups then crash
[965] clutter tests result in X lockups then crash
Status: VERIFIED FIXED
Product: xorg
Classification: Unclassified
Component: Driver/intel
git
Other All
: medium normal
Assigned To: Eric Anholt
Xorg Project Team
:
Depends on:
Blocks: 18841
  Show dependency treegraph
 
Reported: 2008-02-03 23:52 UTC by Johan Bilien
Modified: 2008-12-10 20:53 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
log (18.95 KB, text/plain)
2008-02-04 02:08 UTC, Johan Bilien
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Johan Bilien 2008-02-03 23:52:19 UTC
When running clutter's new fbo test program, I systematically see the following crash of the server:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb7a956b0 (LWP 3294)]
0xb7a13ea7 in DRILock (pScreen=0x821d6c8, flags=0) at dri.c:2182
2182            DRM_LOCK(pDRIPriv->drmFD, pDRIPriv->pLSAREA, pDRIPriv->myContext, flags);
(gdb) bt
#0  0xb7a13ea7 in DRILock (pScreen=0x821d6c8, flags=0) at dri.c:2182
#1  0xb79c6a4d in I830LeaveVT (scrnIndex=0, flags=0) at i830_driver.c:3076
#2  0x080cf168 in xf86XVLeaveVT (index=0, flags=0) at xf86xv.c:1268
#3  0xb7a653e9 in glxDRILeaveVT (index=0, flags=0) at glxdri.c:837
#4  0x080a6298 in AbortDDX () at xf86Init.c:1315
#5  0x08137548 in AbortServer () at log.c:406
#6  0x08137ac6 in FatalError (f=0xb79e711c "lockup\n") at log.c:552
#7  0xb79bb86b in I830WaitLpRing (pScrn=0x820e358, n=131064, timeout_millis=0)
    at i830_accel.c:150
#8  0xb79bbacd in I830Sync (pScrn=0x820e358) at i830_accel.c:201
#9  0xb79da04a in I830EXASync (pScreen=0x821d6c8, marker=0) at i830_exa.c:154
#10 0xb7842cdf in exaWaitSync (pScreen=0x821d6c8) at exa.c:985
#11 0xb79c6dc6 in i830WaitSync (pScrn=0x820e358) at i830_driver.c:3527
#12 0xb79df1d1 in i965_prepare_composite (op=12, pSrcPicture=0x847cec8,
    pMaskPicture=0x0, pDstPicture=0x8469530, pSrc=0x847cdb0, pMask=0x0,
    pDst=0x8469418) at i965_render.c:586
#13 0xb7849f92 in exaTryDriverComposite (op=12 '\f', pSrc=0x847cec8,
    pMask=0x0, pDst=0x8469530, xSrc=0, ySrc=0, 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:446
#14 0xb784a85b in exaComposite (op=12 '\f', pSrc=0x847cec8, pMask=0x0,
    pDst=0x8469530, xSrc=0, ySrc=0, xMask=0, yMask=0, xDst=7, yDst=3, width=8,
---Type <return> to continue, or q <return> to quit---
    height=8) at exa_render.c:701
#15 0x08173b23 in damageComposite (op=192 'À', pSrc=0x847cec8, pMask=0x0,
    pDst=0x8469530, 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:576
#16 0x0815a7af in CompositePicture (op=12 '\f', pSrc=0x847cec8, pMask=0x0,
    pDst=0x8469530, 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:1661
#17 0x08154d42 in miGlyphs (op=3 '\003', pSrc=0x846a488, pDst=0x8440f60,
    maskFormat=0x8220bc8, xSrc=0, ySrc=0, nlist=1, list=0xbfe4d308,
    glyphs=0xbfe4cf10) at glyph.c:723
#18 0x0817389e in damageGlyphs (op=192 'À', pSrc=0x846a488, pDst=0x8440f60,
    maskFormat=0x8220bc8, xSrc=<value optimized out>,
    ySrc=<value optimized out>, nlist=1, list=0xbfe4d308, glyphs=0xbfe4cf08)
    at damage.c:654
#19 0x08155609 in CompositeGlyphs (op=192 'À', pSrc=0x846a488, pDst=0x8440f60,
    maskFormat=0x8220bc8, xSrc=<value optimized out>,
    ySrc=<value optimized out>, nlist=1, lists=0xbfe4d308, glyphs=0xbfe4cf08)
    at glyph.c:629
#20 0x08160ac8 in ProcRenderCompositeGlyphs (client=0x83cbba8) at render.c:1461
#21 0x0815c2a5 in ProcRenderDispatch (client=0x21) at render.c:2086
#22 0x0808a3d8 in Dispatch () at dispatch.c:468
#23 0x080710ed in main (argc=9, argv=0xbfe4d764, envp=Cannot access memory at address 0x29
) at main.c:448


Seems like the driver tries to recover from a lockup but crashes in the recovery.
Comment 1 Johan Bilien 2008-02-04 00:04:57 UTC
I'm using git HEAD (as of today 4th at 8AM GST) for Xserver, intel DDX, drm and mesa. The test program is test-fbo from clutter HEAD (http://svn.o-hand.com/repos/clutter/trunk)
Comment 2 Gordon Jin 2008-02-04 01:10:45 UTC
Please attach Xorg.0.log.
Comment 3 Johan Bilien 2008-02-04 02:08:38 UTC
Created attachment 14133 [details]
log
Comment 4 Johan Bilien 2008-02-04 02:17:18 UTC
The crash is not related to the fbo test, most of clutter's test suite result in that crash.
Comment 5 Eric Anholt 2008-02-07 14:21:40 UTC
I'm only seeing the hardware hang (which is what that crash is a result of) with the fbo test.  For other clutter tests, only test-shader fails to draw as expected (bug #14416), and test-textures gets OOM-killed though I haven't tracked down who's responsible for that.
Comment 6 Johan Bilien 2008-02-09 03:26:05 UTC
I updated today to git tip of everything, I am still seeing the same lockups.

I do see the lockup with at least test-scale, test-actor, test-entry. That's all the ones I have tried. The lockup sometimes does not happen immediatly, sometimes after a few frames.
Comment 7 Johan Bilien 2008-03-13 07:51:04 UTC
I think running them with CLUTTER_VBLANK=none solves the issue. Maybe it relates to the recent problem found in the driver when apps sync on vblank (can't find the bug number)?
Comment 8 Gordon Jin 2008-12-04 19:48:14 UTC
Johan, does this still exist?

I'm CCing Shuang to see if he could reproduce with the latest code.
Comment 9 Shuang He 2008-12-10 20:53:07 UTC
(In reply to comment #7)
> I think running them with CLUTTER_VBLANK=none solves the issue. Maybe it
> relates to the recent problem found in the driver when apps sync on vblank
> (can't find the bug number)?
> 

I met this issue as well before. but with latest commits, that's working fine without that work around.
Kernel:		2.6.28-rc6
Libdrm:		(master)c99566fb810c9d8cae5e9cd39d1772b55e2f514c
Mesa:		(intel-2008-q4)154a9e5317f890618932cea0129ef887e16baf84
Xserver:		(server-1.6-branch)523aae1fa6d8002e55e85aee49f113b7eb9a6df3
Xf86_video_intel:		(xf86-video-intel-2.6-branch)6ca0d7e6ff05bff2bb88bfae64c2d79ac115bd38

If you still met this issue, pls feel free to reopen it.
Comment 10 Shuang He 2008-12-10 20:53:43 UTC
verified