Ubuntu

Confusing error message printed when X locks up. Needs clarification.

Reported by Jonathan Anderson on 2008-08-20
66
This bug affects 6 people
Affects Status Importance Assigned to Milestone
nvidia-graphics-drivers-177 (Ubuntu)
Undecided
Unassigned
xorg-server (Ubuntu)
Wishlist
Unassigned

Bug Description

[Problem]
X can lockup for a wide variety of reasons, and often when it does so it prints an esoteric, confusing error message. This can mislead users into thinking they have identical bugs, when they don't but are just seeing the same error message.

[Original Report]
With recent X packages, there is some level Multiple Input support, I believe. This seems to cause problems, as sometimes (for no apparent reason) X locks up and I see the following in my Xorg.0.log:

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

etc. etc. ad nauseum

Fabien Tassin (fta) wrote :

I have the same symptoms with the new nvidia 177.70 driver when I move a mplayer window (using xv as vo) slightly outside of the screen.
100% reproducible.

nvidia-glx-177 177.70-0ubuntu1
xserver-xorg-core 2:1.4.99.906-2ubuntu2
linux-image-2.6.27-2-generic 2.6.27-2.3
mplayer-nogui 2:1.0~rc2-0ubuntu13

Changed in xorg-server:
status: New → Confirmed
Fabien Tassin (fta) wrote :

Xorg also freeze when leaving fullscreen mode from mplayer, but this time without any logs (hence not those [mi]).
This makes the desktop unusable for video.

Alberto Milone (albertomilone) wrote :

Fabien: can you reproduce the problem if you set the driver to "nv" in the Device section of your xorg.conf and restart the xserver?

Fabien Tassin (fta) wrote :

I will try... next time I'm willing to restart X (I always have ~50 windows so i hate reboots/restarts).

btw, to narrow it down a little bit, it was fine with nvidia 177.68, xorg 2:1.4.99.906-1ubuntu4 and kernel 2.6.26-5-generic.

Fabien Tassin (fta) wrote :

It is not an nvidia problem after. Something changed my xorg.conf from nvidia to nv and I started to feel the effects only after the next reboot, which as I said before, I try to delay as much as possible.
Sorry for the confusion..

Marking invalid for nvidia-graphics-drivers-177.

Changed in nvidia-graphics-drivers-177:
status: New → Invalid
David Tomaschik (matir) wrote :

I am seeing the same behavior with intel graphics. It seems to occur after ~10-15 minutes of idle time, perhaps brought on by gnome-screensaver starting? (Testing the screensaver does NOT cause the lockup)

This makes it impossible for me to leave my laptop alone for any reasonable amount of time without another machine to connect to it via ssh.

dunDer (dunder) wrote :

Same problem when starting Counter Strike in Wine. After few minutes:

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

X hangs - only by holding power button for few seconds I'm able to shutdown (init 0). Nothing else works.

Olivier (olivier-lacroix) wrote :

Hi !

I have the exact same kind of message. I have an ATI card. The issue happens ONLY when desktops effects are turned on in kwin. For me, the lockup seems to appear at random times.

Olivier (olivier-lacroix) wrote :

I don't think the issue is driver related. The errors messages come from http://cgit.freedesktop.org/xorg/xserver/tree/mi/mieq.c

I'll try to get a backtrace. But it won't come today or tomorrow. So if you can do it, please proceed.

David Tomaschik (matir) wrote :

I believe this may be a dupe of bug #262605. Can anyone else seeing this behavior attempt to strace their X.org and see if the same behavior is seen as in that bug?

Not going to mark as dupe unless some others confirm same behavior, might just be my system.

Timo Aaltonen (tjaalton) wrote :

those messages are only the consequence of the lockup, not the reason. The GPU is locked for whatever the reason.

Changed in xorg-server:
status: Confirmed → Invalid
Changed in nvidia-graphics-drivers-177:
status: Invalid → New
David Tomaschik (matir) wrote :

I don't think that this issue is confined to nvidia graphics as you have marked it. Olivier has said it occurs on ATI and I am having the problem on Intel. If it is, in fact, related to bug #262605, then I suspect the bug is in the DRM/DRI (not sure which terminology is proper her) infrastructure, possibly in-kernel, or the X interface to it. An ioctl is being called repeatedly and being interrupted. (-EINTR).

Timo Aaltonen (tjaalton) wrote :

