Lockup on intel dri

[Eric Anholt]

On Fri, 2008-10-24 at 10:55 +0100, Colin Guthrie wrote:
> Hi,
> 
> I'm wondering if anyone can advice of how to address this lockup?
> 
> I'm running mesa master from a couple days ago + a few minor patches 
> (quite similar to the Fedora dev package) + xserver 1.5.2 + patches 
> (very similar to the Fedora dev package - I also cherry picked the dix 
> backtrace stuff too). I'm using intel 2.5.0.
> 
> I'm getting the
> [mi] mieqEnequeue: out-of-order valuator event; dropping.
> [mi] EQ overflowing. The server is probably stuck in an infinite loop.
> error but I know that's somewhat misleading.
> 
> As I have the backtrace cherry-picks from master the following was 
> dumped into my log.
> [mi] EQ overflowing. The server is probably stuck in an infinite loop.
> Backtrace:
> 0: /etc/X11/X(xorg_backtrace+0x26) [0x4e6d56]
> 1: /etc/X11/X(mieqEnqueue+0x291) [0x4c75d1]
> 2: /etc/X11/X(xf86PostMotionEventP+0xc4) [0x4831d4]
> 3: /etc/X11/X(xf86PostMotionEvent+0xb1) [0x4833b1]
> 4: /usr/lib64/xorg/modules/input//evdev_drv.so [0x7f67798bbf46]
> 5: /etc/X11/X [0x484115]
> 6: /etc/X11/X [0x4671d7]
> 7: /lib64/libpthread.so.0 [0x7f677cf38d20]
> 8: /lib64/libpthread.so.0 [0x7f677cf37694]
> 9: /lib64/libpthread.so.0 [0x7f677cf32f34]
> 10: /lib64/libpthread.so.0(pthread_mutex_lock+0x71) [0x7f677cf32941]
> 11: /usr/lib64/libdrm_intel.so.1 [0x7f6779ed6664]
> 12: /usr/lib64/dri/i915_dri.so(_intel_batchbuffer_flush+0x186) 
> [0x7f6768dc9d1f]
> 13: /usr/lib64/dri/i915_dri.so(intelFlush+0xe9) [0x7f6768dde202]
> 14: /usr/lib64/libdricore.so(_mesa_Flush+0x64) [0x7f67689e158c]
> 15: /usr/lib64/xorg/modules/extensions//libglx.so [0x7f677a9c5a9b]
> 16: /usr/lib64/xorg/modules/extensions//libglx.so [0x7f677a9c1e32]
> 17: /etc/X11/X(Dispatch+0x364) [0x447464]
> 18: /etc/X11/X(main+0x45d) [0x42d64d]
> 19: /lib64/libc.so.6(__libc_start_main+0xe6) [0x7f677b8d8316]
> 20: /etc/X11/X(FontFileCompleteXLFD+0x279) [0x42ca29]
> 
> 
> I don't have anything special in my kernel and I'm not using GEM. My h/w 
> is i945GM.
> 
> The above was with an older evdev, but (as it was mentioned, I upgraded 
> to 2.0.99.2 and got the following (similar output):
> [mi] EQ overflowing. The server is probably stuck in an infinite loop.
> Backtrace:
> 0: /etc/X11/X(xorg_backtrace+0x26) [0x4e6d56]
> 1: /etc/X11/X(mieqEnqueue+0x291) [0x4c75d1]
> 2: /etc/X11/X(xf86PostMotionEventP+0xc4) [0x4831d4]
> 3: /etc/X11/X(xf86PostMotionEvent+0xb1) [0x4833b1]
> 4: /usr/lib64/xorg/modules/input//evdev_drv.so [0x7f48dc25d1a7]
> 5: /etc/X11/X [0x484115]
> 6: /etc/X11/X [0x4671d7]
> 7: /lib64/libpthread.so.0 [0x7f48df8dad20]
> 8: /lib64/libpthread.so.0 [0x7f48df8d9694]
> 9: /lib64/libpthread.so.0 [0x7f48df8d4f34]
> 10: /lib64/libpthread.so.0(pthread_mutex_lock+0x71) [0x7f48df8d4941]
> 11: /usr/lib64/libdrm_intel.so.1 [0x7f48dc878664]
> 12: /usr/lib64/dri/i915_dri.so(_intel_batchbuffer_flush+0x186) 
> [0x7f48cb76ad1f]
> 13: /usr/lib64/dri/i915_dri.so(intelFlush+0xe9) [0x7f48cb77f202]
> 14: /usr/lib64/dri/i915_dri.so [0x7f48cb76c7ba]
> 15: /usr/lib64/dri/i915_dri.so(intelTexImage2D+0x7d) [0x7f48cb76d4f3]
> 16: /usr/lib64/libdricore.so(_mesa_TexImage2D+0x2a9) [0x7f48cb3fdc71]
> 17: /usr/lib64/xorg/modules/extensions//libglx.so [0x7f48dd36d933]
> 18: /usr/lib64/xorg/modules/extensions//libglx.so [0x7f48dd360a87]
> 19: /usr/lib64/xorg/modules/extensions//libglx.so [0x7f48dd35fa42]
> 20: /usr/lib64/xorg/modules/extensions//libglx.so [0x7f48dd363e32]
> 21: /etc/X11/X(Dispatch+0x364) [0x447464]
> 22: /etc/X11/X(main+0x45d) [0x42d64d]
> 23: /lib64/libc.so.6(__libc_start_main+0xe6) [0x7f48de27a316]
> 24: /etc/X11/X(FontFileCompleteXLFD+0x279) [0x42ca29]
> 
> 
> (evdev itself did odd things but that's another story!)
> 
> 
> Any ideas?

So, it looks like somebody leaked the lock in libdrm, or we're
attempting to double-lock it.  The second seems unlikely since we
batchbuffer_flush so regularly, but it's hard to say.  Could you get a
gdb backtrace?  A lot of information is missing in server backtraces.
Also, does whatever app you're running that causes this failure run in
direct rendering mode?  That may make it easier to get a decent
backtrace.

-- 
Eric Anholt
eric at anholt.net                         eric.anholt at intel.com


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg/attachments/20081024/628625cd/attachment.pgp>