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.
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?
Created attachment 16048 [details] Xorg.0.log after resume
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.
(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.
(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.
(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?
(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.
> 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. >
(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.
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
Does setting the environment variable SDL_VIDEO_X11_DGAMOUSE=0 for running the affected games work around the problem?
(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.
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
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
*** Bug 18444 has been marked as a duplicate of this bug. ***
*** Bug 18631 has been marked as a duplicate of this bug. ***
It seems that this has spread outside of git Xserver...
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.
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 :)
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.
(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.
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.
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
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).
(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.
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.
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)
*** Bug 25166 has been marked as a duplicate of this bug. ***
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]
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)
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)
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
(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.
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.
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]
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
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)
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.
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?
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.
> 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 #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.
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.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.