Lockup on intel dri

[Colin Guthrie]

Eric Anholt wrote:
> 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.

I'll double check to see if there are any weird patches we apply that 
could cause this.

Well it's generally triggered when "using" the desktop. As I am running 
compiz I'm tagging it as the app that triggers it and it does indeed run 
in direct rendering mode AFAIK.

I'll see if I can get a gdb backtrace, but it's tricky at home as I only 
have one sensible machine here so sshing in to get the backtrace is 
tricky (can be done with a bit of jiggery pokery on my headless machine 
+ a telly!)

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
   Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
   Mandriva Linux Contributor [http://www.mandriva.com/]
   PulseAudio Hacker [http://www.pulseaudio.org/]
   Trac Hacker [http://trac.edgewall.org/]