Bug 19035 - [GM965 GEM UXA] UXA crashes X server
[GM965 GEM UXA] UXA crashes X server
Status: RESOLVED FIXED
Product: xorg
Classification: Unclassified
Component: Driver/intel
git
Other All
: medium normal
Assigned To: Eric Anholt
Xorg Project Team
:
Depends on:
Blocks: 18858
  Show dependency treegraph
 
Reported: 2008-12-11 17:38 UTC by Ben Gamari
Modified: 2008-12-19 13:46 UTC (History)
0 users

See Also:


Attachments
A gdb session with backtrace of a crashed x server (10.72 KB, text/plain)
2008-12-11 17:39 UTC, Ben Gamari
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ben Gamari 2008-12-11 17:38:53 UTC
UXA has a tendency to kill the X server while drawing due to a failed assertion in intel_batch_emit_dword. It seems this usually (always?) happens in uxa_fill_region_solid. The grav screensaver in xscreensavers seems to have a knack for triggering the crash.


Xorg components as of Thu Dec 11 20:37:54 EST 2008
drm: 	c99566fb810c9d8cae5e9cd39d1772b55e2f514c
xf86-video-intel: 	83377b543defdca7226d7c1a7794e4ff3d8b4c84
mesa: 	a0d5c3cfe6582f8294154f6877319193458158a2
xserver: 	7c8720c1433d2c3b85bbf4b811cc54c2df4c0080

Linux mercury.localdomain 2.6.28-rc7 #6 SMP Tue Dec 9 19:36:02 EST 2008 x86_64 x86_64 x86_64 GNU/Linux
Comment 1 Ben Gamari 2008-12-11 17:39:48 UTC
Created attachment 21078 [details]
A gdb session with backtrace of a crashed x server

Here's the interesting part of the backtrace,

#2  0x00000033b6a2bec9 in __assert_fail (
    assertion=0x7f2866a7dfd8 "pI830->batch_ptr != ((void *)0)", 
    file=0x7f2866a7e091 "i830_batchbuffer.h", line=56, 
    function=0x7f2866a84d20 "intel_batch_emit_dword") at assert.c:78
#3  0x00007f2866a62ab7 in intel_batch_emit_dword () at i830_batchbuffer.h:56
#4  I830EXASolid (pPixmap=0x20eecb0, x1=724, y1=460, x2=725, y2=461)
    at i830_exa.c:245
#5  0x00007f2866a76191 in uxa_fill_region_solid (
    pDrawable=<value optimized out>, pRegion=0x224e0e0, 
    pixel=<value optimized out>, planemask=4294967295, alu=3)
    at uxa-accel.c:871
#6  0x00007f2866a776e0 in uxa_poly_fill_rect (pDrawable=0x25619e0, 
    pGC=0x283bff0, nrect=1, prect=0x2740690) at uxa-accel.c:690
#7  0x00007f2866a76626 in uxa_poly_point (pDrawable=0x25619e0, pGC=0x283bff0, 
    mode=-1, npt=1, ppt=0x282d064) at uxa-accel.c:523
#8  0x00000000004bfa9e in damagePolyPoint (pDrawable=0x25619e0, pGC=0x283bff0, 
    mode=0, npt=1, ppt=0x282d064) at damage.c:1038
#9  0x0000000000428218 in ProcPolyPoint (client=0x21eccc0) at dispatch.c:1636
#10 0x000000000042a974 in Dispatch () at dispatch.c:437
#11 0x00000000004244fd in main (argc=8, argv=0x7fff6f9ad2a8, 
    envp=<value optimized out>) at main.c:383
Comment 2 Eric Anholt 2008-12-14 19:15:40 UTC
Fix for review posted to the mailing list:

commit 5e0a99e274cbe1aa661a53f96a3a57cd44dde42c
Author: Eric Anholt <eric@anholt.net>
Date:   Sun Dec 14 19:05:04 2008 -0800

    drm/i915: Don't return busy for buffers left on the flushing list.
    
    These buffers don't have active rendering still occurring to them, they just
    need either a flush to be emitted or a retire_requests to occur so that we
    notice they're done.  Return unbusy so that one of the two occurs.  The two
    expected consumers of this interface (OpenGL and libdrm_intel BO cache) both
    want this behavior.
Comment 3 Eric Anholt 2008-12-19 13:34:38 UTC
Fix has been pushed at linus.
Comment 4 Ben Gamari 2008-12-19 13:46:11 UTC
Yeah, things seem to be much more stable now. Now the only real stability issue I'm seeing is the random GPU hangs.