fair enough. Please provide proper backtraces then.

the other bug is not related IMO, and is intel specific.

Changed in xorg-server:
status: Invalid → Incomplete
Changed in nvidia-graphics-drivers-177:
status: New → Invalid
David Tomaschik (matir) wrote :

Can you suggest a way to get a proper backtrace? I've tried the steps suggested in the wiki, but despite having xserver-xorg-core-dbg, xserver-xorg-video-intel-dbg, and libgl1-mesa-dri-dbg installed, gdb cannot seem to resolve addresses into symbolic names. Do I need to point to the debug libraries specifically somehow?

I have had the error messages mentioned above in some of my X logs after lockups, but I also have the strace and exact behavior of the other bug. Additionally, disabling compiz (as mentioned in the other bug) has prevented EITHER condition from recurring. Perhaps I should follow up only with the other bug?

(Though, if I could get a backtrace, it might help clarify and would certainly help the other bug report.)

Rocco (rocco) wrote :

Same problem in kde4.1.1, nvidia-177. Desktop effects on/off doesn't matter.

X always hangs just after logging in to kde4, random lockups occurs when using X.

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

Many of these in X.org.log.

The look is released after about 30 seconds, and then one can use X again, until next lockup.

This problem started when installing nvidia 177.70, but doesn't look to be unique to nvidia.

Martin Nowack (martin-nowack) wrote :

I've got this problem too, ati with radeon driver and kde 4.1.1.

I remembered the following mail from Dave Airlie who works on the DRM stuff of the kernel:
http://marc.info/?l=dri-devel&m=121956233318894&w=2

And maybe it is the following commit which would help us:
http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commit;h=e5b4f19417b75a2d7c1e36934f60a3e836c4337e

Gryffus (gryffus) wrote :
Download full text (30.0 KiB)

I am experiencing same problem on openSUSE 11.0 x86-64 with Factory KDE4.1.2 and nVidia 177.67 beta driver (also happens with stable driver)...

I can easily reproduce it when i use "Folder view" plasmoid... When i click on a file within folder view or when i try to select multiple files... sometimes even when only hovering over the files...

Other opengl apps work just fine... Warcraft 3, Quake4, Quake 3, Call Of Duty 2...

X.Org X Server 1.5.1
Release Date: 23 September 2008
X Protocol Version 11, Revision 0
Build Operating System: openSUSE SUSE LINUX
Current Operating System: Linux saily 2.6.25.16-0.1-default #1 SMP 2008-08-21 00:34:25 +0200 x86_64
Build Date: 07 October 2008 05:36:15PM

        Before reporting problems, check http://wiki.x.org
        to make sure that you have the latest version.
Module Loader present
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: Thu Oct 9 06:57:03 2008
(==) Using config file: "/etc/X11/xorg.conf"
(==) ServerLayout "Layout[all]"
(**) |-->Screen "Screen[0]" (0)
(**) | |-->Monitor "Monitor[0]"
(**) | |-->Device "Device[0]"
(**) |-->Input Device "Keyboard[0]"
(**) |-->Input Device "Mouse[1]"
(**) |-->Input Device "Mouse[3]"
(**) Option "ZapWarning" "on"
(**) Option "AllowMouseOpenFail" "on"
(**) Option "Xinerama" "off"
(==) Automatically adding devices
(==) Automatically enabling devices
(WW) The directory "/usr/share/fonts/local" does not exist.
        Entry deleted from font path.
(WW) The directory "/usr/share/fonts/PEX" does not exist.
        Entry deleted from font path. ...

praveer01 (praveer12) wrote :

Even I have the same problem at my end, the installation here is Fedora 9 sulphur,

$ /sbin/lspci | grep VGA
01:00.0 VGA compatible controller: nVidia Corporation Quadro NVS 290 (rev a1)

driver installed for nvidia is nvidia-kmod-173.14.12-5.lvn9.src.rpm from livna repository,

Uniquely it happens only when I login into KDE4 and not in gnome, and shows all same symptoms as Rocco mentioned,

the lockup happens randomly ranging from 1/2 a minute to 5 minutes, and the X locks up for a while after which the lock is released and then lock can occur randomly again.

I noticed the same error messages in /var/log/Xorg.0.log
...................
[mi] EQ overflowing. The server is probably stuck in an infinite loop.
[mi] mieqEnequeue: out-of-order valuator event; dropping.
[mi] EQ overflowing. The server is probably stuck in an infinite loop.
[mi] mieqEnequeue: out-of-order valuator event; dropping.
...................

