|Summary:||[GM965 GEM UXA] UXA crashes X server|
|Product:||xorg||Reporter:||Ben Gamari <bgamari>|
|Component:||Driver/intel||Assignee:||Eric Anholt <eric>|
|Status:||RESOLVED FIXED||QA Contact:||Xorg Project Team <xorg-team>|
|i915 platform:||i915 features:|
|Bug Depends on:|
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 <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.
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.
on May 26, 2016 at 16:25:12.
(provided by the Example extension).