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/] _______________________________________________ xorg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xorg