Strangely, X doesnt lock up randomly when I use gnome rather than kde4, I tried disabling composite in xorg.conf, but X in kde4 still locks up randomly.

Kamalakar Agashe (kagashe) wrote :

I installed Intrepid RC. My graphic card:
$ lspci | grep VGA
00:02.0 VGA compatible controller: Intel Corporation 82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device (rev 03)

Live CD did not work except in Safe graphics mode. I installed on hard disc and working fine with vesa. I changed the driver to intel and I could get to GDM login screen. After login there is a lock up. Keyboard did not work and I had to press reset button of the PC to reboot.

Now I am logged into Hardy installed on another partition and could read the following in Xorg.0.log:
[mi] EQ overflowing. The server is probably stuck in an infinite loop.

After searching I found this bug.

I am attaching Xorg.0.log

Kamalakar Agashe (kagashe) wrote :

I thought that this could be a bug related to Gnome.

I added openbox and changed to openbox session on GDM using intel driver. I could login to openbox without any problem.

Kamalakar Agashe (kagashe) wrote :

I removed compiz and compiz-core and could login to gnome, therefore, this is a bug related to compiz.

Gareth Bult (gareth-encryptec) wrote :

Ok, I'm having what sounds like the same problem - I've used synaptic to remove compiz (completely) and am still seeing the same issue. I can't pin it down as nothing appears in the logs when it dies, however it does seem to be sound related. (i.e. if I play music, I lock up pretty quickly)

System: Althon Duo, 4G RAM, 500Gb SATA, nVidia Quattro
Machine was previously stable on Hardy.

I've tried amd64,x86, same on both architectures - no difference, both lock up.
I've tried Nvidia 173 and 177 drivers, no difference there.
I do run VMWARE on the machine (server), have just disabled that to see if it makes a difference.

What I have noticed is that the mouse locks up, however ( I didn't notice this at first ) the keyboard is still active, so you can Alt-Tab into the window you want to close things down .. no end of killing processed however will make the mouse do anything useful apart from move.

It would be useful to define the term "lock" .. for example do you mean a complete freeze? In which case I have a different problem as the mouse still moves, it just won't do anything. I Can for example ctrl-alt-del out of the problem ... ??

Gareth Bult (gareth-encryptec) wrote :

Ok, removed lots of other stuff completely, like vmware .. just had the problem again and noticed this in the logs;

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

So .. same problem.
This looks like a show-stopper if anyone is thinking of trying to release Intrepid (!)

Gareth Bult (gareth-encryptec) wrote :

Ok, I think I've found the cause .. looks like it could be the "Xinerama" setting.
(i.e. graphics card independent)

This is going to hit anyone with more than one screen.
(anyone who's tried Twinview and Xinerama on a decent graphics card won't be using twinview!)

I'm running 4 screens here .. after reverting to Xinerama=0 in xoard.conf, problems seem to have gone away. Going one better, when running with Xinerama on, many applications, although running Ok, reported a lack of the XRANDR extension on starting up. (easy example is gkrellm)

When turning off Xinerama, this error also vanishes !!
Note that in either instance the Xorg.0.log reports that internal RANDR extension loads up Ok.

Same issue here on a fresh intreprid install (not an update from 8.04):
Total xorg freeze during ~20s and "[mi] EQ overflowing" in the xorg log.

nvidia 177.80 is installed.
I'm on a laptop, only one screen, nothing but the automatically generated xorg.conf (no extra options). One usb mouse always plugged.

I would be happy to test whatever you want to find where it comes from.

Xavier

Gareth Bult (gareth-encryptec) wrote :

Hi, please can you verify whether you have Xinerama on or off .. if in doubt, please add;

Section "ServerFlags"
        Option "Xinerama" "0"
EndSection

To /etc/X11/xorg.conf.

I was seeing crashes every few minutes or hours .. I've now gone 48h without a crash after making this change ...

Ok...at least 6hours without a freeze...the bug could really be in
Xinerama :)
Now we have to figure out why...

