Bug 15473 - DGA Mouse causes ut2004 to overflow mieq
DGA Mouse causes ut2004 to overflow mieq
Status: RESOLVED INVALID
Product: xorg
Classification: Unclassified
Component: Server/General
git
x86 (IA32) Linux (All)
: high critical
Assigned To: Xorg Project Team
Xorg Project Team
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-04-12 14:51 UTC by Jie Luo
Modified: 2011-10-15 14:01 UTC (History)
18 users (show)

See Also:


Attachments
Xorg.0.log (26.21 KB, text/plain)
2008-04-12 14:51 UTC, Jie Luo
no flags Details
Xorg.0.log after resume (124.32 KB, text/plain)
2008-04-19 19:56 UTC, Jie Luo
no flags Details
Xorg.0.log.old after the freeze (59.59 KB, application/x-trash)
2009-03-20 19:59 UTC, Götz
no flags Details
Xorg.log after freeze with backtrace at the end. (296.24 KB, text/plain)
2010-02-21 10:06 UTC, Kai
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jie Luo 2008-04-12 14:51:20 UTC
Created attachment 15854 [details]
Xorg.0.log

Unreal Tournament 2004 demo will run correctly first, then when the mouse come out, it will make xserver dead lock. There are tons of 

[mi] mieqEnequeue: out-of-order valuator event; dropping.
[mi] EQ overflowing. The server is probably stuck in an infinite loop.

message.

I'm using xserver git, mesa git, and intel driver git. To reproduce it, you just need the Unreal Tournament 2004 demo.
Comment 1 Jie Luo 2008-04-19 19:55:36 UTC
This bug is being triggered several times recently when resume from suspend. It seams this is a known problem, but it is not easy to trigger it in the past. Now this bug seams much easy to be triggered. Can we fix this?
Comment 2 Jie Luo 2008-04-19 19:56:52 UTC
Created attachment 16048 [details]
Xorg.0.log after resume
Comment 3 Jie Luo 2008-04-25 17:54:30 UTC
This bug seems much easy to be triggered by git xserver and kernel 2.6.25. After resume from suspend, X is locked, doesn't response to keyboard and mouse. 

