| Summary: | [965] clutter tests result in X lockups then crash | ||||||
|---|---|---|---|---|---|---|---|
| Product: | xorg | Reporter: | Johan Bilien <jobi> | ||||
| Component: | Driver/intel | Assignee: | Eric Anholt <eric> | ||||
| Status: | VERIFIED FIXED | QA Contact: | Xorg Project Team <xorg-team> | ||||
| Severity: | normal | ||||||
| Priority: | medium | CC: | shuang.he | ||||
| Version: | git | ||||||
| Hardware: | Other | ||||||
| OS: | All | ||||||
| Whiteboard: | |||||||
| i915 platform: | i915 features: | ||||||
| Bug Depends on: | |||||||
| Bug Blocks: | 18841 | ||||||
| Attachments: |
|
||||||
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) Please attach Xorg.0.log. Created attachment 14133 [details]
log
The crash is not related to the fbo test, most of clutter's test suite result in that crash. 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. 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. 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)? Johan, does this still exist? I'm CCing Shuang to see if he could reproduce with the latest code. (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. verified |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
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.