:(

"I can easily reproduce it when i use "Folder view" plasmoid... When i
click on a file within folder view or when i try
to select multiple files..."

Indeed...X lockups each time I do that. Each time I get get "[mi] EQ
overflowing. The server is probably stuck in an infinite loop." in
Xorg.0.log.

Can someone please confirm that the bug is present not only on kubuntu
but also on ubuntu?

I have nvidia in a dual screen configuration using twinview (xinerama is disabled) running Ubuntu intrepid.
Usually after idle time the screen crashes,

I can see in my log file the following errors before the loop error messages begin:

Backtrace:
0: /usr/X11R6/bin/X(xf86SigHandler+0x65) [0x480f35]
1: /lib/libc.so.6 [0x7f48a6a41060]
2: /lib/libc.so.6 [0x7f48a6a89988]
3: /lib/libc.so.6(cfree+0x76) [0x7f48a6a89f86]
4: /usr/lib/libGLcore.so.1 [0x7f48a4cbe878]
5: /usr/lib/libGLcore.so.1 [0x7f48a4a67d1b]
6: /usr/lib/libGLcore.so.1 [0x7f48a4a1a7e9]
7: /usr/lib/libGLcore.so.1 [0x7f48a4ca058d]
8: /usr/lib/libGLcore.so.1 [0x7f48a4c5f2da]
9: /usr/lib/libGLcore.so.1 [0x7f48a4c60842]
10: /usr/lib/libGLcore.so.1 [0x7f48a49f9580]
11: /usr/lib/xorg/modules/extensions//libglx.so [0x7f48a5797e6f]
Saw signal 11. Server aborting.
[mi] EQ overflowing. The server is probably stuck in an infinite loop.
[mi] mieqEnequeue: out-of-order valuator event; dropping.

"Bad" news:
I'm not able to reproduce this bug on my box using the nv driver. So, either it is a bug in nvidia driver and we have to wait for a fix, either it is a bug on the open source side. It can be in the kernel (drm and so on), in Xorg or even, in qt or in kde..

I used to play with gdb/valgring but if someone could tell me how I'm supposed to start X and plasma so that I could get a useful backtrace if would be nice.

If someone can reproduce that using the nv driver please let us know asap :)

Gregor Kappler (g-kappler) wrote :

I can confirm that this bug affects the OS ati driver as well:

I use kububtu/kwin and "ati" driver. Desktop effects are on. There is no xinerama section in my xorg.conf.
xorg is freezing at random times - I could not detect any pattern yet.

When logging in with ssh from my other machine Xorg process is at nearly 100% CPU, I can kill it only with signal 9, then X starts up fresh to the login screen.

Xorg.log spits out a lot of these messages:

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

Hum ok but I would like to see someone using ubuntu (and not kubuntu) able to reproduce that.
My point is the following : Are we sure it does not come from qt/kde trying to ask the X server do something fully wrong?

Ok ok it looks like it is a bug at a lower level...

TheBus (tw2006) wrote :

i have the same issue with openchrome driver (VIA KN8000) on a benq laptop. If i use vesa on xorg.conf it work but the resolution is very bad. With 8.04 it worked perfect

Using KDE or gnome?

I use Gnome ...

----- Original Message -----
From: "Xavier Gnata" <email address hidden>
To: <email address hidden>
Sent: Wednesday, 5 November, 2008 10:55:17 AM GMT +00:00 GMT Britain, Ireland, Portugal
Subject: [Bug 259808] Re: X Lockup in Intrepid (infinite loop)

Using KDE or gnome?

--
X Lockup in Intrepid (infinite loop)
https://bugs.launchpad.net/bugs/259808
You received this bug notification because you are a direct subscriber
of the bug.

--
Managing Director, Encryptec Limited
Tel: 0845 5082719, Mob: 0785 3305393
Email: <email address hidden>
Statements made are at all times subject to Encryptec's Terms and Conditions of Business, which are available upon request.

Following the suggestion made by Gareth Bult (https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/259808/comments/26) I stopped experiencing hard lock-ups with my network updated intrepid, OS ati driver with desktop effects activated in kwin.

Although I was not able to reproduce the bug, it appeared most frequently when opening windows menus such as "file", "modify", "view", etc.

praveer01 (praveer12) wrote :

Gareth Bult, yes I tried adding

Section "ServerFlags"
        Option "Xinerama" "0"
EndSection

To /etc/X11/xorg.conf.

but it doesnt change the behavior of lockups in kde, whereas in gnome strangely X wont lockup at all. So the bug seems to be specific to kde

