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
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
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)
#5 0x00007f2866a76191 in uxa_fill_region_solid (
pDrawable=<value optimized out>, pRegion=0x224e0e0,
pixel=<value optimized out>, planemask=4294967295, alu=3)
#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
Fix for review posted to the mailing list:
Author: Eric Anholt <email@example.com>
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.
Fix has been pushed at linus.
Yeah, things seem to be much more stable now. Now the only real stability issue I'm seeing is the random GPU hangs.
on Mar 26, 2017 at 01:29:03.
(provided by the Example extension).