Bug#651318: xserver-xorg: EQ overflowing -- probably stuck in an infinite loop
I recently obtained the same bug as reported by Nelson, that is the X
server suddenly freezes for few seconds. I have no idea the reason of
the freeze, or of any possibility to reproduce the condition of the
freeze. As far as I know, they seem to be totally random. One can
experience the freeze few minutes after a fresh X restart after a
freeze, or may work without any problems during several days with the
same X server.
When back from the freeze, the mouse pointer can be moved, but that it.
Actually, it seems that the focus is stuck to the last focused window
(keyboard is only sending its events to the same active window area,
whatever what is done with the mouse, which may result in a seemingly
non responding keyboard if the corresponding area do not react to the
keyboard). Clicking on mouse buttons seems to result in what would have
been obtained when clicking in always the same position (where the mouse
was during the freeze?), wherever is really the pointer.
Using awesome as a WM, I couldn't use any keyboard shortcut to interact
with it (even global shortcuts that are not sent to any windows). I
could however switch to a VT terminal by Ctrl-Alt-F1, connect to a
screen session possessing the right access to DISPLAY and DBUS, and send
commands to awesome by awesome-client, that seemed to answer normally.
Restarting the WM by awesome.restart() does nothing, it is necessary to
awesome.quit() the relog, i.e. to restart the X server. If by chance the
server gets frozen when a X terminal is focused, it is possible to
directly interact with awesome frome there.
I obtain the same error i Xorg.0.log than Nelson obtains:
[ 56505.935] [mi] EQ overflowing. The server is probably stuck in an
[ 56505.936] 0: /usr/bin/X (xorg_backtrace+0x26) [0x7f85ccea14d6]
[ 56505.936] 1: /usr/bin/X (mieqEnqueue+0x191) [0x7f85cce81de1]
[ 56505.936] 2: /usr/bin/X (0x7f85ccd1d000+0x65254) [0x7f85ccd82254]
[ 56505.936] 3: /usr/bin/X (xf86PostButtonEvent+0xdd) [0x7f85ccdbcddd]
[ 56505.936] 4: /usr/lib/xorg/modules/input/synaptics_drv.so
[ 56505.936] 5: /usr/lib/xorg/modules/input/synaptics_drv.so
[ 56505.936] 6: /usr/bin/X (0x7f85ccd1d000+0x8a947) [0x7f85ccda7947]
[ 56505.936] 7: /usr/bin/X (0x7f85ccd1d000+0xb052e) [0x7f85ccdcd52e]
[ 56505.936] 8: /lib/x86_64-linux-gnu/libpthread.so.0
[ 56505.936] 9: /lib/x86_64-linux-gnu/libc.so.6 (__select+0x13)
[ 56505.936] 10: /usr/bin/X (WaitForSomething+0x19b) [0x7f85cce9e8bb]
[ 56505.936] 11: /usr/bin/X (0x7f85ccd1d000+0x51cd2) [0x7f85ccd6ecd2]
[ 56505.936] 12: /usr/bin/X (0x7f85ccd1d000+0x411aa) [0x7f85ccd5e1aa]
[ 56505.936] 13: /lib/x86_64-linux-gnu/libc.so.6
[ 56505.936] 14: /usr/bin/X (0x7f85ccd1d000+0x4149d) [0x7f85ccd5e49d]
I have a different configuration, namely as for the video chipset:
lspci | grep VGA â
00:02.0 VGA compatible controller: Intel Corporation Core Processor
Integrated Graphics Controller (rev 02)
Please tell me if you need some additional informations about my config.
So it really seems that after the lock up, it is only the communication
between X server and mouse/keyboards that is broken (partially, but
sufficient to render the X session unusable). Probably a problem from
synaptics_drv as reported in Xorg.0.log ?