Specs: Using nvidia driver(kmod-nvidia-2.6.26.5-45.fc9.i686) + kde4 + fedora 9

praveer01 (praveer12) wrote :

correction to above reply, the addition of above content to xorg.conf didnt change behavior in gnome, X+gnome was stable previously even before adding Option "Xinerama" "0" to xorg.conf

I only use Gnome, so I think that theory may also have an imperfection .. (!)

----- Original Message -----
From: "praveer01" <email address hidden>
To: <email address hidden>
Sent: Wednesday, 5 November, 2008 5:50:17 PM GMT +00:00 GMT Britain, Ireland, Portugal
Subject: [Bug 259808] Re: X Lockup in Intrepid (infinite loop)

correction to above reply, the addition of above content to xorg.conf
didnt change behavior in gnome, X+gnome was stable previously even
before adding Option "Xinerama" "0" to xorg.conf

--
X Lockup in Intrepid (infinite loop)
https://bugs.launchpad.net/bugs/259808
You received this bug notification because you are a direct subscriber
of the bug.

--
Managing Director, Encryptec Limited
Tel: 0845 5082719, Mob: 0785 3305393
Email: <email address hidden>
Statements made are at all times subject to Encryptec's Terms and Conditions of Business, which are available upon request.

it might, but thats the case right now, gnome+x = no X lockups :-)

Richard (richardbe) wrote :

It appears I am having the same problem (or a variation). Xorg doesn't lockup but I become unable to click with the mouse. I am able to use the keyboard as well as move the mouse (useless if I can't click). I can start some programs but other programs never start complaining about RANDR missing. Restarting the xserver works but simply changing to tty1 and back doesn't solve the problem. I haven't worked out if something I do triggers the problem or if it happens randomly.

I'm running Intrepid with gnome (upgraded) with xinerama using 2 nvidia cards.

One thing I did notice is that when I move the mouse it sometimes changes to the icon for text input but this doesn't correspond to what is actually on the screen. I also noticed that if I start totem the mouse disappears when I move it across an area on the first monitor where totem is playing on the third.

Richard (richardbe) wrote :

I forgot to mention that if I start Synergy and connect my laptop to the computer running Intrepid that the mouse works as normal on my laptop while continuing to have the same problem on the desktop.

This is the same problem .. try turning Xinerama off.

One thing I have noticed, I DO get the lockups still on occasion, however they only last for 20 seconds and only affect ONE screen.

----- Original Message -----
From: "Richard" <email address hidden>
To: <email address hidden>
Sent: Thursday, 6 November, 2008 8:06:03 AM GMT +00:00 GMT Britain, Ireland, Portugal
Subject: [Bug 259808] Re: X Lockup in Intrepid (infinite loop)

It appears I am having the same problem (or a variation). Xorg doesn't
lockup but I become unable to click with the mouse. I am able to use the
keyboard as well as move the mouse (useless if I can't click). I can
start some programs but other programs never start complaining about
RANDR missing. Restarting the xserver works but simply changing to tty1
and back doesn't solve the problem. I haven't worked out if something I
do triggers the problem or if it happens randomly.

I'm running Intrepid with gnome (upgraded) with xinerama using 2 nvidia
cards.

One thing I did notice is that when I move the mouse it sometimes
changes to the icon for text input but this doesn't correspond to what
is actually on the screen. I also noticed that if I start totem the
mouse disappears when I move it across an area on the first monitor
where totem is playing on the third.

--
X Lockup in Intrepid (infinite loop)
https://bugs.launchpad.net/bugs/259808
You received this bug notification because you are a direct subscriber
of the bug.

--
Managing Director, Encryptec Limited
Tel: 0845 5082719, Mob: 0785 3305393
Email: <email address hidden>
Statements made are at all times subject to Encryptec's Terms and Conditions of Business, which are available upon request.

Ok I have updated the kernel and some kde package via apt-get dist-upgrade but I still have the same problem. No improvement.
It would be nice to have one xorg maintainer here to tell us what we should do to help in an as efficient as possible way.

My config : nvidia driver (and not nv), one screen only, xinerama off in xorg.conf. A fresh and up to date intrepid kubuntu (no upgrade from 8.04 but a fully new install).

X lockup during at least 10s. No real way to know what triggers that bug but I occurs each time I try to select files in a plamoid directory view.
[mi] mieqEnequeue: out-of-order valuator event; dropping.
[mi] EQ overflowing. The server is probably stuck in an infinite loop.

Bryce Harrington (bryce) wrote :

> It would be nice to have one xorg maintainer here to tell us what we should do to help in an as efficient as possible way.

Well, we're still awaiting a backtrace on the issue. See http://wiki.ubuntu.com/X/Backtracing for directions.

Also take note as mentioned above that the "[mi] EQ overflowing..." is a generic error message that gets printed for a variety of different error cases.

So, probably everyone who is saying "me too" on this bug is probably in reality having a completely separate, unrelated bug. None of which have been reported with enough data to begin troubleshooting on. I'm going to retitle this bug to focus only on the original reporter's issue; others seeing similar behavior really ought to file new bugs (after reproducing on Intrepid).

Bryce Harrington (bryce) wrote :

Hmm... actually Jon did not provide any details in his original report except for the error message and doesn't seem to have responded at all since then, so with such generic info we can't troubleshoot this at all.

I'll recast the bug to "Error message causes confusion".

All of the lockup errors people have commented on in this bug MUST be reported as separate bug reports.

Changed in xorg-server:
status: Incomplete → Triaged
importance: Undecided → Wishlist
description: updated
Richard (richardbe) wrote :

I have changed a few of the options of the nvidia driver and also updated the kernel and so far have not had the same problem. If it happens again I will try disabling Xinerama. It isn't a long term solution though as I need to be able to move windows across screens.

I enabled the option which shows the location of the mouse when control is pressed and when I had this problem last time it located the mouse in the upper left hand corner of the left most screen regardless of where the mouse actually was.

Bryce Harrington (bryce) wrote :

Here's a shot at cleaning up the error message to make it a bit more clear on what's going on.

This will make it print the backtrace, and maybe the mieqEnequeue line once, and then print out "stuck in a loop" as much as it wants, and refer the user to the backtrace for details.

For those who are trying to debug your individual lockup issues, I wrote a section on "Debugging Hangs" on https://wiki.ubuntu.com/X/Backtracing that you might find of use. If you find it incomplete or confusing, let me know (or edit the wiki directly.)

Thanks a lot for the link and the patch.
Please see : https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/294941

lockup-err-msg-cleanup.patch looks great to get a backtrace when X lockups.
The problem is that I cannot figure out on which version of mieq.c should be patched.

It is easy to modify this patch so that is can be applied on mieq.c you get viq apt-get source but it doesn't compile (xorg-backtrace() is not definied).

Could someone tell me how I can get the correct set of files to perform this test.

Well, just related to my previous comment (https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/259808/comments/36), I have to say I spoke too soon. X is continuing to lockup even with Xinerama disabled. It still happens randomly and I cannot reproduce it at all. I lost some work twice already. Now I "cleaned up" my xorg.conf and if it happens again I'll switch composite off. Best of luck with debugging the issue...

Tormod Volden (tormodvolden) wrote :

I refreshed Bryce's patch for xorg-server 1.5.3.

xenophed (xenophed) wrote :

guys it is a gl mode bug and I can turn the bug on and off using glmode and non glmode screensavers
p.s.graphics chipset does not seem to matter check forum

Cinquero (cinquero) wrote :

Quite similar bug here:

[mi] EQ overflowing. The server is probably stuck in an infinite loop.

Backtrace:
0: /usr/bin/X (xorg_backtrace+0x28) [0x4a3238]
1: /usr/bin/X (mieqEnqueue+0x1f4) [0x4a2ab4]
2: /usr/bin/X (xf86PostMotionEventP+0xc4) [0x47ce94]
3: /usr/lib/xorg/modules/input/evdev_drv.so (0x7fe6668d1000+0x53cf) [0x7fe6668d63cf]
4: /usr/bin/X (0x400000+0x6fca7) [0x46fca7]
5: /usr/bin/X (0x400000+0x11d1b3) [0x51d1b3]
6: /lib/libpthread.so.0 (0x7fe66adf1000+0xf8f0) [0x7fe66ae008f0]
7: /usr/bin/X (0x400000+0x65700) [0x465700]
8: /lib/libpthread.so.0 (0x7fe66adf1000+0xf8f0) [0x7fe66ae008f0]
9: /usr/lib/libpixman-1.so.0 (0x7fe66a756000+0x42f90) [0x7fe66a798f90]
10: /usr/lib/libpixman-1.so.0 (0x7fe66a756000+0x431c8) [0x7fe66a7991c8]
11: /usr/lib/libpixman-1.so.0 (pixman_blt+0x78) [0x7fe66a785818]
12: /usr/lib/xorg/modules/libfb.so (fbCopyNtoN+0x26a) [0x7fe667280b6a]
13: /usr/lib/xorg/modules/drivers/intel_drv.so (0x7fe667cac000+0x61168) [0x7fe667d0d168]
14: /usr/lib/xorg/modules/drivers/intel_drv.so (0x7fe667cac000+0x6539d) [0x7fe667d1139d]
15: /usr/bin/X (0x400000+0xd8110) [0x4d8110]
16: /usr/bin/X (0x400000+0xd182e) [0x4d182e]
17: /usr/bin/X (0x400000+0x30c3c) [0x430c3c]
18: /usr/bin/X (0x400000+0x261aa) [0x4261aa]
19: /lib/libc.so.6 (__libc_start_main+0xfd) [0x7fe669ae9c4d]
20: /usr/bin/X (0x400000+0x25d59) [0x425d59]

Steps to reproduce:

Latest (with all the latest updates as of right now) Ubuntu Lucid (Stable, 10.04).

1. start Firefox 3.6.3
2. open a second window (not tab!)
3. go to http://www.ardmediathek.de/ard/servlet/
4. Xorg hangs

in most cases, the X screen is then locked with the backtrace shown above.

Seems to be a Flash plugin concurrency issue in Firefox.

    npwrapper.libflashplayer.so
    Version: Shockwave Flash 10.1 r53

And: graphics chipset is not ATI, but integrated Intel. GL mode does not matter -- problem persists in 3D and 2D desktop mode.

Same here.

[mi] EQ overflowing. The server is probably stuck in an infinite loop.

Backtrace:
0: /usr/bin/X (xorg_backtrace+0x28) [0x45fcc8]
1: /usr/bin/X (mieqEnqueue+0x1f4) [0x45b344]
2: /usr/bin/X (xf86PostMotionEventP+0xc4) [0x487564]
3: /usr/lib/xorg/modules/input/evdev_drv.so (0x7fe3a98be000+0x53cf) [0x7fe3a98c33cf]
4: /usr/bin/X (0x400000+0x701b7) [0x4701b7]
5: /usr/bin/X (0x400000+0x110263) [0x510263]
6: /lib/libpthread.so.0 (0x7fe3aebed000+0xf8f0) [0x7fe3aebfc8f0]
7: /lib/libc.so.6 (ioctl+0x7) [0x7fe3ad9a4197]
8: /lib/libdrm.so.2 (drmIoctl+0x28) [0x7fe3abf555b8]
9: /lib/libdrm.so.2 (drmCommandWrite+0x1b) [0x7fe3abf5583b]
10: /lib/libdrm_nouveau.so.1 (0x7fe3ab917000+0x2f7d) [0x7fe3ab919f7d]
11: /lib/libdrm_nouveau.so.1 (nouveau_bo_map_range+0xfc) [0x7fe3ab91a1bc]
12: /lib/libdrm_nouveau.so.1 (0x7fe3ab917000+0x2166) [0x7fe3ab919166]
13: /lib/libdrm_nouveau.so.1 (nouveau_pushbuf_flush+0x29c) [0x7fe3ab9194fc]
14: /usr/lib/xorg/modules/libexa.so (0x7fe3aaa72000+0x9555) [0x7fe3aaa7b555]
15: /usr/lib/xorg/modules/libexa.so (0x7fe3aaa72000+0xa0ea) [0x7fe3aaa7c0ea]
16: /usr/bin/X (0x400000+0xd91bb) [0x4d91bb]
17: /usr/lib/xorg/modules/libexa.so (0x7fe3aaa72000+0xb3bd) [0x7fe3aaa7d3bd]
18: /usr/bin/X (0x400000+0xd8bbe) [0x4d8bbe]
19: /usr/bin/X (0x400000+0xcf04e) [0x4cf04e]
20: /usr/bin/X (0x400000+0x4418c) [0x44418c]
21: /usr/bin/X (0x400000+0x261aa) [0x4261aa]
22: /lib/libc.so.6 (__libc_start_main+0xfd) [0x7fe3ad8e4c4d]
23: /usr/bin/X (0x400000+0x25d59) [0x425d59]

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Bug attachments