Is there any plan to fix mieqEnqueue? It seems current design has some limitation.
Comment 4 Peter Hutterer 2008-04-25 23:34:32 UTC
(In reply to comment #3)
> This bug seems much easy to be triggered by git xserver and kernel 2.6.25.
> After resume from suspend, X is locked, doesn't response to keyboard and mouse. 
> 
> Is there any plan to fix mieqEnqueue? It seems current design has some
> limitation.

well, the "fix" would be to increase the EQ size from the current 512 events to something larger. This would only remove the symptom though, not the problem (which is that something isn't fast enough in waking up, causing the mouse to generate a lot of events before they are processed). 

I even doubt that with a larger queue the problem goes away. But - to be sure - please recompile with a larger QUEUE_SIZE in xserver/mi/mieq.c

If it overflows with a larger queue, something is definitely stuck somewhere.
Comment 5 Jie Luo 2008-04-26 23:28:42 UTC
(In reply to comment #4)
> (In reply to comment #3)
> > This bug seems much easy to be triggered by git xserver and kernel 2.6.25.
> > After resume from suspend, X is locked, doesn't response to keyboard and mouse. 
> > 
> > Is there any plan to fix mieqEnqueue? It seems current design has some
> > limitation.
> 
> well, the "fix" would be to increase the EQ size from the current 512 events to
> something larger. This would only remove the symptom though, not the problem
> (which is that something isn't fast enough in waking up, causing the mouse to
> generate a lot of events before they are processed). 
> 
> I even doubt that with a larger queue the problem goes away. But - to be sure -
> please recompile with a larger QUEUE_SIZE in xserver/mi/mieq.c

I change the QUEUE_SIZE to 1024. It seems help, I didn't hit this problem for a while. I'll see how it works in long term. 

> 
> If it overflows with a larger queue, something is definitely stuck somewhere.
> 

Is fixing for this part in you TODO list of input rework? Thanks for your time.
Comment 6 Peter Hutterer 2008-04-27 20:45:55 UTC
(In reply to comment #5)
> (In reply to comment #4)
> > (In reply to comment #3)
> > I even doubt that with a larger queue the problem goes away. But - to be sure -
> > please recompile with a larger QUEUE_SIZE in xserver/mi/mieq.c
> 
> I change the QUEUE_SIZE to 1024. It seems help, I didn't hit this problem for a
> while. I'll see how it works in long term.

ok, let us know how it works. If you are confident that the problem went away, I can push the fix.

> > If it overflows with a larger queue, something is definitely stuck somewhere.
> > 
> 
> Is fixing for this part in you TODO list of input rework? Thanks for your time.

sort of. We should find the cause of the problem (graphics driver maybe?) and fix this. If not, we can extend the queue size. 

Have you had the same problem with other kernels or graphics drivers?
Comment 7 Jie Luo 2008-04-28 17:03:41 UTC
(In reply to comment #6)
> (In reply to comment #5)
> > (In reply to comment #4)
> > > (In reply to comment #3)
> > > I even doubt that with a larger queue the problem goes away. But - to be sure -
> > > please recompile with a larger QUEUE_SIZE in xserver/mi/mieq.c
> > 
> > I change the QUEUE_SIZE to 1024. It seems help, I didn't hit this problem for a
> > while. I'll see how it works in long term.
> 
> ok, let us know how it works. If you are confident that the problem went away,
> I can push the fix.
> 
> > > If it overflows with a larger queue, something is definitely stuck somewhere.
> > > 
> > 
> > Is fixing for this part in you TODO list of input rework? Thanks for your time.
> 
> sort of. We should find the cause of the problem (graphics driver maybe?) and
> fix this. If not, we can extend the queue size. 
> 
> Have you had the same problem with other kernels or graphics drivers?
> 

Yes, I find the drm module in 2.6.25 kernel didn't work fine with the current dri driver and xserver. It will cause X lock up when you try to run some OpenGL program after resume. So maybe that is the cause of this problem.

Currently, I find avoid to run OpenGL after resume (don't use compiz), then I can't reproduce this bug even with QUEUE_SIZE 512.
Comment 8 Jie Luo 2008-04-28 17:07:56 UTC
> Yes, I find the drm module in 2.6.25 kernel didn't work fine with the current
   |
   `~ I mean only one or two times, and I can't reproduce them.

> dri driver and xserver. It will cause X lock up when you try to run some OpenGL
> program after resume. So maybe that is the cause of this problem.
> 
> Currently, I find avoid to run OpenGL after resume (don't use compiz), then I
> can't reproduce this bug even with QUEUE_SIZE 512.
> 

Comment 9 Peter Hutterer 2008-04-28 17:22:00 UTC
(In reply to comment #7)
> Yes, I find the drm module in 2.6.25 kernel didn't work fine with the current
> dri driver and xserver. It will cause X lock up when you try to run some OpenGL
> program after resume. So maybe that is the cause of this problem.
> 
> Currently, I find avoid to run OpenGL after resume (don't use compiz), then I
> can't reproduce this bug even with QUEUE_SIZE 512.

Yep, this indicates that the problem is with OpenGL or the driver, but that's not my territory. You'll have to wait for s.b. else to pick it up.

Comment 10 Tobias Jakobi 2008-09-23 14:15:30 UTC
I have the same issue with this setup:
- xorg-server-1.5.0
- mesa-7.2
- libdrm-2.3.1
- xf86-input-evdev-2.0.4
- gentoo-sources-2.6.26-r1

I can reproduce the X input lock up with this games:
- UT2004 demo
- ioquake3 (+demo files)

X doesn't really lock up completly for me. When pressing the ACPI power button I can see how the game is closed by X and also the other windows in the background. The system then does shutdown like normal.

Lots of
"[mi] EQ overflowing. The server is probably stuck in an infinite loop.
[mi] mieqEnequeue: out-of-order valuator event; dropping."
in the Xorg.0.log.

Note that both games use SDL for input management. Maybe this also has to do with SDL.

Greets,
Tobias
Comment 11 Michel Dänzer 2008-09-24 00:37:57 UTC
Does setting the environment variable SDL_VIDEO_X11_DGAMOUSE=0 for running the affected games work around the problem?
Comment 12 Tobias Jakobi 2008-09-24 09:34:39 UTC
(In reply to comment #11)
> Does setting the environment variable SDL_VIDEO_X11_DGAMOUSE=0 for running the
> affected games work around the problem?
> 
Yep, disabling DGA mouse fixes the problem for both ioquake3 and ut2004-demo.
Comment 13 xvalentinex 2008-09-25 14:42:27 UTC
I experience similar issues.

My Setup
Arch Linux
xorg-server 1.5.0
xf86-video-ati 6.9.0
libgl 7.1
mesa 7.1
libdrm 2.3.1
linux 2.6.26.5


I am using direct rendering and desktop effects with KDE 4.1.1.

Xorg will randomly lock up.  The only think that seems to work is mouse movement, not mouse clicks or the keyboard.  A hard reboot is the only fix.

logs show this repeating hundreds of times.
[mi] mieqEnequeue: out-of-order valuator event; dropping.                                              
[mi] EQ overflowing. The server is probably stuck in an infinite loop.


I have DGA disabled via the following xorg.conf module config:
        SubSection "extmod"
                Option      "omit xfree86-dga"
        EndSubSection 
Comment 14 Peter 2008-10-01 02:07:51 UTC
I've experienced similar issue: same error in logs and full lock, had to reboot my desktop from remote. Note: I have not used any opengl on my desktop at that time, no games... I've just had remote applications opened (using NX)

Gentoo linux
kernel gentoo-sources-2.6.26-r1
xorg-server-1.5.0
mesa-7.2
x11-libs/libdrm-2.3.1
openchrome drivers (svn version > 0.2.903)
x11-drivers/xf86-input-evdev-2.0.5
Comment 15 Renato Caldas 2008-11-20 09:00:50 UTC
*** Bug 18444 has been marked as a duplicate of this bug. ***
Comment 16 Renato Caldas 2008-11-20 09:02:45 UTC
*** Bug 18631 has been marked as a duplicate of this bug. ***
Comment 17 Renato Caldas 2008-11-20 09:06:48 UTC
It seems that this has spread outside of git Xserver...
Comment 18 Luc Verhaegen 2008-11-20 09:14:41 UTC
Renato... Feel free to explain why these bugs are duplicates...

As detailed before, the mieqEnqueue messages are a symptom and not the cause of the bug. The cause is usually something else entirely. These bugs are most likely not duplicates at all.
Comment 19 Renato Caldas 2008-11-20 09:53:32 UTC
Bug 18631 seems to be somewhat related to the drawing of the mouse cursor:

0: X(xorg_backtrace+0x39) [0x8149bad]
1: X(mieqEnqueue+0x20f) [0x81255d4]
2: X(xf86PostMotionEventP+0x1dd) [0x80c441e]
3: X(xf86PostMotionEvent+0x9a) [0x80c423b]
4: /usr/lib/X11/modules/input//mouse_drv.so [0xb7a5f954]
5: /usr/lib/X11/modules/input//mouse_drv.so [0xb7a6004c]
6: /usr/lib/X11/modules/input//mouse_drv.so [0xb7a605fa]
7: X [0x80df9a2]
8: X [0x80c1c17]
9: [0xb7f81400]
10: /usr/lib/libdrm.so.2(drmCommandWrite+0x34) [0xb7a4e2b4]
11: /usr/lib/X11/modules/drivers//intel_drv.so(I830Sync+0x116) [0xb79a9a1e]
12: /usr/lib/X11/modules/drivers//intel_drv.so [0xb79e30ef]
13: /usr/lib/X11/modules//libexa.so(exaWaitSync+0x63) [0xb788abf6]
14: /usr/lib/X11/modules//libexa.so(ExaDoPrepareAccess+0x96) [0xb7889c71]
15: /usr/lib/X11/modules//libexa.so(ExaCheckPutImage+0x72) [0xb7892f47]
16: /usr/lib/X11/modules//libexa.so [0xb788b6ad]
17: X [0x81a44f8]
18: X(ProcPutImage+0x41a) [0x8087776]
19: X(Dispatch+0x228) [0x80835c2]
20: X(main+0x6da) [0x806a4ae]
21: /lib/libc.so.6(__libc_start_main+0xe5) [0xb7b88925]
22: X [0x8069d01]

This bug also seems related to the drawing of the mouse cursor, so much that switching off DGA cursor fixes/delays the problem for some.

As for bug 18444 there isn't much useful info (a backtrace would be nice), but the fact that only the mouse moves makes me believe it may have something to do with it.

I may be wrong, but these reports exhibit at least very similar symptoms, so they might as well be debugged in conjunction. As I said on each report, feel free to "un-dupe" if proved otherwise :)
Comment 20 Luc Verhaegen 2008-11-21 04:58:04 UTC
Why do you think the eventqueue is stuffed? Because the xserver is too bloody busy elsewhere to fully handle events in a timely manner.

Which is exactly what the log tells you:
[mi] EQ overflowing. The server is probably stuck in an infinite loop.

Stop blindly focusing on the symptom. and finally realise that the cause is something else entirely.

These are not duplicates.

Fix the wrong duplication you introduced and then let the developers responsible for their drivers and subsystems resume their normal work, without needless noise or interruption.
Comment 21 Renato Caldas 2008-11-21 05:41:56 UTC
(In reply to comment #20)
> (...)
> Stop blindly focusing on the symptom. and finally realise that the cause is
> something else entirely.

You're right, sorry. But they do seem to be using similar setups, namely:

Xorg server 1.5.x
DRI drivers

> These are not duplicates.
> 
> Fix the wrong duplication you introduced and then let the developers
> responsible for their drivers and subsystems resume their normal work, without
> needless noise or interruption.

Done. Sorry for the noise.
Comment 22 Wes 2009-03-02 08:13:06 UTC
Hi All,

This bug is also being tracked here :

https://bugzilla.redhat.com/show_bug.cgi?id=465884

More information and more logs are available.   A colleague and I both have this problem.

Acer Laptops
Intel Graphics Driver (on different chipsets)
Unable to reproduce by performing same steps (ie random hang).
Can ssh into a dead machine.
Hard power down is the only way out.

Due to a complete system lockup and the random nature of the bug, I would consider this to be a higher priority that medium, but knowing how aggressively reactionary *some* people can be to such things, i'll leave that decision to someone else.
Comment 23 Götz 2009-03-20 19:59:45 UTC
Created attachment 24111 [details]
Xorg.0.log.old after the freeze

I'm also affected by this bug. I could find this in Xorg.0.log.old

...
exaCopyDirty: Pending damage region empty!                                             
[mi] EQ overflowing. The server is probably stuck in an infinite loop. 
[mi] EQ overflowing. The server is probably stuck in an infinite loop. 
...

The screen freezes and only the mouse moves, but no clicks are tracked. I can only reboot using SysRq.

I can only reproduce this bug using (K)Ubuntu Jaunty 9.04 using EXA or UXA (can't but with XAA) with Kwin OpenGL composition (but not with Xrender) when moving some windows or minimizing/maximizing.

xserver-xorg-video-intel 2:2.6.99.1+git20090319.bedc894a-0ubuntu0tormod
libdrm-intel1 2.4.5+git20090314.82eac806-0ubuntu0tormod2
libdrm2 2.4.5+git20090314.82eac806-0ubuntu0tormod2
xserver-xorg-core 2:1.6.0-0ubuntu4
libgl1-mesa-dri 7.3.0+git20090320+mesa-7-4-branch.b009a32b-0ubuntu0tormod
linux-image-2.6.29-020629rc8-generic 2.6.29-020629rc8
Comment 24 Kai 2010-02-21 10:06:59 UTC
Created attachment 33474 [details]
Xorg.log after freeze with backtrace at the end.

I'm seeing this bug too with the following system:
GPU: R300
Kernel: 2.6.32.8
X.org: 1.7.4
Mesa: 7.6.1
Radeon driver: 6.12.4 + commits up to 712ac98a
Essentially Debian Testing except the Kernel (self-built) and the radeon driver
(from Unstable, because it fixes <http://bugs.debian.org/565506>).

It happens for me most often in Iceweasel (that is the rebranded Firefox), but also in other applications. The probability of hitting the bug is much higher, when KDE's compositing is active. But deactivating it, isn't a safe-guard (the log attached with this comment was with deactivated Compositing and while loading a page in Iceweasel).
Comment 25 blaise 2010-02-28 09:57:27 UTC
(In reply to comment #4)
> (In reply to comment #3)
> > This bug seems much easy to be triggered by git xserver and kernel 2.6.25.
> > After resume from suspend, X is locked, doesn't response to keyboard and mouse. 
> > 
> > Is there any plan to fix mieqEnqueue? It seems current design has some
> > limitation.
> 
> well, the "fix" would be to increase the EQ size from the current 512 events to
> something larger. This would only remove the symptom though, not the problem
> (which is that something isn't fast enough in waking up, causing the mouse to
> generate a lot of events before they are processed). 
> 
> I even doubt that with a larger queue the problem goes away. But - to be sure -
> please recompile with a larger QUEUE_SIZE in xserver/mi/mieq.c
> 
> If it overflows with a larger queue, something is definitely stuck somewhere.
> 

Thanks for the tip. After purchasing a new logitech usb wireless mouse I was experiencing this problem. I raised the queue_size to 4096 and everything works OK.

Comment 26 Kai 2010-03-18 14:37:25 UTC
With the advent of kernel version 2.6.33(.1) I've switched to KMS (with the 6.12.192 radeon driver) and haven't been able to hit this bug anymore ever since.
Comment 27 Kai 2010-04-12 09:48:24 UTC
And there it is again:
[mi] EQ overflowing. The server is probably stuck in an infinite loop.

Backtrace:
0: /usr/bin/X (xorg_backtrace+0x3b) [0x80ad72b]
1: /usr/bin/X (mieqEnqueue+0x1ab) [0x80a023b]
2: /usr/bin/X (xf86PostMotionEventP+0xd2) [0x80b2c02]
3: /usr/lib/xorg/modules/input/evdev_drv.so (0xb7073000+0x4801) [0xb7077801]
4: /usr/lib/xorg/modules/input/evdev_drv.so (0xb7073000+0x4af6) [0xb7077af6]
5: /usr/bin/X (0x8048000+0x6920f) [0x80b120f]
6: /usr/bin/X (0x8048000+0x106804) [0x814e804]
7: (vdso) (__kernel_sigreturn+0x0) [0xb7871400]
8: /usr/lib/libpixman-1.so.0 (0xb7795000+0x13dd9) [0xb77a8dd9]
9: /usr/lib/libpixman-1.so.0 (0xb7795000+0x39a6d) [0xb77cea6d]
10: /usr/lib/libpixman-1.so.0 (0xb7795000+0x4180a) [0xb77d680a]
11: /usr/lib/libpixman-1.so.0 (0xb7795000+0x42a2a) [0xb77d7a2a]
12: /usr/lib/libpixman-1.so.0 (0xb7795000+0x39763) [0xb77ce763]
13: /usr/lib/libpixman-1.so.0 (0xb7795000+0x14953) [0xb77a9953]
14: /usr/lib/libpixman-1.so.0 (0xb7795000+0x3b75e) [0xb77d075e]
15: /usr/lib/libpixman-1.so.0 (0xb7795000+0x14953) [0xb77a9953]
16: /usr/lib/libpixman-1.so.0 (0xb7795000+0x46b63) [0xb77dbb63]
17: /usr/lib/libpixman-1.so.0 (0xb7795000+0x14953) [0xb77a9953]
18: /usr/lib/libpixman-1.so.0 (pixman_image_composite+0x16f) [0xb77cf5df]
19: /usr/lib/xorg/modules/libfb.so (fbComposite+0x1fe) [0xb73204fe]
20: /usr/lib/xorg/modules/libexa.so (0xb72f8000+0xfc3b) [0xb7307c3b]
21: /usr/lib/xorg/modules/libexa.so (0xb72f8000+0xd30b) [0xb730530b]
22: /usr/bin/X (0x8048000+0xca5fb) [0x81125fb]
23: /usr/bin/X (CompositePicture+0x298) [0x8102f68]
24: /usr/bin/X (0x8048000+0xc39fd) [0x810b9fd]
25: /usr/bin/X (0x8048000+0xc06d3) [0x81086d3]
26: /usr/bin/X (0x8048000+0x2c117) [0x8074117]
27: /usr/bin/X (0x8048000+0x1e93a) [0x806693a]
28: /lib/i686/cmov/libc.so.6 (__libc_start_main+0xe5) [0xb75a2b55]
29: /usr/bin/X (0x8048000+0x1e521) [0x8066521]

Now using:
X.Org X Server 1.7.6
Radeon driver: 6.13.0 (R300)
Mesa: 7.7.1
Kernel: 2.6.33.2 (with KMS)
Comment 28 Kai 2010-04-12 09:49:35 UTC
*** Bug 25166 has been marked as a duplicate of this bug. ***
Comment 29 B. A. 2010-09-14 00:08:54 UTC
The problem affects me too. On Ubuntu 10.04 (amd64) with fglrx

X.Org X Server 1.7.6
fglrx 8.723.1
Kernel: 2.6.32.x

On resuming I get sometimes this error in Xorg.0.log => only reset helps.

I think that it is also related to my PS/2 to USB Converter, which needs probably too many events and so triggers this error.
I had this issue never before using this PS/2 to USB Converter.
But I have to use it, else my PS2 isn't working.

(II) UnloadModule: "evdev"
(II) XKB: reuse xkmfile /var/lib/xkb/server-30847DE7A116C3E56CC957FB5D66B6975803FC85.xkm
(II) fglrx(0): Preparing suspend from graphics mode...
(II) AIGLX: Suspending AIGLX clients for VT switch
(II) fglrx(0): Backup framebuffer data.
(II) fglrx(0): Backup complete.
(II) fglrx(0): Preparing resume to graphics mode...
(II) Open ACPI successful (/var/run/acpid.socket)
(II) AIGLX: Resuming AIGLX clients after VT switch
(II) fglrx(0): Suspend/Resume detected. Restoring framebuffer data.
(II) fglrx(0): Restore complete.
(II) fglrx(0): UVD2 feature is available
(II) fglrx(0): User Preference Output CRT2 using refresh rate 75.0 Hz.
(II) Power Button: Device reopened after 1 attempts.
(II) Power Button: Device reopened after 1 attempts.
(II) CHESEN PS2 to USB Converter: Device reopened after 1 attempts.
(II) CHESEN PS2 to USB Converter: Device reopened after 1 attempts.
(II) Macintosh mouse button emulation: Device reopened after 1 attempts.
(II) fglrx(0): Hot-plug event occurs on device: 1:0:0 
(II) Logitech USB Receiver: Device reopened after 1 attempts.
[mi] EQ overflowing. The server is probably stuck in an infinite loop.

Backtrace:
0: /usr/bin/X (xorg_backtrace+0x28) [0x4a3258]
1: /usr/bin/X (mieqEnqueue+0x1f4) [0x4a2ad4]
2: /usr/bin/X (xf86PostKeyEventP+0x67) [0x47c887]
3: /usr/bin/X (xf86PostKeyboardEvent+0x19) [0x47c919]
4: /usr/lib/xorg/modules/input/evdev_drv.so (0x7f4ed973f000+0x540f) [0x7f4ed974440f]
5: /usr/bin/X (0x400000+0x6fcb7) [0x46fcb7]
6: /usr/bin/X (0x400000+0x11d1d3) [0x51d1d3]
7: /lib/libpthread.so.0 (0x7f4ee2bed000+0xf8f0) [0x7f4ee2bfc8f0]
8: /lib/libc.so.6 (ioctl+0x7) [0x7f4ee19a4187]
9: /usr/lib/fglrx/libatiuki.so.1 (ukiGetLock+0x7b) [0x7f4edf3b28bb]
10: /usr/lib/xorg/extra-modules/modules/drivers/fglrx_drv.so (swlDriLock+0x80) [0x7f4edf854260]
11: /usr/lib/xorg/extra-modules/modules/drivers/fglrx_drv.so (swlDriDoWakeupHandler+0x40) [0x7f4edf853790]
12: /usr/lib/xorg/extra-modules/modules/drivers/fglrx_drv.so (0x7f4edf5c5000+0x27a62a) [0x7f4edf83f62a]
13: /usr/lib/xorg/extra-modules/modules/drivers/fglrx_drv.so (swlDriWakeupHandler+0x74) [0x7f4edf8536c4]
14: /usr/bin/X (WakeupHandler+0x4b) [0x435f2b]
15: /usr/bin/X (WaitForSomething+0x1d7) [0x45f9a7]
16: /usr/bin/X (0x400000+0x30952) [0x430952]
17: /usr/bin/X (0x400000+0x261aa) [0x4261aa]
18: /lib/libc.so.6 (__libc_start_main+0xfd) [0x7f4ee18e4c4d]
19: /usr/bin/X (0x400000+0x25d59) [0x425d59]
Comment 30 Willem Verstraeten 2010-09-29 00:43:05 UTC
I am also affected :



X.Org X Server 1.7.6
Release Date: 2010-03-17
X Protocol Version 11, Revision 0
Build Operating System: Linux 2.6.24-27-server i686 Ubuntu
Current Operating System: Linux nuuk 2.6.32-25-generic #44-Ubuntu SMP Fri Sep 17 20:26:08 UTC 2010 i686
Kernel command line: root=/dev/mapper/nuuk-nuuk ro quiet splash
Build Date: 21 July 2010  12:47:34PM
xorg-server 2:1.7.6-2ubuntu7.3 (For technical support please see http://www.ubuntu.com/support)
Current version of pixman: 0.16.4
        Before reporting problems, check http://wiki.x.org
        to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
        (++) from command line, (!!) notice, (II) informational,
        (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Tue Sep 28 18:46:44 2010
(==) Using config file: "/etc/X11/xorg.conf"
(==) Using config directory: "/usr/lib/X11/xorg.conf.d"
(==) ServerLayout "Layout0"
(**) |-->Screen "Screen0" (0)
(**) |   |-->Monitor "Monitor0"
(**) |   |-->Device "Device0"
(**) Option "Xinerama" "0"
(==) Automatically adding devices
(==) Automatically enabling devices
(WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
        Entry deleted from font path.
(==) FontPath set to:
        /usr/share/fonts/X11/misc,
        /usr/share/fonts/X11/100dpi/:unscaled,
        /usr/share/fonts/X11/75dpi/:unscaled,
        /usr/share/fonts/X11/Type1,
        /usr/share/fonts/X11/100dpi,
        /usr/share/fonts/X11/75dpi,
        /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType,
        built-ins
(==) ModulePath set to "/usr/lib/xorg/extra-modules,/usr/lib/xorg/modules"
(II) The server relies on udev to provide the list of input devices.
        If no devices become available, reconfigure udev or disable AutoAddDevices.
(II) Loader magic: 0x81f0e80
(II) Module ABI versions:
        X.Org ANSI C Emulation: 0.4
        X.Org Video Driver: 6.0
        X.Org XInput driver : 7.0
        X.Org Server Extension : 2.0
(++) using VT number 7

(--) PCI:*(0:1:0:0) 10de:05e3:10de:065b nVidia Corporation GT200b [GeForce GTX 285] rev 161, Mem @ 0xec000000/16777216, 0xd0000000/268435456, 0xea000000/33554432, I/O @ 0x0000df00/128, BIOS @ 0x????????/524288
(II) Open ACPI successful (/var/run/acpid.socket)
(II) "extmod" will be loaded. This was enabled by default and also specified in the config file.
(II) "dbe" will be loaded. This was enabled by default and also specified in the config file.
(II) "glx" will be loaded. This was enabled by default and also specified in the config file.
(II) "record" will be loaded by default.
(II) "dri" will be loaded by default.
(II) "dri2" will be loaded by default.
(II) LoadModule: "dbe"
(II) Loading /usr/lib/xorg/modules/extensions/libdbe.so
(II) Module dbe: vendor="X.Org Foundation"
        compiled for 1.7.6, module version = 1.0.0
        Module class: X.Org Server Extension
        ABI class: X.Org Server Extension, version 2.0
(II) Loading extension DOUBLE-BUFFER
(II) LoadModule: "extmod"
(II) Loading /usr/lib/xorg/modules/extensions/libextmod.so
(II) Module extmod: vendor="X.Org Foundation"
        compiled for 1.7.6, module version = 1.0.0
        Module class: X.Org Server Extension
        ABI class: X.Org Server Extension, version 2.0
(II) Loading extension MIT-SCREEN-SAVER
(II) Loading extension XFree86-VidModeExtension
(II) Loading extension XFree86-DGA
(II) Loading extension DPMS
(II) Loading extension XVideo
(II) Loading extension XVideo-MotionCompensation
(II) Loading extension X-Resource
(II) LoadModule: "glx"
(II) Loading /usr/lib/xorg/extra-modules/libglx.so
(II) Module glx: vendor="NVIDIA Corporation"
        compiled for 4.0.2, module version = 1.0.0
        Module class: X.Org Server Extension
(II) NVIDIA GLX Module  195.36.24  Thu Apr 22 10:38:29 PDT 2010
(II) Loading extension GLX
(II) LoadModule: "record"
(II) Loading /usr/lib/xorg/modules/extensions/librecord.so
(II) Module record: vendor="X.Org Foundation"
        compiled for 1.7.6, module version = 1.13.0
        Module class: X.Org Server Extension
        ABI class: X.Org Server Extension, version 2.0
(II) Loading extension RECORD
(II) LoadModule: "dri"
(II) Loading /usr/lib/xorg/modules/extensions/libdri.so
(II) Module dri: vendor="X.Org Foundation"
        compiled for 1.7.6, module version = 1.0.0
        ABI class: X.Org Server Extension, version 2.0
(II) Loading extension XFree86-DRI
(II) LoadModule: "dri2"
(II) Loading /usr/lib/xorg/modules/extensions/libdri2.so
(II) Module dri2: vendor="X.Org Foundation"
        compiled for 1.7.6, module version = 1.1.0
        ABI class: X.Org Server Extension, version 2.0
(II) Loading extension DRI2
(II) LoadModule: "nvidia"
(II) Loading /usr/lib/xorg/extra-modules/nvidia_drv.so
(II) Module nvidia: vendor="NVIDIA Corporation"
        compiled for 4.0.2, module version = 1.0.0
        Module class: X.Org Video Driver
(II) NVIDIA dlloader X Driver  195.36.24  Thu Apr 22 09:34:29 PDT 2010
(II) NVIDIA Unified Driver for all Supported NVIDIA GPUs
(II) Primary Device is: PCI 01@00:00:0
(II) Loading sub module "fb"
(II) LoadModule: "fb"
(II) Loading /usr/lib/xorg/modules/libfb.so
(II) Module fb: vendor="X.Org Foundation"
        compiled for 1.7.6, module version = 1.0.0
        ABI class: X.Org ANSI C Emulation, version 0.4
(II) Loading sub module "wfb"
(II) LoadModule: "wfb"
(II) Loading /usr/lib/xorg/modules/libwfb.so
(II) Module wfb: vendor="X.Org Foundation"
        compiled for 1.7.6, module version = 1.0.0
        ABI class: X.Org ANSI C Emulation, version 0.4
(II) Loading sub module "ramdac"
(II) LoadModule: "ramdac"
(II) Module "ramdac" already built-in
(**) NVIDIA(0): Depth 24, (--) framebuffer bpp 32
(==) NVIDIA(0): RGB weight 888
(==) NVIDIA(0): Default visual is TrueColor
(==) NVIDIA(0): Using gamma correction (1.0, 1.0, 1.0)
(**) NVIDIA(0): Option "TwinView" "1"
(**) NVIDIA(0): Option "MetaModes" "DFP-0: nvidia-auto-select +0+0, DFP-1: nvidia-auto-select +1280+0"
(**) NVIDIA(0): Option "TwinViewXineramaInfoOrder" "DFP-1"
(**) Sep 28 18:46:44 NVIDIA(0): Enabling RENDER acceleration
(II) Sep 28 18:46:44 NVIDIA(0): Support for GLX with the Damage and Composite X extensions is
(II) Sep 28 18:46:44 NVIDIA(0):     enabled.
(II) Sep 28 18:46:46 NVIDIA(0): NVIDIA GPU GeForce GTX 285 (GT200) at PCI:1:0:0 (GPU-0)
(--) Sep 28 18:46:46 NVIDIA(0): Memory: 1048576 kBytes
(--) Sep 28 18:46:46 NVIDIA(0): VideoBIOS: 62.00.45.00.03
(II) Sep 28 18:46:46 NVIDIA(0): Detected PCI Express Link width: 8X
(--) Sep 28 18:46:46 NVIDIA(0): Interlaced video modes are supported on this GPU
(--) Sep 28 18:46:46 NVIDIA(0): Connected display device(s) on GeForce GTX 285 at PCI:1:0:0:
(--) Sep 28 18:46:46 NVIDIA(0):     DELL 1907FP (DFP-0)
(--) Sep 28 18:46:46 NVIDIA(0):     DELL 1907FP (DFP-1)
(--) Sep 28 18:46:46 NVIDIA(0): DELL 1907FP (DFP-0): 330.0 MHz maximum pixel clock
(--) Sep 28 18:46:46 NVIDIA(0): DELL 1907FP (DFP-0): Internal Dual Link TMDS
(--) Sep 28 18:46:46 NVIDIA(0): DELL 1907FP (DFP-1): 330.0 MHz maximum pixel clock
(--) Sep 28 18:46:46 NVIDIA(0): DELL 1907FP (DFP-1): Internal Dual Link TMDS
(**) Sep 28 18:46:46 NVIDIA(0): TwinView enabled
(II) Sep 28 18:46:46 NVIDIA(0): Display Devices found referenced in MetaMode: DFP-0, DFP-1
(II) Sep 28 18:46:46 NVIDIA(0): Assigned Display Devices: DFP-0, DFP-1
(II) Sep 28 18:46:46 NVIDIA(0): Validated modes:
(II) Sep 28 18:46:46 NVIDIA(0):
(II) Sep 28 18:46:46 NVIDIA(0):     "DFP-0:nvidia-auto-select+0+0,DFP-1:nvidia-auto-select+1280+0"
(II) Sep 28 18:46:46 NVIDIA(0): Virtual screen size determined to be 2560 x 1024
(--) Sep 28 18:46:46 NVIDIA(0): DPI set to (85, 86); computed from "UseEdidDpi" X config
(--) Sep 28 18:46:46 NVIDIA(0):     option
(==) Sep 28 18:46:46 NVIDIA(0): Enabling 32-bit ARGB GLX visuals.
(--) Depth 24 pixmap format is 32 bpp
(II) Sep 28 18:46:46 NVIDIA: Using 768.00 MB of virtual memory for indirect memory access.
(II) Sep 28 18:46:46 NVIDIA(0): Initialized GPU GART.
(II) Sep 28 18:46:46 NVIDIA(0): Setting mode
(II) Sep 28 18:46:46 NVIDIA(0):     "DFP-0:nvidia-auto-select+0+0,DFP-1:nvidia-auto-select+1280+0"
(II) Loading extension NV-GLX
(II) Sep 28 18:46:46 NVIDIA(0): Initialized OpenGL Acceleration
(==) NVIDIA(0): Disabling shared memory pixmaps
(II) Sep 28 18:46:46 NVIDIA(0): Initialized X Rendering Acceleration
(==) NVIDIA(0): Backing store disabled
(==) NVIDIA(0): Silken mouse enabled
(**) NVIDIA(0): DPMS enabled
(II) Loading extension NV-CONTROL
(II) Loading extension XINERAMA
(==) RandR enabled
(II) Initializing built-in extension Generic Event Extension
(II) Initializing built-in extension SHAPE
(II) Initializing built-in extension MIT-SHM
(II) Initializing built-in extension XInputExtension
(II) Initializing built-in extension XTEST
(II) Initializing built-in extension BIG-REQUESTS
(II) Initializing built-in extension SYNC
(II) Initializing built-in extension XKEYBOARD
(II) Initializing built-in extension XC-MISC
(II) Initializing built-in extension SECURITY
(II) Initializing built-in extension XINERAMA
(II) Initializing built-in extension XFIXES
(II) Initializing built-in extension RENDER
(II) Initializing built-in extension RANDR
(II) Initializing built-in extension COMPOSITE
(II) Initializing built-in extension DAMAGE
(II) Initializing extension GLX
(II) XKB: reuse xkmfile /var/lib/xkb/server-B20D7FC79C7F597315E3E501AEF10E0D866E8E92.xkm
(II) config/udev: Adding input device Power Button (/dev/input/event1)
(**) Power Button: Applying InputClass "evdev keyboard catchall"
(II) LoadModule: "evdev"
(II) Loading /usr/lib/xorg/modules/input/evdev_drv.so
(II) Module evdev: vendor="X.Org Foundation"
        compiled for 1.7.6, module version = 2.3.2
        Module class: X.Org XInput Driver
        ABI class: X.Org XInput driver, version 7.0
(**) Power Button: always reports core events
(**) Power Button: Device: "/dev/input/event1"
(II) Power Button: Found keys
(II) Power Button: Configuring as keyboard
(II) XINPUT: Adding extended input device "Power Button" (type: KEYBOARD)
(**) Option "xkb_rules" "evdev"
(**) Option "xkb_model" "pc105"
(**) Option "xkb_layout" "us"
(**) Option "xkb_variant" "euro"
(**) Option "xkb_options" "lv3:ralt_switch"
(II) XKB: reuse xkmfile /var/lib/xkb/server-8607B2682176CB8E0C80E68C2B34B5746457B906.xkm
(II) config/udev: Adding input device Power Button (/dev/input/event0)
(**) Power Button: Applying InputClass "evdev keyboard catchall"
(**) Power Button: always reports core events
(**) Power Button: Device: "/dev/input/event0"
(II) Power Button: Found keys
(II) Power Button: Configuring as keyboard
(II) XINPUT: Adding extended input device "Power Button" (type: KEYBOARD)
(**) Option "xkb_rules" "evdev"
(**) Option "xkb_model" "pc105"
(**) Option "xkb_layout" "us"
(**) Option "xkb_variant" "euro"
(**) Option "xkb_options" "lv3:ralt_switch"
(II) config/udev: Adding input device Logitech Optical USB Mouse (/dev/input/event3)
(**) Logitech Optical USB Mouse: Applying InputClass "evdev pointer catchall"
(**) Logitech Optical USB Mouse: always reports core events
(**) Logitech Optical USB Mouse: Device: "/dev/input/event3"
(II) Logitech Optical USB Mouse: Found 3 mouse buttons
(II) Logitech Optical USB Mouse: Found scroll wheel(s)
(II) Logitech Optical USB Mouse: Found relative axes
(II) Logitech Optical USB Mouse: Found x and y relative axes
(II) Logitech Optical USB Mouse: Configuring as mouse
(**) Logitech Optical USB Mouse: YAxisMapping: buttons 4 and 5
(**) Logitech Optical USB Mouse: EmulateWheelButton: 4, EmulateWheelInertia: 10, EmulateWheelTimeout: 200
(II) XINPUT: Adding extended input device "Logitech Optical USB Mouse" (type: MOUSE)
(II) Logitech Optical USB Mouse: initialized for relative axes.
(II) config/udev: Adding input device Logitech Optical USB Mouse (/dev/input/mouse1)
(II) No input driver/identifier specified (ignoring)
(II) config/udev: Adding input device Dell Dell USB Keyboard Hub (/dev/input/event4)
(**) Dell Dell USB Keyboard Hub: Applying InputClass "evdev keyboard catchall"
(**) Dell Dell USB Keyboard Hub: always reports core events
(**) Dell Dell USB Keyboard Hub: Device: "/dev/input/event4"
(II) Dell Dell USB Keyboard Hub: Found keys
(II) Dell Dell USB Keyboard Hub: Configuring as keyboard
(II) XINPUT: Adding extended input device "Dell Dell USB Keyboard Hub" (type: KEYBOARD)
(**) Option "xkb_rules" "evdev"
(**) Option "xkb_model" "pc105"
(**) Option "xkb_layout" "us"
(**) Option "xkb_variant" "euro"
(**) Option "xkb_options" "lv3:ralt_switch"
(II) config/udev: Adding input device Dell Dell USB Keyboard Hub (/dev/input/event5)
(**) Dell Dell USB Keyboard Hub: Applying InputClass "evdev keyboard catchall"
(**) Dell Dell USB Keyboard Hub: always reports core events
(**) Dell Dell USB Keyboard Hub: Device: "/dev/input/event5"
(II) Dell Dell USB Keyboard Hub: Found absolute axes
(II) Dell Dell USB Keyboard Hub: Found keys
(II) Dell Dell USB Keyboard Hub: Configuring as mouse
(II) Dell Dell USB Keyboard Hub: Configuring as keyboard
(II) XINPUT: Adding extended input device "Dell Dell USB Keyboard Hub" (type: KEYBOARD)
(**) Option "xkb_rules" "evdev"
(**) Option "xkb_model" "pc105"
(**) Option "xkb_layout" "us"
(**) Option "xkb_variant" "euro"
(**) Option "xkb_options" "lv3:ralt_switch"
(II) Dell Dell USB Keyboard Hub: initialized for absolute axes.
(II) config/udev: Adding input device Macintosh mouse button emulation (/dev/input/event2)
(**) Macintosh mouse button emulation: Applying InputClass "evdev pointer catchall"
(**) Macintosh mouse button emulation: always reports core events
(**) Macintosh mouse button emulation: Device: "/dev/input/event2"
(II) Macintosh mouse button emulation: Found 3 mouse buttons
(II) Macintosh mouse button emulation: Found relative axes
(II) Macintosh mouse button emulation: Found x and y relative axes
(II) Macintosh mouse button emulation: Configuring as mouse
(**) Macintosh mouse button emulation: YAxisMapping: buttons 4 and 5
(**) Macintosh mouse button emulation: EmulateWheelButton: 4, EmulateWheelInertia: 10, EmulateWheelTimeout: 200
(II) XINPUT: Adding extended input device "Macintosh mouse button emulation" (type: MOUSE)
(II) Macintosh mouse button emulation: initialized for relative axes.
(II) config/udev: Adding input device Macintosh mouse button emulation (/dev/input/mouse0)
(II) No input driver/identifier specified (ignoring)
[mi] EQ overflowing. The server is probably stuck in an infinite loop.

Backtrace:
0: /usr/bin/X (xorg_backtrace+0x3b) [0x80e938b]
1: /usr/bin/X (mieqEnqueue+0x1ab) [0x80e8b7b]
2: /usr/bin/X (xf86PostMotionEventP+0xd2) [0x80c2d12]
3: /usr/lib/xorg/modules/input/evdev_drv.so (0x407000+0x48a1) [0x40b8a1]
4: /usr/lib/xorg/modules/input/evdev_drv.so (0x407000+0x4b96) [0x40bb96]
5: /usr/bin/X (0x8048000+0x6d5cf) [0x80b55cf]
6: /usr/bin/X (0x8048000+0x122754) [0x816a754]
7: (vdso) (__kernel_sigreturn+0x0) [0x271400]
(WW) Sep 29 09:18:24 NVIDIA(0): WAIT (0, 6, 0x8000, 0x0000ef9c, 0x0000ef9c)
(WW) Sep 29 09:18:27 NVIDIA(0): WAIT (2, 6, 0x8000, 0x0000f604, 0x00000390)
(WW) Sep 29 09:18:32 NVIDIA(0): WAIT (0, 6, 0x8000, 0x00000390, 0x00000390)
(WW) Sep 29 09:18:36 NVIDIA(0): WAIT (2, 6, 0x8000, 0x0000f26c, 0x0000fde4)
(WW) Sep 29 09:18:48 NVIDIA(0): WAIT (2, 6, 0x8000, 0x00006180, 0x00006d0c)
(WW) Sep 29 09:18:55 NVIDIA(0): WAIT (1, 6, 0x8000, 0x00006180, 0x00006d0c)
(WW) Sep 29 09:19:01 NVIDIA(0): WAIT (2, 6, 0x8000, 0x00003284, 0x00003e1c)
(WW) Sep 29 09:19:08 NVIDIA(0): WAIT (1, 6, 0x8000, 0x00003284, 0x00003e1c)
Comment 31 BP 2011-02-28 18:41:36 UTC
I also get this bug whenever I use graphical apps. It seems not as bad with the newer nvidia driver, 270.29, but it is still happening. I to have a logitech usb wireless keyboard/mouse. The waits are about ten second pauses in the apps i use until finally a complete lock. SSH still works though.

[   137.585] (II) NVIDIA(0): Setting mode "1920x1080_60i_0"
[  1220.299] [mi] EQ overflowing. The server is probably stuck in an infinite loop.
[  1220.299] 
Backtrace:
[  1220.299] 0: /usr/bin/X (xorg_backtrace+0x3b) [0x80ef31b]
[  1220.299] 1: /usr/bin/X (mieqEnqueue+0x1ab) [0x80ecb5b]
[  1220.299] 2: /usr/bin/X (xf86PostMotionEventP+0xd2) [0x80bd662]
[  1220.299] 3: /usr/lib/xorg/modules/input/evdev_drv.so (0xb4e78000+0x4911) [0xb4e7c911]
[  1220.299] 4: /usr/lib/xorg/modules/input/evdev_drv.so (0xb4e78000+0x4a06) [0xb4e7ca06]
[  1220.299] 5: /usr/lib/xorg/modules/input/evdev_drv.so (0xb4e78000+0x5246) [0xb4e7d246]
[  1220.299] 6: /usr/bin/X (0x8048000+0x62e7f) [0x80aae7f]
[  1220.299] 7: /usr/bin/X (0x8048000+0x121b4e) [0x8169b4e]
[  1220.299] 8: (vdso) (__kernel_sigreturn+0x0) [0xb78c0400]
[  1221.160] (WW) NVIDIA(0): WAIT (2, 6, 0x8000, 0x0000c30c, 0x0000cc04)
[  1222.909] (WW) NVIDIA(0): WAIT (0, 6, 0x0000, 0x0000cc04, 0x0000cc04)
[  1448.243] (WW) NVIDIA(0): WAIT (2, 6, 0x8000, 0x0000c30c, 0x0000cc04)
[  1452.591] (WW) NVIDIA(0): WAIT (0, 6, 0x0000, 0x0000cc04, 0x0000cc04)
[  2775.359] (WW) NVIDIA(0): WAIT (2, 6, 0x8000, 0x0000474c, 0x00005044)
[  2776.214] (WW) NVIDIA(0): WAIT (0, 6, 0x0000, 0x00005044, 0x00005044)
[  5993.403] (WW) NVIDIA(0): WAIT (2, 6, 0x8000, 0x00005eec, 0x000067e4)
[  5994.962] (WW) NVIDIA(0): WAIT (0, 6, 0x0000, 0x000067e4, 0x000067e4)
Comment 32 Artem S. Tashkinov 2011-04-25 15:45:08 UTC
This bug is 100% reproducible for me using NVIDIA binary drivers, Adobe Flash 10.2.x/10.3.x and  xorg-x11-server-Xorg-1.9.5-1.fc14.i686.

More here: http://www.nvnews.net/vbulletin/showthread.php?t=161664
Comment 33 Sean Budd 2011-05-15 18:00:59 UTC
(In reply to comment #32)
> This bug is 100% reproducible for me using NVIDIA binary drivers, Adobe Flash
> 10.2.x/10.3.x and  xorg-x11-server-Xorg-1.9.5-1.fc14.i686.
> 
> More here: http://www.nvnews.net/vbulletin/showthread.php?t=161664

I have been experiencing the same issue.I have found if I unplug the (logitech)Mouse the X server will begin responding shortly,but only if I don't type too many characters on the keyboard(which is obviously generating more events it cant deal with),however,the server is still not recovered properly,as if I plug the mouse back in it will work for a moment and then lock X again.Restarting X resolves it.
Comment 34 Ramon 2011-07-11 06:48:35 UTC
Any progress here? I have the same issues but only when I enable hardware acceleration in flash 10.3 under my x86_64 Ubuntu box using the option EnableLinuxHWVideoDecode=1 in /etc/adobe/mms.cfg 

I cannot reproduce it if this option is disabled.
Comment 35 Michael Kers 2011-07-11 22:47:13 UTC
I was having the same crashes on my notebook (IBM thinkpad T60, intel 945).

My crash looked really similar to those above, here is a snippet:

[426827.927] [mi] EQ overflowing. The server is probably stuck in an infinite loop.
[426827.927] 
Backtrace:
[426827.927] 0: /usr/bin/X (xorg_backtrace+0x3b) [0x80eab2b]

... Blah blah blah.

I got angry.  I got the symbols, fired up GDB remotely, attached to xorg and started using my computer waiting for a crash.  1.5 days later...  I was using firefox, and it hung.  Mouse could move, but no response to events.

Other machine, switch to GDB, Ctrl-C, (add some symbol files) and bt full gives the following (note, it didn't stop GDB due to exception or SIG*, it just entered an infinite loop, I had to break out of it).

I will leave the crashed Xorg as is for now if any one wants me to explore anything further via GDB.

(gdb) bt full
#0  sse2_composite_src_x888_8888 (imp=0x89f0bd0, op=PIXMAN_OP_SRC, src_image=0x8f5af00, 
    mask_image=0x0, dst_image=0x9076038, src_x=0, src_y=0, mask_x=0, mask_y=1096, dest_x=0, 
    dest_y=0, width=1936, height=<value optimized out>) at ../../pixman/pixman-sse2.c:3163
        dst_line = 0xb045a000
        dst = 0xb04588c0
        src_line = 0xabc5a000
        src = 0xabc588c0
        w = 1376
        dst_stride = <value optimized out>
        src_stride = <value optimized out>
#1  0x00b04e5f in pixman_image_composite32 (op=<value optimized out>, src=0x8f5af00, mask=0x0, 
    dest=0x9076038, src_x=0, src_y=0, mask_x=0, mask_y=1096, dest_x=0, dest_y=0, width=1936, 
    height=2174) at ../../pixman/pixman.c:839
        pbox = 0xbfc670cc
        n = 0
        src_format = PIXMAN_x8r8g8b8
        mask_format = 0
        dest_format = <value optimized out>
        src_flags = 3091199
        mask_flags = 8192
        dest_flags = <value optimized out>
        region = {extents = {x1 = 0, y1 = 0, x2 = 1936, y2 = 2174}, data = 0x0}
        extents = <value optimized out>
        src_bits = <value optimized out>
        src_dx = <value optimized out>
        src_dy = <value optimized out>
        mask_bits = <value optimized out>
        mask_dx = <value optimized out>
        mask_dy = <value optimized out>
        dest_bits = <value optimized out>
        dest_dx = <value optimized out>
        dest_dy = <value optimized out>
        need_workaround = 0
        imp = 0x89f0bd0
        func = 0xb24230 <sse2_composite_src_x888_8888>
#2  0x00b0519c in pixman_image_composite (op=PIXMAN_OP_SRC, src=0x8f5af00, mask=0x0, 
    dest=0x9076038, src_x=0, src_y=0, mask_x=0, mask_y=1096, dest_x=0, dest_y=0, width=1936, 
    height=2174) at ../../pixman/pixman.c:879
No locals.
#3  0x005a8d7e in fbComposite (op=1 '\001', pSrc=0x8f378e0, pMask=0x0, pDst=0x90663d8, xSrc=0, 
    ySrc=0, xMask=0, yMask=0, xDst=0, yDst=0, width=1936, height=2174) at ../../fb/fbpict.c:67
        src = <value optimized out>
        mask = 0x0
        dest = <value optimized out>
#4  0x0022ce5f in uxa_check_composite (op=1 '\001', pSrc=0x8f378e0, pMask=0x0, pDst=0x90663d8, 
    xSrc=0, ySrc=0, xMask=0, yMask=0, xDst=0, yDst=0, width=1936, height=2174)
    at ../../uxa/uxa-unaccel.c:371
        screen = <value optimized out>
        __FUNCTION__ = <error reading variable __FUNCTION__ (Cannot access memory at address 0x4454f)>
#5  0x002295d0 in uxa_composite (op=1 '\001', pSrc=0x8f378e0, pMask=0x0, pDst=0x90663d8, xSrc=0, 
    ySrc=0, xMask=0, yMask=0, xDst=0, yDst=0, width=1936, height=2174)
    at ../../uxa/uxa-render.c:1718
        uxa_screen = 0x1
        ret = <value optimized out>
        saveSrcRepeat = 256
        saveMaskRepeat = 0
        region = {extents = {x1 = 8192, y1 = 0, x2 = 7744, y2 = 0}, data = 0x81f7ff4}
        tx = 150930504
        ty = -131073
#6  0x08127d12 in damageComposite (op=1 '\001', pSrc=0x8f378e0, pMask=0x0, pDst=0x90663d8, xSrc=0, 
    ySrc=0, xMask=0, yMask=0, xDst=0, yDst=0, width=1936, height=2174)
    at ../../../miext/damage/damage.c:617
        pScreen = <value optimized out>
        ps = 0x89a99c8
        pScrPriv = 0x89a9d00
#7  0x0811c9ee in CompositePicture (op=<value optimized out>, pSrc=0x8f378e0, pMask=0x0, 
    pDst=0x90663d8, xSrc=0, ySrc=0, xMask=0, yMask=0, xDst=0, yDst=0, width=1936, height=2174)
    at ../../render/picture.c:1705
        ps = 0x89a99c8
#8  0x081204b9 in ProcRenderComposite (client=0x8e92220) at ../../render/render.c:728
        pSrc = 0x8f378e0
        pMask = 0x0
        pDst = 0x90663d8
        stuff = <value optimized out>
#9  0x0811d1b3 in ProcRenderDispatch (client=0x8e92220) at ../../render/render.c:2057
        stuff = <value optimized out>
#10 0x08070167 in Dispatch () at ../../dix/dispatch.c:431
        clientReady = 0x8d11ed0
        result = <value optimized out>
        client = 0x8e92220
        nready = 0
        icheck = 0x820a878
        start_tick = 87020
#11 0x0806281c in main (argc=8, argv=0xbfc67704, envp=0xbfc67728) at ../../dix/main.c:287
        i = <value optimized out>
        alwaysCheckForInput = {0, 1}







< continuation of my Xorg.0.log file> 

[426827.927] 1: /usr/bin/X (mieqEnqueue+0x1ab) [0x80e9d0b]
[426827.927] 2: /usr/bin/X (xf86PostMotionEventM+0xbf) [0x80c4b6f]
[426827.927] 3: /usr/lib/xorg/modules/input/evdev_drv.so (0xcb4000+0x368f) [0xcb768f]
[426827.927] 4: /usr/lib/xorg/modules/input/evdev_drv.so (0xcb4000+0x54e9) [0xcb94e9]
[426827.927] 5: /usr/lib/xorg/modules/input/evdev_drv.so (0xcb4000+0x5d4d) [0xcb9d4d]
[426827.927] 6: /usr/bin/X (0x8048000+0x6b41f) [0x80b341f]
[426827.927] 7: /usr/bin/X (0x8048000+0x12ddb6) [0x8175db6]
[426827.927] 8: (vdso) (__kernel_sigreturn+0x0) [0xe63400]
[426827.927] 9: /usr/lib/libpixman-1.so.0 (pixman_image_composite32+0x4bf) [0xc3ce5f]
[426827.927] 10: /usr/lib/libpixman-1.so.0 (pixman_image_composite+0x8c) [0xc3d19c]
[426827.928] 11: /usr/lib/xorg/modules/libfb.so (fbComposite+0x1fe) [0x1f8d7e]
[426827.928] 12: /usr/lib/xorg/modules/drivers/intel_drv.so (0x367000+0x2fe5f) [0x396e5f]
[426827.928] 13: /usr/lib/xorg/modules/drivers/intel_drv.so (0x367000+0x2c5d0) [0x3935d0]
[426827.928] 14: /usr/bin/X (0x8048000+0xdfd12) [0x8127d12]
[426827.928] 15: /usr/bin/X (CompositePicture+0x24e) [0x811c9ee]
[426827.928] 16: /usr/bin/X (0x8048000+0xd84b9) [0x81204b9]
[426827.928] 17: /usr/bin/X (0x8048000+0xd51b3) [0x811d1b3]
[426827.928] 18: /usr/bin/X (0x8048000+0x28167) [0x8070167]
[426827.928] 19: /usr/bin/X (0x8048000+0x1a81c) [0x806281c]
[426827.928] 20: /lib/i386-linux-gnu/libc.so.6 (__libc_start_main+0xe7) [0x21ce37]
[426827.928] 21: /usr/bin/X (0x8048000+0x1a411) [0x8062411]
Comment 36 Artem S. Tashkinov 2011-07-23 05:04:44 UTC
Adobe Flash player together with NVIDIA binary drivers can trigger this easily leading to temporary freezes or total system hang up

X.org log

[ 19730.864] [mi] EQ overflowing. The server is probably stuck in an infinite loop.
[ 19730.864]
Backtrace:
[ 19730.888] 0: /usr/bin/X (xorg_backtrace+0x3c) [0x80e8c6c]
[ 19730.888] 1: /usr/bin/X (mieqEnqueue+0x1c1) [0x80e8141]
[ 19730.888] 2: /usr/bin/X (xf86PostMotionEventM+0xbf) [0x80c47af]
[ 19730.888] 3: /usr/bin/X (xf86PostMotionEventP+0x68) [0x80c48f8]
[ 19730.888] 4: /usr/lib/xorg/modules/input/evdev_drv.so (0xb48c2000+0x2caf) [0xb48c4caf]
[ 19730.888] 5: /usr/lib/xorg/modules/input/evdev_drv.so (0xb48c2000+0x3d81) [0xb48c5d81]
[ 19730.888] 6: /usr/bin/X (0x8048000+0x69d00) [0x80b1d00]
[ 19730.888] 7: /usr/bin/X (0x8048000+0x122175) [0x816a175]
[ 19730.888] 8: (vdso) (__kernel_sigreturn+0x0) [0xb76ef400]
[ 19730.888] 9: (vdso) (__kernel_vsyscall+0x10) [0xb76ef424]
[ 19730.888] 10: /lib/libc.so.6 (__gettimeofday+0x16) [0xb7311ca6]
[ 19730.888] 11: /usr/lib/xorg/modules/drivers/nvidia_drv.so (0xb4e2c000+0x5c34d) [0xb4e8834d]
[ 19732.612] (WW) NVIDIA(0): WAIT (2, 6, 0x8000, 0x0000d088, 0x0000d098)
[ 19733.544] (WW) NVIDIA(0): WAIT (0, 6, 0x0000, 0x0000d098, 0x0000d098)
[ 19734.306] [mi] EQ overflowing. The server is probably stuck in an infinite loop.
[ 19734.306]
Backtrace:
[ 19734.306] 0: /usr/bin/X (xorg_backtrace+0x3c) [0x80e8c6c]
[ 19734.306] 1: /usr/bin/X (mieqEnqueue+0x1c1) [0x80e8141]
[ 19734.306] 2: /usr/bin/X (xf86PostMotionEventM+0xbf) [0x80c47af]
[ 19734.306] 3: /usr/bin/X (xf86PostMotionEventP+0x68) [0x80c48f8]
[ 19734.306] 4: /usr/lib/xorg/modules/input/evdev_drv.so (0xb48c2000+0x2caf) [0xb48c4caf]
[ 19734.306] 5: /usr/lib/xorg/modules/input/evdev_drv.so (0xb48c2000+0x3d81) [0xb48c5d81]
[ 19734.306] 6: /usr/bin/X (0x8048000+0x69d00) [0x80b1d00]
[ 19734.306] 7: /usr/bin/X (0x8048000+0x122175) [0x816a175]
[ 19734.306] 8: (vdso) (__kernel_sigreturn+0x0) [0xb76ef400]
[ 19734.306] 9: /usr/lib/xorg/modules/drivers/nvidia_drv.so (0xb4e2c000+0x5b792) [0xb4e87792]
[ 19739.478] [mi] EQ overflowing. The server is probably stuck in an infinite loop.
[ 19739.478]
Backtrace:
[ 19739.478] 0: /usr/bin/X (xorg_backtrace+0x3c) [0x80e8c6c]
[ 19739.478] 1: /usr/bin/X (mieqEnqueue+0x1c1) [0x80e8141]
[ 19739.478] 2: /usr/bin/X (xf86PostMotionEventM+0xbf) [0x80c47af]
[ 19739.478] 3: /usr/bin/X (xf86PostMotionEventP+0x68) [0x80c48f8]
[ 19739.478] 4: /usr/lib/xorg/modules/input/evdev_drv.so (0xb48c2000+0x2caf) [0xb48c4caf]
[ 19739.478] 5: /usr/lib/xorg/modules/input/evdev_drv.so (0xb48c2000+0x3d81) [0xb48c5d81]
[ 19739.478] 6: /usr/bin/X (0x8048000+0x69d00) [0x80b1d00]
[ 19739.478] 7: /usr/bin/X (0x8048000+0x122175) [0x816a175]
[ 19739.478] 8: (vdso) (__kernel_sigreturn+0x0) [0xb76ef400]
[ 19739.478] 9: /usr/lib/xorg/modules/drivers/nvidia_drv.so (0xb4e2c000+0x5b786) [0xb4e87786]

dmesg:

NVRM: Xid (0000:01:00): 13, 0001 00000000 00005097 0000194c 00000000 00000180
NVRM: Xid (0000:01:00): 8, Channel 00000001
NVRM: os_schedule: Attempted to yield the CPU while in atomic or interrupt context
NVRM: Xid (0000:01:00): 8, Channel 0000007e
NVRM: os_schedule: Attempted to yield the CPU while in atomic or interrupt context
NVRM: os_schedule: Attempted to yield the CPU while in atomic or interrupt context
NVRM: Xid (0000:01:00): 8, Channel 0000007e
NVRM: os_schedule: Attempted to yield the CPU while in atomic or interrupt context
NVRM: Xid (0000:01:00): 8, Channel 0000007e
NVRM: os_schedule: Attempted to yield the CPU while in atomic or interrupt context
Comment 37 Ivan Giuliani 2011-08-16 15:08:32 UTC
I've been hit by this bug too: frozen screen, but the mouse could move. Even the keyboard seemed to be frozen. To me, the freeze has always occurred when starting reproduction of some flash embedded videos (i.e: youtube videos). As a side note I enabled the hardware acceleration for the flash player. All happened both after hibernation and after a clean start.

During the freeze, I have been able to partially "recover" the system by logging in through ssh from another computer and manually killing chrome (I can confirm that the bug happens on firefox too so flash it's the likely cause). After killing the flash player the system *seemed* responsive again but it has always crashed definitely soon afterwards. The only clean way to restore the status is a complete reboot.

I'm using ubuntu 11.04, Xorg 7.6 (64bit Intel i3 CPU, NVIDIA GT 320).
Follows the relevant portions of Xorg.log (the following excerpt is repeated, identically, at least ten times in the log file):

[ 23460.518] (WW) NVIDIA(0): WAIT (1, 6, 0x8000, 0x00004cac, 0x0000e88c)
[ 23509.083] [mi] EQ overflowing. The server is probably stuck in an infinite loop.
[ 23509.083] 
Backtrace:
[ 23509.083] 0: /usr/bin/X (xorg_backtrace+0x26) [0x4a2656]
[ 23509.083] 1: /usr/bin/X (mieqEnqueue+0x1f4) [0x4a1914]
[ 23509.083] 2: /usr/bin/X (xf86PostKeyEventM+0xa7) [0x47dfc7]
[ 23509.083] 3: /usr/bin/X (xf86PostKeyboardEvent+0x4b) [0x47e26b]
[ 23509.083] 4: /usr/lib/xorg/modules/input/evdev_drv.so (0x7f472d552000+0x6034) [0x7f472d558034]
[ 23509.083] 5: /usr/lib/xorg/modules/input/evdev_drv.so (0x7f472d552000+0x668d) [0x7f472d55868d]
[ 23509.083] 6: /usr/bin/X (0x400000+0x6c687) [0x46c687]
[ 23509.083] 7: /usr/bin/X (0x400000+0x124c1e) [0x524c1e]
[ 23509.083] 8: /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f4734312000+0xfc60) [0x7f4734321c60]
[ 23509.083] 9: /usr/lib/xorg/extra-modules/nvidia_drv.so (0x7f472ea3f000+0x768dd) [0x7f472eab58dd]
[ 23509.083] 10: /usr/lib/xorg/extra-modules/nvidia_drv.so (0x7f472ea3f000+0x78520) [0x7f472eab7520]
[ 23509.083] 11: /usr/lib/xorg/extra-modules/nvidia_drv.so (0x7f472ea3f000+0xdb315) [0x7f472eb1a315]
[ 23509.083] 12: /usr/lib/xorg/extra-modules/nvidia_drv.so (0x7f472ea3f000+0xdefc3) [0x7f472eb1dfc3]
[ 23509.083] 13: /usr/lib/xorg/extra-modules/nvidia_drv.so (0x7f472ea3f000+0x60f9d) [0x7f472ea9ff9d]
[ 23509.083] 14: /usr/bin/X (0x400000+0x145351) [0x545351]
[ 23509.083] 15: /usr/bin/X (0x400000+0x143db8) [0x543db8]
[ 23509.083] 16: /usr/bin/X (miPointerUpdateSprite+0x252) [0x45b6d2]
[ 23509.083] 17: /usr/bin/X (0x400000+0x5b92f) [0x45b92f]
[ 23509.083] 18: /usr/bin/X (0x400000+0xa86db) [0x4a86db]
[ 23509.083] 19: /usr/bin/X (0x400000+0x16eb77) [0x56eb77]
[ 23509.083] 20: /usr/bin/X (0x400000+0x35ba9) [0x435ba9]
[ 23509.083] 21: /usr/bin/X (0x400000+0x3909f) [0x43909f]
[ 23509.083] 22: /usr/bin/X (0x400000+0xe65bb) [0x4e65bb]
[ 23509.083] 23: /usr/bin/X (0x400000+0x108650) [0x508650]
[ 23509.083] 24: /usr/bin/X (mieqProcessDeviceEvent+0x30e) [0x4a1e7e]
[ 23509.083] 25: /usr/bin/X (mieqProcessInputEvents+0xc4) [0x4a1f64]
[ 23509.083] 26: /usr/bin/X (ProcessInputEvents+0x9) [0x46c709]
[ 23509.084] 27: /usr/bin/X (0x400000+0x2e0e5) [0x42e0e5]
[ 23509.084] 28: /usr/bin/X (0x400000+0x21a7e) [0x421a7e]
[ 23509.084] 29: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xff) [0x7f473325beff]
[ 23509.084] 30: /usr/bin/X (0x400000+0x21629) [0x421629]
[ 23543.368] (WW) NVIDIA(0): WAIT (2, 6, 0x8000, 0x00008a0c, 0x0000cd20)
[ 23545.363] (WW) NVIDIA(0): WAIT (0, 6, 0x8000, 0x0000cd20, 0x0000cd20)
Comment 38 Daniel Stone 2011-08-17 04:42:49 UTC
On Tue, Aug 16, 2011 at 03:08:35PM -0700, bugzilla-daemon@freedesktop.org wrote:
> I've been hit by this bug too: frozen screen, but the mouse could move. Even
> the keyboard seemed to be frozen. To me, the freeze has always occurred when
> starting reproduction of some flash embedded videos (i.e: youtube videos). As a
> side note I enabled the hardware acceleration for the flash player. All
> happened both after hibernation and after a clean start.

This is a bug in the NVIDIA driver: please contact them to work through
it.
Comment 39 Ujjwal Dasgupta 2011-09-24 04:10:26 UTC
If I understand this correctly, then even if the size of the EQ buffer is insufficient, that should be no reason for the xserver to lock up, as the overflowing I/O events are simply dropped. However, some users are reporting that the lock-up issue goes away or reduces by increasing the QUEUE_SIZE of the buffer. Does that indicate that the xserver might be stuck somewhere waiting for an I/O event that doesn't reach it?
Comment 40 Daniel Stone 2011-09-24 08:22:49 UTC
On 24 September 2011 11:10,  <bugzilla-daemon@freedesktop.org> wrote:
> If I understand this correctly, then even if the size of the EQ buffer is
> insufficient, that should be no reason for the xserver to lock up, as the
> overflowing I/O events are simply dropped. However, some users are reporting
> that the lock-up issue goes away or reduces by increasing the QUEUE_SIZE of the
> buffer. Does that indicate that the xserver might be stuck somewhere waiting
> for an I/O event that doesn't reach it?

It depends what you mean by 'lock-up'.  If you mean that the server is
stuck in an infinite loop: right, that should never happen.  If you
mean that the desktop is locked up, yes, that's entirely possible: we
could miss a button or key release event and leave a grab hanging
somewhere.

I think there's a definite argument for increasing the queue size
quite dramatically on current servers.  If someone's _really_ keen, it
would be great to both make sure we retain all button release events
at all costs, and compress motion so all consecutive motion events get
squashed into one single event, but ensure that we never change the
position of button presses (e.g. if you have motion1 - motion2 -
buttonpress1 - motion3 - motion4 - motion5 - buttonrelease1 - motion6
- buttonpress2 - motion7 - motion8 - buttonrelease2; the result would
be motion1+2 - buttonpress1 - motion3+4+5 - buttonrelease1 - motion7+8
- buttonrelease2).

A patch like that would be fantastic if someone was interested! But in
the meantime, I think we should definitely just bump the default queue
size.
Comment 41 Ujjwal Dasgupta 2011-09-24 09:11:27 UTC
> It depends what you mean by 'lock-up'.  If you mean that the server is
> stuck in an infinite loop: right, that should never happen.  If you
> mean that the desktop is locked up, yes, that's entirely possible: we
> could miss a button or key release event and leave a grab hanging
> somewhere.

Thanks for the explanation. So a missed I/O event could indeed prove fatal to the x-server. In that case, would it be better to implement an event queue of dynamic size which could be increased when required? Or would that lead to situations where the queue keeps incrementing indefinitely, and the system runs out of memory?
Comment 42 Daniel Stone 2011-09-24 09:25:17 UTC
--- Comment #41 from Ujjwal Dasgupta <ujjwaldasgupta@gmail.com>
2011-09-24 09:11:27 PDT ---
> Thanks for the explanation. So a missed I/O event could indeed prove fatal to
> the x-server.

Not to the server per se, but definitely to the running environment, yes.

> In that case, would it be better to implement an event queue of
> dynamic size which could be increased when required? Or would that lead to
> situations where the queue keeps incrementing indefinitely, and the system runs
> out of memory?

The problem with this -- and the reason it's statically allocated in
the first place -- is that we cannot call malloc() or realloc() from a
signal handler (UNIX signals suck).  So the ultimate solution to this
is to thread input handling, basically.
Comment 43 Jeremy Huddleston 2011-10-15 14:01:40 UTC
This bug got hijacked.  It is full of so much noise about people claiming 
reopen, dupe, etc that it is 100% completely useless for tracking anything.

1) INVALID: mieq overflowing is a symptom, NOT a cause.
2) WONTFIX: The original issue reported seems to be because of DGA being crap.  
That is true and won't be fixed until it is purged.  A workaround exists for 
the given case, and I suggest distros use that workaround in their launch 
scripts:

export SDL_VIDEO_X11_DGAMOUSE=0

3) NOTOURBUG: libsdl should be updated to not use DGA

Re: Increasing the queue size, I agree that since it resolves the symptom in 
many cases, we should bump it to 4K or make it adaptive.  I will make a new bug 
for that.

Closing this report.