|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 <firstname.lastname@example.org> 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.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct.