This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 464866 - [845G, 915GM] Xorg lockup with intel video: "EQ overflowing. The server is probably stuck in an infinite loop."
[845G, 915GM] Xorg lockup with intel video: "EQ overflowing. The server is pr...
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-intel (Show other bugs)
12
All Linux
medium Severity high
: ---
: ---
Assigned To: Adam Jackson
Fedora Extras Quality Assurance
: Reopened, Triaged
: 454069 465707 470094 470422 472935 477859 501256 513245 520274 (view as bug list)
Depends On:
Blocks: F10Target eq-overflow
  Show dependency treegraph
 
Reported: 2008-09-30 18:01 EDT by Will Woods
Modified: 2013-01-09 23:49 EST (History)
56 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-12-11 15:07:43 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Xorg.0.log (188.47 KB, text/plain)
2008-09-30 18:01 EDT, Will Woods
no flags Details
xorg.conf (593 bytes, text/plain)
2008-09-30 18:02 EDT, Will Woods
no flags Details
Xorg.0.log (160.26 KB, text/plain)
2008-10-14 15:47 EDT, Will Woods
no flags Details
Xorg.0.log.working (92.78 KB, text/plain)
2008-10-14 17:42 EDT, Will Woods
no flags Details
Xorg.0.log - compiz lockup (130.57 KB, text/plain)
2008-10-15 16:43 EDT, Will Woods
no flags Details
Xorg log file for X hang up after enabling destop effects on MacBook2 (96.56 KB, text/plain)
2008-11-06 18:18 EST, Joachim Katzer
no flags Details
Xorg log file with EQ errors (228.07 KB, text/plain)
2008-11-08 03:14 EST, Tim Lauridsen
no flags Details
My Xorg.0.log (167.16 KB, text/plain)
2008-11-12 16:41 EST, Kevin Fenzi
no flags Details
Xorg log file with EQ errors (111.00 KB, text/plain)
2008-11-15 01:56 EST, Tim Lauridsen
no flags Details
Xorg log file with EQ errors (280.97 KB, text/plain)
2008-11-30 00:33 EST, Tim Lauridsen
no flags Details
Xorg.0.log (136.23 KB, text/plain)
2008-12-20 00:15 EST, Mace Moneta
no flags Details
Xorg.0.log.old after from X lockup (141.03 KB, text/plain)
2008-12-20 21:19 EST, David Crowe
no flags Details
latest Xorg.0.log.old after hangup (764.35 KB, text/plain)
2009-01-06 05:27 EST, Tim Lauridsen
no flags Details
Xorg.0.log.old from after bug variant 2 has occurred. (110.02 KB, text/plain)
2009-01-30 21:13 EST, Thomas M Steenholdt
no flags Details
Recently hit this, with fully up to date xorg packages (134.61 KB, text/plain)
2009-03-12 06:10 EDT, Dave Russell
no flags Details
eq overflowing on fedora 12 xorg.log (46.22 KB, text/plain)
2009-11-20 12:56 EST, Derrick
no flags Details
EQ Overflowing lockups with xorg-x11-drv-intel-2.9.1-1.fc12.i686 (40.96 KB, text/plain)
2009-11-21 06:36 EST, Hideki Yoshida
no flags Details
Xorg.0.log from IBM Thinkpad x41t with intel 915GM (221.88 KB, text/plain)
2009-11-25 23:03 EST, Richard Schwarting
no flags Details
Xorg.0.log.old from after freeze in f12 (53.75 KB, text/plain)
2009-12-07 00:25 EST, p.johns
no flags Details

  None (edit)
Description Will Woods 2008-09-30 18:01:19 EDT
Created attachment 318142 [details]
Xorg.0.log

kernel-2.6.27-0.370.rc8.fc10.i686
xorg-x11-drv-i810-2.4.2-8.fc10.i386

After a while on my Intel Mac Mini (i945 video), X locks up. The only thing strange going on was that the flash plugin had just segfaulted. (Actually, that's not all that strange.)

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

So I ssh in from another machine and killall -9 Xorg. This results in this line appearing in syslog:

Sep 30 17:46:07 kraid kernel: [drm:i915_gem_idle] *ERROR* hardware wedged

The screen turns black with some vertical colored stripes. Attempting to start X causes some mode-switching to happen, and the screen turns black, but no display. The following line appears in syslog: 

Sep 30 17:46:12 kraid kernel: [drm:i915_gem_entervt_ioctl] *ERROR* Reenabling wedged hardware, good luck

Alas, my luck is not good. Nothing I can do seems to bring the display back up, so I rebooted.
Comment 1 Will Woods 2008-09-30 18:02:12 EDT
Created attachment 318143 [details]
xorg.conf

Xorg.conf - nothing too interesting here. 'intel' driver, 24bpp.
Comment 2 Will Woods 2008-10-14 15:47:41 EDT
Created attachment 320347 [details]
Xorg.0.log

Reproduced with xorg-x11-drv-i810-2.4.2-9.fc10.i386 and xorg-x11-server-Xorg-1.5.2-3.fc10.i386 - now with tracebacky goodness!
Comment 3 Adam Jackson 2008-10-14 15:56:23 EDT
Yeah, seen that one before.  The driver is stuck waiting for the kernel to get a throttling interrupt from the GPU, which never comes.  Thanks GEM.

I can repro this on my vaio, which is a GM45.  Interesting that it affects 945GM too...
Comment 4 Will Woods 2008-10-14 17:42:27 EDT
Created attachment 320361 [details]
Xorg.0.log.working

Here's the Xorg.0.log from a patched driver provided by ajax. It's working fine.

http://koji.fedoraproject.org/scratch/ajax/task_880907/xorg-x11-drv-i810-2.4.2-10.fc10.jx.i386.rpm
Comment 5 Will Woods 2008-10-15 16:43:20 EDT
Created attachment 320484 [details]
Xorg.0.log - compiz lockup

To amend my previous comment: X is working fine.. so long as I don't try to enable compiz. 

Different, possibly interesting Xorg.0.log attached.
Comment 6 Jesse Keating 2008-10-27 18:26:46 EDT
As we don't do compiz by default, I'm moving this off of Preview.  I'll leave it on the F10 Blocker, but I"d rather ajax gave a decision on if it hits enough hardware to be considered a slippable bug.
Comment 7 Bill Nottingham 2008-11-04 13:38:47 EST
*** Bug 465707 has been marked as a duplicate of this bug. ***
Comment 8 Joachim Katzer 2008-11-06 18:18:49 EST
Created attachment 322796 [details]
Xorg log file for X hang up after enabling destop effects on MacBook2
Comment 9 Joachim Katzer 2008-11-06 18:24:04 EST
Same problem occurs on MacBook (2nd generation) with Intel 945GM when enabling
desktop effects on F10 Preview Live-CD (GNOME desktop).

kernel-2.6.27.4-79.fc10.i686
xorg-x11-server-Xorg-1.5.2-12.fc10.i386
xorg-x11-drv-i810-2.5.0-1.fc10.i386

When this happens, all desktop objects disappear, background image remains, no
mouse and keyboard input possible. Remote access is still possible, otherwise
power has to be turned off.
Comment 10 Jarod Wilson 2008-11-07 13:27:04 EST
ThinkPad T61 (i965GM, x86_64) behaving identically to comment #9 here. Acer Aspire One behaving slightly different -- black screen, w/video showing through in a square around the cursor. Seems possibly related to bug 467332.
Comment 11 Tim Lauridsen 2008-11-08 03:14:00 EST
Created attachment 322931 [details]
Xorg log file with EQ errors

I had this issue on a TP60

00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03)

I was not running Compiz.
I was just reading a mail and the animated cursor froze, i could move it, but to no use.
C-A-F2 etc was not workning.
Pressing the power button made the system shutdown, but ended up with a lot of random colors on the screen and the caps led was blinking and i had to hold down
the power button to kill the system.

The attached xorg log file contains a lot of EQ errors.

i also have the error with resume when Compiz is running
https://bugzilla.redhat.com/show_bug.cgi?id=467332
Comment 12 Tim Lauridsen 2008-11-08 03:18:21 EST
Forgot to tell that my system is running F9, upgraded to Rawhide
Comment 13 Matěj Cepl 2008-11-10 13:19:18 EST
*** Bug 470422 has been marked as a duplicate of this bug. ***
Comment 14 Adrian Ponoran 2008-11-11 11:30:15 EST
I think it is happening with most of the intel videocards. I have an Intel 82852/82855 (855GM) graphics controller. 
I compiled and tried all this intel video drivers:

  xf86-video-intel-2.4.97.0
  xf86-video-intel-2.4.98.0
  xf86-video-intel-2.5.0

and it behaves the same.
Comment 15 Youknowwho 2008-11-12 07:31:27 EST
I'm having the same bug on an Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller rev 3 on a Toshiba A205, when i try to suspend the laptop, it suspends, but when I try to resume, all I get is a black screen with a locked cursor and keyboard, by the look of it, it seems that only intel cards  are affected with this bug, without compiz enable, the suspend and hibernate functions just right.
Comment 16 Kevin Fenzi 2008-11-12 16:41:35 EST
Created attachment 323391 [details]
My Xorg.0.log

I am seeing this here as well... attaching my Xorg.0.log.old (after booting)
Comment 17 Charles R. Anderson 2008-11-13 18:55:51 EST
Same here on Dell Optiplex GX260:

Intel Corporation 82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device (rev 01)

kernel-2.6.27.5-101.fc10.i686
xorg-x11-drv-i810-2.5.0-3.fc10.i386
Comment 18 Charles R. Anderson 2008-11-13 19:07:16 EST
I just read a lesson on the intel graphics chip generations:

"broadly speaking the intel graphics classes are (i810, i815), (i830, i845, i855, i865), (i915, i945), (965 and newer). i tend to assume bugs against one class are not bugs against another until proven otherwise."--ajax

I hadn't realized that 82845G means i845, so it seems my bug is really #461205, not this one.
Comment 19 Will Woods 2008-11-14 12:53:53 EST
As far as we can tell, the random lockups are now fixed. Closing.

Reopen this bug *only* if you have an intel i9xx chipset system that locks up *randomly* - not because of a VT switch or resume from suspend, and not when running compiz.

Lockups on resume from suspend or VT switch are bug 467332.
Comment 20 Tim Lauridsen 2008-11-15 01:56:05 EST
Created attachment 323687 [details]
Xorg log file with EQ errors
Comment 21 Tim Lauridsen 2008-11-15 02:03:02 EST
I still has random lockups, i had one yesterday, se the attached log.

i have an IBM Thinkpad T60, with this

00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03)

$ uname -r
2.6.27.5-101.fc10.i686

$ rpm -q  xorg-x11-drv-i810
xorg-x11-drv-i810-2.5.0-3.fc10.i386

and i'm not running compiz.

the lockup happen while browsing the net.
Comment 22 Tim Lauridsen 2008-11-15 06:51:03 EST
i happend again today :(

$ uname -r
2.6.27.5-109.fc10.i686
Comment 23 Tomasz Torcz 2008-11-17 13:21:27 EST
I've getting this with GM45 mobile when I enable compiz. There's some backtrace in Xorg, should I reproduce this bug and paste bt here?
Comment 24 Will Woods 2008-11-17 13:50:08 EST
(In reply to comment #23)
> I've getting this with GM45 mobile when I enable compiz. There's some backtrace
> in Xorg, should I reproduce this bug and paste bt here?

No. This bug is for *spontaneous* lockups *without* compiz. 

If it's happening on resume-from-suspend or VT switch *with* compiz, try bug 467332 instead.
Comment 25 Jesse Keating 2008-11-18 22:29:08 EST
Guys, I don't think we'll get a perfect fix for this before the release.  Since you are able to get into it, and it doesn't lock up immediately, I'm going to de-classify this as a release blocker.  We'll try to fix it as soon as possible with an update to Fedora 10.
Comment 26 Tim Lauridsen 2008-11-19 01:30:00 EST
I have not had any lockups for the last couple of days, earlier it was almost every day. Yesterday,i have reinstalled my laptop with F10 PreRelease and updated from rawhide, earlier it was a F9 updated to rawhide a couple of months ago.
So it look like the situation is better now (i hope).
So go on with the release of F10 :)
Comment 27 Bug Zapper 2008-11-25 22:17:56 EST
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 28 Tim Lauridsen 2008-11-30 00:31:57 EST
Did not have this error for a while, but now i got it again.
fully updated F10

$ uname -r
2.6.27.5-120.fc10.i686
Comment 29 Tim Lauridsen 2008-11-30 00:33:51 EST
Created attachment 325112 [details]
Xorg log file with EQ errors
Comment 30 Lennart Poettering 2008-12-18 09:18:03 EST
This is still a problem for me. My X60s is still kind of useless with this breakage.
Comment 31 Mace Moneta 2008-12-20 00:15:03 EST
Created attachment 327524 [details]
Xorg.0.log

Still happening.

kernel-2.6.27.9-163.fc10.x86_64
xorg-x11-drv-i810-2.5.0-4.fc10.x86_64
mesa-libGL-7.2-0.15.fc10.x86_64
mesa-libGL-7.2-0.15.fc10.i386
mesa-libGLU-7.2-0.15.fc10.x86_64
mesa-libGLU-7.2-0.15.fc10.i386
mesa-dri-drivers-7.2-0.15.fc10.x86_64
Comment 32 Mace Moneta 2008-12-20 17:16:08 EST
I can recreate this 100% of the time, by enabling the "Bicubic filter" in ccsm Effects section.  Enable the filter, drag a window, hung with an EQ overflow.
Comment 33 David Crowe 2008-12-20 21:18:01 EST
this happens randomly for me on a dell d420 laptop with up-to-date F10. www.smolts.org profile at:

http://www.smolts.org/client/show/?uuid=pub_eafd6792-3f81-4f74-97c9-a7540e1dff25

will attach Xorg log file.
Comment 34 David Crowe 2008-12-20 21:19:13 EST
Created attachment 327555 [details]
Xorg.0.log.old after from X lockup
Comment 35 Matěj Cepl 2008-12-22 06:12:26 EST
OK, here we are:

Backtrace:
0: /usr/bin/Xorg(xorg_backtrace+0x3b) [0x812bc5b]
1: /usr/bin/Xorg(mieqEnqueue+0x289) [0x810b379]
2: /usr/bin/Xorg(xf86PostMotionEventP+0xc2) [0x80d4262]
3: /usr/bin/Xorg(xf86PostMotionEvent+0x68) [0x80d43c8]
4: /usr/lib/xorg/modules/input//synaptics_drv.so [0x3938fe]
5: /usr/lib/xorg/modules/input//synaptics_drv.so [0x395f79]
6: /usr/bin/Xorg [0x80bcdb7]
7: /usr/bin/Xorg [0x80ac91e]
8: [0x110400]
9: [0x110416]
10: /lib/libc.so.6(ioctl+0x19) [0x65a979]
11: /usr/lib/libdrm.so.2 [0x691d6cf]
12: /usr/lib/libdrm.so.2(drmCommandNone+0x2a) [0x691da1a]
13: /usr/lib/xorg/modules/drivers//intel_drv.so [0x23d970]
14: /usr/bin/Xorg [0x8162bff]
15: /usr/bin/Xorg [0x813c49a]
16: /usr/bin/Xorg(BlockHandler+0x58) [0x8089ac8]
17: /usr/bin/Xorg(WaitForSomething+0x10d) [0x8128f0d]
18: /usr/bin/Xorg(Dispatch+0x7e) [0x8085bce]
19: /usr/bin/Xorg(main+0x47d) [0x806b71d]
20: /lib/libc.so.6(__libc_start_main+0xe5) [0x5956e5]
21: /usr/bin/Xorg [0x806ab01]
Comment 36 Tim Lauridsen 2009-01-06 05:27:23 EST
Created attachment 328261 [details]
latest Xorg.0.log.old after hangup

Here we go again :(

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

Backtrace:
0: /usr/bin/Xorg(xorg_backtrace+0x3b) [0x812bc5b]
1: /usr/bin/Xorg(mieqEnqueue+0x289) [0x810b379]
2: /usr/bin/Xorg(xf86PostMotionEventP+0xc2) [0x80d4262]
3: /usr/bin/Xorg(xf86PostMotionEvent+0x68) [0x80d43c8]
4: /usr/lib/xorg/modules/input//evdev_drv.so [0x275a8d]
5: /usr/bin/Xorg [0x80bcdb7]
6: /usr/bin/Xorg [0x80ac91e]
7: [0x110400]
8: [0x110416]
9: /lib/libc.so.6(ioctl+0x19) [0x7ad979]
10: /usr/lib/libdrm.so.2 [0x4e146cf]
11: /usr/lib/libdrm.so.2(drmCommandWrite+0x34) [0x4e14984]
12: /usr/lib/xorg/modules/drivers//intel_drv.so(I830Sync+0x135) [0x2b7ca5]
13: /usr/lib/xorg/modules/drivers//intel_drv.so [0x2e197a]
14: /usr/lib/xorg/modules//libexa.so(exaWaitSync+0x65) [0x266095]
15: /usr/lib/xorg/modules//libexa.so(ExaDoPrepareAccess+0x7e) [0x2673ae]
16: /usr/lib/xorg/modules//libexa.so [0x26c3b2]
17: /usr/lib/xorg/modules//libexa.so [0x26c905]
18: /usr/lib/xorg/modules//libexa.so(exaDoMigration+0x652) [0x26d0c2]
19: /usr/lib/xorg/modules//libexa.so(exaCopyNtoN+0x3f1) [0x269fd1]
20: /usr/lib/xorg/modules//libexa.so(exaComposite+0x90e) [0x26f4de]
21: /usr/bin/Xorg [0x816f6fa]
22: /usr/bin/Xorg(CompositePicture+0x19a) [0x815818a]
23: /usr/bin/Xorg [0x815e055]
24: /usr/bin/Xorg [0x815ad75]
25: /usr/bin/Xorg(Dispatch+0x34f) [0x8085e9f]
26: /usr/bin/Xorg(main+0x47d) [0x806b71d]
27: /lib/libc.so.6(__libc_start_main+0xe5) [0x6e86e5]
28: /usr/bin/Xorg [0x806ab01]
[mi] mieqEnequeue: out-of-order valuator event; dropping.
[mi] EQ overflowing. The server is probably stuck in an infinite loop.
Comment 37 Jarod Wilson 2009-01-08 10:53:35 EST
Happens on my T61 w/intel x3100 too, but usually takes hours, if not days, before it hits.
Comment 38 Thomas M Steenholdt 2009-01-08 21:38:50 EST
On my system, leaving Compiz disabled seems to mask this issue. Once I enable Compiz, it usually takes no more than one of two DPMS off events (when the laptop is idle and shuts down the LVDS).

My graphics controller is:
00:02.0 VGA compatible controller: Intel Corporation Cantiga Integrated Graphics Controller (rev 07)
Comment 39 Thomas M Steenholdt 2009-01-20 04:59:09 EST
How is the work on this bug progressing? Seems like enough people are hit by it, so getting any proposed solution tested, shouldn't be an issue. :-)

Is there any info that might be useful for tracking down the root cause of this, any tests you like to see performed, in addition to what has already been put in this bug earlier?

I tried to update the intel driver to 2.5.1, but problems remain. Then again, I am not exactly sure that the intel driver is actually the culprit here?
Comment 40 David Crowe 2009-01-20 11:15:51 EST
i am also very interested in progress toward a solution as this problem is debilitating when it happens.  if there is anything i can do (load test or debug versions, etc) please let us know.
Comment 41 Marko Vojinovic 2009-01-22 12:13:31 EST
I second that. This is a very annoying bug, since it occurs randomly. I have an Intel GM965 card on an Fujitsu-Siemens Esprimo U9200, and if it were my decision, I would find this bug to be a showstopper.

I am also interested to test anything that might make the situation better.
Comment 42 Anders 2009-01-24 13:53:20 EST
Maybe not so useful for you folks if you need acceleration, but if you can live with just 2D graphics, in the Device section, set 'Option "NoAccel" "yes"' and you can at least use your system without lockups. I have run my ThinkPad X60s since shortly after F10 was released this way. If I enable acceleration, instant hang of X and hard reset required. (945GM chip in the X60s.)
Comment 43 Matěj Cepl 2009-01-26 04:16:05 EST
(In reply to comment #42)
> Maybe not so useful for you folks if you need acceleration, but if you can live
> with just 2D graphics, in the Device section, set 'Option "NoAccel" "yes"' and
> you can at least use your system without lockups. I have run my ThinkPad X60s
> since shortly after F10 was released this way. If I enable acceleration,
> instant hang of X and hard reset required. (945GM chip in the X60s.)

Would it be sufficient for you to leave NoAccel in default value and add 

Option "AccelMethod" "XAA"

to xorg.conf, intel driver section, please?
Comment 44 Asko Tontti 2009-01-28 11:17:40 EST
In the case this helps to narrow the problem.

I got very frequent lock ups with kernel-2.6.27.9-159.fc10.x86_64:

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

Backtrace:
0: /usr/bin/Xorg(xorg_backtrace+0x26) [0x4e7a26]
1: /usr/bin/Xorg(mieqEnqueue+0x291) [0x4c8591]
2: /usr/bin/Xorg(xf86PostMotionEventP+0xc4) [0x491494]
3: /usr/bin/Xorg(xf86PostMotionEvent+0xa9) [0x491669]
4: /usr/lib64/xorg/modules/input//evdev_drv.so [0x4db5126]
5: /usr/bin/Xorg [0x47a765]
6: /usr/bin/Xorg [0x46b307]
7: /lib64/libc.so.6 [0x36dee32f90]
8: /lib64/libc.so.6(ioctl+0x7) [0x36deede037]
9: /usr/lib64/libdrm.so.2 [0x36f4c03023]
10: /usr/lib64/libdrm.so.2(drmCommandWrite+0x1b) [0x36f4c032ab]
11: /usr/lib64/xorg/modules/drivers//intel_drv.so(I830Sync+0x118) [0x19a3d38]
12: /usr/lib64/xorg/modules//libexa.so(exaWaitSync+0x5c) [0x103029c]
13: /usr/lib64/xorg/modules//libexa.so(ExaDoPrepareAccess+0x91) [0x1031591]
14: /usr/lib64/xorg/modules//libexa.so [0x1036749]
15: /usr/lib64/xorg/modules//libexa.so [0x1036982]
16: /usr/lib64/xorg/modules//libexa.so(exaPixmapSave+0x28) [0x1036ac8]
17: /usr/lib64/xorg/modules//libexa.so [0x103777f]
18: /usr/lib64/xorg/modules//libexa.so(exaOffscreenAlloc+0x2ef) [0x1037caf]
19: /usr/lib64/xorg/modules//libexa.so [0x1036ceb]
20: /usr/lib64/xorg/modules//libexa.so(exaDoMigration+0x68f) [0x103746f]
21: /usr/lib64/xorg/modules//libexa.so [0x1038bac]
22: /usr/lib64/xorg/modules//libexa.so(exaComposite+0x645) [0x10392d5]
23: /usr/bin/Xorg [0x5291b8]
24: /usr/bin/Xorg [0x5183fa]
25: /usr/bin/Xorg(Dispatch+0x364) [0x4468d4]
26: /usr/bin/Xorg(main+0x45d) [0x42cd1d]
27: /lib64/libc.so.6(__libc_start_main+0xe6) [0x36dee1e576]
28: /usr/bin/Xorg [0x42c0f9]
[mi] mieqEnequeue: out-of-order valuator event; dropping.
...

And I also managed to get kerneloops:
http://www.kerneloops.org/submitresult.php?number=189923

00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Grap
hics Controller (rev 0c)

xorg-x11-drv-i810-2.5.0-4.fc10.x86_64
xorg-x11-server-Xorg-1.5.3-6.fc10.x86_64


But when I downgraded to kernel 2.6.27.5-117.fc10.x86_64 my ThinkPad X300 has now been up for 7 days without any problems.
Comment 45 Eric Donkersloot 2009-01-30 15:51:53 EST
I'm only hitting the bug when compiz fusion is enabled:

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

Backtrace:
0: /usr/bin/Xorg(xorg_backtrace+0x3b) [0x812bc5b]
1: /usr/bin/Xorg(mieqEnqueue+0x289) [0x810b379]
2: /usr/bin/Xorg(xf86PostMotionEventP+0xc2) [0x80d4262]
3: /usr/bin/Xorg(xf86PostMotionEvent+0x68) [0x80d43c8]
4: /usr/lib/xorg/modules/input//evdev_drv.so [0x203d25]
5: /usr/bin/Xorg [0x80bcdb7]
6: /usr/bin/Xorg [0x80ac91e]
7: [0xf5c400]
8: [0xf5c416]
9: /lib/libc.so.6(ioctl+0x19) [0x316979]
10: /usr/lib/libdrm.so.2 [0x3b3a6cf]
11: /usr/lib/libdrm.so.2(drmWaitVBlank+0x28) [0x3b3ae08]
12: /usr/lib/dri/i965_dri.so [0x199578]
13: /usr/lib/dri/i965_dri.so(driWaitForVBlank+0xd8) [0x199798]
14: /usr/lib/dri/i965_dri.so(intelSwapBuffers+0x262) [0x19f5ac]
15: /usr/lib/dri/i965_dri.so [0x199912]
16: /usr/lib/xorg/modules/extensions//libglx.so [0x153504]
17: /usr/lib/xorg/modules/extensions//libglx.so [0x145cfe]
18: /usr/lib/xorg/modules/extensions//libglx.so [0x14963a]
19: /usr/bin/Xorg(Dispatch+0x34f) [0x8085e9f]
20: /usr/bin/Xorg(main+0x47d) [0x806b71d]
21: /lib/libc.so.6(__libc_start_main+0xe5) [0x2516e5]
22: /usr/bin/Xorg [0x806ab01]
[mi] mieqEnequeue: out-of-order valuator event; dropping.

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

00:02.1 Display controller: Intel Corporation Cantiga Integrated Graphics Controller (rev 07)

2.6.27.12-170.2.5.fc10.i686
Comment 46 Eric Donkersloot 2009-01-30 17:56:51 EST
This bug seems to have been introduced in the 2.5 branch of the driver, I have not experienced this bug with any 2.6.27.x kernel and a driver from the 2.4 branch.

Can someone else confirm this as well ?

This is an incredible annoying bug, what about backporting the 2.6 branch to Fedora ? 2.6.1 seems to be the latest stable driver.

http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/
Comment 47 Thomas M Steenholdt 2009-01-30 20:56:36 EST
I may be experiencing two different issues, that "appear" the same.

1) the primary bug in this report ([mi] EQ overflowing. The server is probably stuck in an infinite loop.)

2) same sort of hang appearing upon waking up from DPMS (nothing gets written to the log in this case)

I just installed xorg-x11-drv-i810-2.4.2-12.fc10.x86_64 and was able to at least trigger bug 2 with that version (I can reproduce it by enabling compiz and letting the system go into DPMS sleep once or twice). I'll look for other bug-reports that might be a closer match for 2. Meanwhile, are anyone else experiencing the same thing?
Comment 48 Thomas M Steenholdt 2009-01-30 21:13:44 EST
Created attachment 330516 [details]
Xorg.0.log.old from after bug variant 2 has occurred.

There are a couple of WW and EE statements near the bottom, that might indicate to you guys if these are in fact two completely different bugs?
Comment 49 Matěj Cepl 2009-01-31 15:21:26 EST
(In reply to comment #47)
> 1) the primary bug in this report ([mi] EQ overflowing. The server is probably
> stuck in an infinite loop.)
> 
> 2) same sort of hang appearing upon waking up from DPMS (nothing gets written
> to the log in this case)

Just to explain — “[mi] EQ overflowing” message in the log is very unfortunate thing, because it is very misleading. I was told by the X developers that it could mean almost any problem with the server — translate it for yourself as “X server is unhappy”, but don't try to distill from it much more information. Backtraces which are present in the comments of this bug are much more interesting.
Comment 50 Ben Gamari 2009-01-31 15:56:05 EST
(In reply to comment #49) 
> Just to explain — “[mi] EQ overflowing” message in the log is very unfortunate
> thing, because it is very misleading. I was told by the X developers that it
> could mean almost any problem with the server — translate it for yourself as “X
> server is unhappy”, but don't try to distill from it much more information.
> Backtraces which are present in the comments of this bug are much more
> interesting.

This is quite true. All this means is that the event queue is overflowing (i.e. the event processing loop is stuck somewhere). You can see this in the backtrace in Comment #45: the server is stuck in drmWaitVBlank when it gets an input event. When the server is stuck in drm code like this, this generally means that the GPU has crashed and stopped executing commands.

Unfortunately, gpu crashes are not easy to debug. Generally the best way to approach this is to look at the commands being executed by the GPU directly before it crashed. Unfortunately, while this functionality used to be implemented in the ddx, the recent restructuring with GEM renders this code obsolete so at the moment we have no means of dumping the ring buffer. I currently have a patch awaiting merging which incorporates gpu ring buffer dumping into the drm, but it could be a while until it is merged.
Comment 51 Thomas M Steenholdt 2009-01-31 17:14:54 EST
Perhaps we could include the mentioned patch in a test package, to get this thing solved? People who'd like to help sqaushing these problems could install said package if they choose to. ??
Comment 52 Anders 2009-01-31 17:45:17 EST
(In reply to comment #43)

I have tried with and without
  Option "AccelMethod" "XAA"
and also tried with
  Option "DRI" "no"
but no luck. Only when I run with
  Option "NoAccel" "yes"
can I keep the X server from locking up.

Stacktrace from Xorg in the logfile from that last lockup was:

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

Backtrace:
0: /usr/bin/X(xorg_backtrace+0x3b) [0x812bc5b]
1: /usr/bin/X(mieqEnqueue+0x289) [0x810b379]
2: /usr/bin/X(xf86PostMotionEventP+0xc2) [0x80d4262]
3: /usr/bin/X(xf86PostMotionEvent+0x68) [0x80d43c8]
4: /usr/lib/xorg/modules/input//evdev_drv.so [0x224d25]
5: /usr/bin/X [0x80bcdb7]
6: /usr/bin/X [0x80ac91e]
7: [0xa34400]
8: /lib/libc.so.6(__libc_calloc+0xa3) [0x7c4443]
9: /usr/lib/libdrm_intel.so.1 [0x30c094]
10: /usr/lib/libdrm_intel.so.1 [0x30c5e5]
11: /usr/lib/libdrm_intel.so.1 [0x30ccbc]
12: /usr/lib/libdrm_intel.so.1 [0x30ce75]
13: /usr/lib/libdrm_intel.so.1(dri_bo_exec+0x2e) [0x30b05e]
14: /usr/lib/xorg/modules/drivers//intel_drv.so(intel_batch_flush+0xa4) [0x1a43d4]
15: /usr/lib/xorg/modules/drivers//intel_drv.so [0x1af950]
16: /usr/bin/X [0x8162bff]
17: /usr/bin/X [0x813c49a]
18: /usr/bin/X(BlockHandler+0x58) [0x8089ac8]
19: /usr/bin/X(WaitForSomething+0x10d) [0x8128f0d]
20: /usr/bin/X(Dispatch+0x7e) [0x8085bce]
21: /usr/bin/X(main+0x47d) [0x806b71d]
22: /lib/libc.so.6(__libc_start_main+0xe5) [0x7676e5]
23: /usr/bin/X [0x806ab01]
[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.

/Anders
Comment 53 Mace Moneta 2009-01-31 18:13:50 EST
If the error is caused by a GPU crash, is there an option that will cause the driver to reset and reestablish the state of the GPU on failure (as is done for other controllers, e.g., Firewire, USB, SCSI)?  That this is causing the entire system to hang seems broken well beyond whatever error caused the GPU to crash in the first place.  I can boot a headless system; the system should be able to continue to function with, and recover from, a software fault in the GPU.
Comment 54 Eric Donkersloot 2009-02-05 07:52:47 EST
I've had this issue using Arch as well, seems like the latest stable driver fixed this issue. There is an unsupported Arch package available:

http://aur.archlinux.org/packages.php?ID=22968

http://lists.freedesktop.org/archives/xorg/2009-January/042816.html

Once the 2.6.x branch makes it onto the Arch extra repo, I will test it on my laptop.
Comment 55 Ben Gamari 2009-02-05 10:30:02 EST
(In reply to comment #54)
> I've had this issue using Arch as well, seems like the latest stable driver
> fixed this issue.

It is likely that this bug is in actuality a composite of several issues, it remains to be seen whether all of the sources of this crash will actually be solved with 2.6.0. I for one have been experiencing continuing crashing with xf86-video-intel master, so there are at least still issues in master.

(In reply to comment #53)
> If the error is caused by a GPU crash, is there an option that will cause the
> driver to reset and reestablish the state of the GPU on failure (as is done for
> other controllers, e.g., Firewire, USB, SCSI)?  That this is causing the entire
> system to hang seems broken well beyond whatever error caused the GPU to crash
> in the first place.  I can boot a headless system; the system should be able to
> continue to function with, and recover from, a software fault in the GPU.

At the moment, the ability to reset the GPU after a fault seems pretty far off. I discussed this with anholt (who has the early beginnings of an error-recovery branch in his kernel git tree) yesterday and the process if far more difficult than it seems.

Technically speaking, the entire system isn't hanging when the GPU crashes. The apparent system lockup stems from Xorg's event queue being frozen, therefore the system appears unresponsive. Moreover, the GPU is locked up so you couldn't redraw even if the event queue was being processed. However, you should still be able to access the machine through SSH/serial console. The underlying kernel is still alive and well, it's just the user-facing side of things which crashes.
Comment 56 Eric Donkersloot 2009-02-05 10:40:43 EST
> Technically speaking, the entire system isn't hanging when the GPU crashes. The
> apparent system lockup stems from Xorg's event queue being frozen, therefore
> the system appears unresponsive. Moreover, the GPU is locked up so you couldn't
> redraw even if the event queue was being processed. However, you should still
> be able to access the machine through SSH/serial console. The underlying kernel
> is still alive and well, it's just the user-facing side of things which
> crashes.

So how does this relate to compiz ? I only experience the Xorg crash when compiz is enabled, not when it is disabled. The only annoying (random) bug I come across when compiz is disabled is a lower resolution display after my laptop is waking up from suspend or hibernation.
Comment 57 Ben Gamari 2009-02-05 10:51:15 EST
(In reply to comment #56)
> So how does this relate to compiz ? I only experience the Xorg crash when
> compiz is enabled, not when it is disabled.

This probably means that there's an issue with the 3d implementation. Without compiz, you are only using 2d acceleration provided by the ddx (xorg driver). Compiz on the other hand uses the OpenGL implementation provided by mesa.

> The only annoying (random) bug I
> come across when compiz is disabled is a lower resolution display after my
> laptop is waking up from suspend or hibernation.
That's really odd, open a new bug for this. Can you revert to the correct resolution with xrandr?
Comment 58 Eric Donkersloot 2009-02-05 11:02:33 EST
> That's really odd, open a new bug for this. Can you revert to the correct
> resolution with xrandr?

Haven't tried that, restarting gdm didn't help in any case. Will create a bug report for it next time it happens again.

FYI, the xorg crash bug is not present when I use Mandriva 2009.0 on this laptop (x11-driver-video-intel-2.4.2-7.4mdv2009.0.i586.rpm & x11-server-1.4.2-10.1mdv2009.0.i586.rpm)
Comment 59 Tomasz Torcz 2009-02-05 11:43:45 EST
> > The only annoying (random) bug I
> > come across when compiz is disabled is a lower resolution display after my
> > laptop is waking up from suspend or hibernation.
> That's really odd, open a new bug for this. Can you revert to the correct
> resolution with xrandr?

I'm experiencing it too. Somehow VGA output gets enabled with some low resolution, like 1024x768. Disabling it with xrandr and switching LVDS to "preferred" gives 1440x900 back. But I believe this bug is totally different than queue freezing.
BTW, none of the input works, but I can still move mouse cursor when it happens. Clicks aren't registered.
Comment 61 Marko Vojinovic 2009-02-06 11:59:46 EST
(In reply to comment #59)
> BTW, none of the input works, but I can still move mouse cursor when it
> happens. Clicks aren't registered.

In my case this manifests as follows: with compiz enabled, X locks up along with the keyboard, while mouse pointer is movable (clicks are not registred). With compiz disabled, X locks up so that even mouse pointer does not move.

In both cases I can ssh remotely into the machine and verify that it works, read logs and all...
Comment 62 Dave Russell 2009-03-12 06:06:36 EDT
Compiz disabled, completely up to date F10, mouse continues to move but X frozen.

00:02.0 VGA compatible controller: Intel Corporation 82G33/G31 Express Integrated Graphics Controller (rev 10)

No xorg.conf

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

Backtrace:
0: /usr/bin/X(xorg_backtrace+0x3b) [0x812bd6b]
1: /usr/bin/X(mieqEnqueue+0x289) [0x810b469]
2: /usr/bin/X(xf86PostMotionEventP+0xc2) [0x80d4262]
3: /usr/bin/X(xf86PostMotionEvent+0x68) [0x80d43c8]
4: /usr/lib/xorg/modules/input//evdev_drv.so [0x129d25]
5: /usr/bin/X [0x80bcdb7]
6: /usr/bin/X [0x80ac91e]
7: [0xe8d400]
8: [0xe8d416]
9: /lib/libc.so.6(ioctl+0x19) [0xb47979]
10: /usr/lib/libdrm.so.2 [0x3ad06cf]
11: /usr/lib/libdrm.so.2(drmCommandWrite+0x34) [0x3ad0984]
12: /usr/lib/xorg/modules/drivers//intel_drv.so(I830Sync+0x135) [0x160ca5]
13: /usr/lib/xorg/modules/drivers//intel_drv.so [0x18a97a]
14: /usr/lib/xorg/modules//libexa.so(exaWaitSync+0x65) [0x11a095]
15: /usr/lib/xorg/modules//libexa.so(ExaDoPrepareAccess+0x7e) [0x11b3ae]
16: /usr/lib/xorg/modules//libexa.so [0x1203b2]
17: /usr/lib/xorg/modules//libexa.so [0x120905]
18: /usr/lib/xorg/modules//libexa.so(exaDoMigration+0x652) [0x1210c2]
19: /usr/lib/xorg/modules//libexa.so [0x12274b]
20: /usr/lib/xorg/modules//libexa.so(exaComposite+0xd5a) [0x12392a]
21: /usr/bin/X [0x816f75a]
22: /usr/bin/X(CompositePicture+0x19a) [0x81581ea]
23: /usr/lib/xorg/modules//libexa.so(exaTrapezoids+0x3ea) [0x1223da]
24: /usr/bin/X(CompositeTrapezoids+0x9b) [0x8157fbb]
25: /usr/bin/X [0x816059d]
26: /usr/bin/X [0x815add5]
27: /usr/bin/X(Dispatch+0x34f) [0x8085e9f]
28: /usr/bin/X(main+0x47d) [0x806b71d]
29: /lib/libc.so.6(__libc_start_main+0xe5) [0xa826e5]
30: /usr/bin/X [0x806ab01]
[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.
[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.
[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.
[mi] EQ overflowing. The server is probably stuck in an infinite loop.
[mi] mieqEnequeue: out-of-order valuator event; dropping.
Comment 63 Dave Russell 2009-03-12 06:10:39 EDT
Created attachment 334912 [details]
Recently hit this, with fully up to date xorg packages

Recently hit this, with fully up to date xorg packages as shown below.

xorg-x11-drv-i810-2.5.0-4.fc10.i386
xorg-x11-server-Xorg-1.5.3-13.fc10.i386
Comment 64 Richard Haakma 2009-03-13 23:22:35 EDT
Hi.  I also get this lockup about once a week.  It mostly occurs when moving a card in Freecell Solitaire, though it has happened once while not running that.  It was scrolling in Firefox I think.

I have an Asus P5KPL-CM motherboard with G31 onboard graphics.  Desktop Effects (Compiz) is OFF.  Compiz/3D messes up the sound anyway so I have it off.

Fedora 10 all up to date as of Mar 12 2009

Kernel 2.6.27.19-170.2.35.fc10.i686 and all kernels since F 10.
xorg-x11-server-Xorg-1.5.3-13.fc10.i386
xorg-x11-drv-i810-2.5.0-4.fc10.i386

Backtrace:
0: /usr/bin/Xorg(xorg_backtrace+0x3b) [0x812bc5b]
1: /usr/bin/Xorg(mieqEnqueue+0x289) [0x810b379]
2: /usr/bin/Xorg(xf86PostMotionEventP+0xc2) [0x80d4262]
3: /usr/bin/Xorg(xf86PostMotionEvent+0x68) [0x80d43c8]
4: /usr/lib/xorg/modules/input//evdev_drv.so [0x30fd05]
5: /usr/bin/Xorg [0x80bcdb7]
6: /usr/bin/Xorg [0x80ac91e]
7: [0x110400]
8: [0x110416]
9: /lib/libc.so.6(ioctl+0x19) [0xb90979]
10: /usr/lib/libdrm.so.2 [0x5ace6cf]
11: /usr/lib/libdrm.so.2(drmCommandWrite+0x34) [0x5ace984]
12: /usr/lib/xorg/modules/drivers//intel_drv.so(I830Sync+0x135) [0x1c6ca5]
13: /usr/lib/xorg/modules/drivers//intel_drv.so [0x1f097a]
14: /usr/lib/xorg/modules//libexa.so(exaWaitSync+0x65) [0x26b095]
15: /usr/lib/xorg/modules//libexa.so(ExaDoPrepareAccess+0x7e) [0x26c3ae]
16: /usr/lib/xorg/modules//libexa.so [0x2713b2]
17: /usr/lib/xorg/modules//libexa.so [0x271905]
18: /usr/lib/xorg/modules//libexa.so(exaDoMigration+0x652) [0x2720c2]
19: /usr/lib/xorg/modules//libexa.so [0x27374b]
20: /usr/lib/xorg/modules//libexa.so(exaComposite+0xd5a) [0x27492a]
21: /usr/bin/Xorg [0x816f6fa]
22: /usr/bin/Xorg(CompositePicture+0x19a) [0x815818a]
23: /usr/bin/Xorg [0x815e055]
24: /usr/bin/Xorg [0x815ad75]
25: /usr/bin/Xorg(Dispatch+0x34f) [0x8085e9f]
26: /usr/bin/Xorg(main+0x47d) [0x806b71d]
27: /lib/libc.so.6(__libc_start_main+0xe5) [0xacb6e5]
28: /usr/bin/Xorg [0x806ab01]

Backtrace:
0: /usr/bin/Xorg(xorg_backtrace+0x3b) [0x812bc5b]
1: /usr/bin/Xorg(mieqEnqueue+0x289) [0x810b379]
2: /usr/bin/Xorg(xf86PostMotionEventP+0xc2) [0x80d4262]
3: /usr/bin/Xorg(xf86PostMotionEvent+0x68) [0x80d43c8]
4: /usr/lib/xorg/modules/input//evdev_drv.so [0x7a3d25]
5: /usr/bin/Xorg [0x80bcdb7]
6: /usr/bin/Xorg [0x80ac91e]
7: [0x1d8400]
8: [0x1d8416]
9: /lib/libc.so.6(ioctl+0x19) [0xb90979]
10: /usr/lib/libdrm.so.2 [0x5ace6cf]
11: /usr/lib/libdrm.so.2(drmCommandWrite+0x34) [0x5ace984]
12: /usr/lib/xorg/modules/drivers//intel_drv.so(I830Sync+0x135) [0x124ca5]
13: /usr/lib/xorg/modules/drivers//intel_drv.so [0x14e97a]
14: /usr/lib/xorg/modules//libexa.so(exaWaitSync+0x65) [0x45e095]
15: /usr/lib/xorg/modules//libexa.so(ExaDoPrepareAccess+0x7e) [0x45f3ae]
16: /usr/lib/xorg/modules//libexa.so [0x4643b2]
17: /usr/lib/xorg/modules//libexa.so [0x464905]
18: /usr/lib/xorg/modules//libexa.so(exaDoMigration+0x652) [0x4650c2]
19: /usr/lib/xorg/modules//libexa.so [0x46674b]
20: /usr/lib/xorg/modules//libexa.so(exaComposite+0xd5a) [0x46792a]
21: /usr/bin/Xorg [0x816f6fa]
22: /usr/bin/Xorg(CompositePicture+0x19a) [0x815818a]
23: /usr/bin/Xorg [0x815e055]
24: /usr/bin/Xorg [0x815ad75]
25: /usr/bin/Xorg(Dispatch+0x34f) [0x8085e9f]
26: /usr/bin/Xorg(main+0x47d) [0x806b71d]
27: /lib/libc.so.6(__libc_start_main+0xe5) [0xacb6e5]
28: /usr/bin/Xorg [0x806ab01]


Backtrace:
0: /usr/bin/Xorg(xorg_backtrace+0x3b) [0x812bd6b]
1: /usr/bin/Xorg(mieqEnqueue+0x289) [0x810b469]
2: /usr/bin/Xorg(xf86PostMotionEventP+0xc2) [0x80d4262]
3: /usr/bin/Xorg(xf86PostMotionEvent+0x68) [0x80d43c8]
4: /usr/lib/xorg/modules/input//evdev_drv.so [0x252d25]
5: /usr/bin/Xorg [0x80bcdb7]
6: /usr/bin/Xorg [0x80ac91e]
7: [0xd13400]
8: [0xd13416]
9: /lib/libc.so.6(ioctl+0x19) [0xb90979]
10: /usr/lib/libdrm.so.2 [0x5ace6cf]
11: /usr/lib/libdrm.so.2(drmCommandWrite+0x34) [0x5ace984]
12: /usr/lib/xorg/modules/drivers//intel_drv.so(I830Sync+0x135) [0x197ca5]
13: /usr/lib/xorg/modules/drivers//intel_drv.so [0x1c197a]
14: /usr/lib/xorg/modules//libexa.so(exaWaitSync+0x65) [0x504095]
15: /usr/lib/xorg/modules//libexa.so(ExaDoPrepareAccess+0x7e) [0x5053ae]
16: /usr/lib/xorg/modules//libexa.so [0x50a3b2]
17: /usr/lib/xorg/modules//libexa.so [0x50a905]
18: /usr/lib/xorg/modules//libexa.so(exaDoMigration+0x652) [0x50b0c2]
19: /usr/lib/xorg/modules//libexa.so(exaCopyNtoN+0x3f1) [0x507fd1]
20: /usr/lib/xorg/modules//libfb.so(fbCopyRegion+0x1d6) [0x2157f6]
21: /usr/lib/xorg/modules//libfb.so(fbDoCopy+0x4a3) [0x215dd3]
22: /usr/lib/xorg/modules//libexa.so(exaCopyArea+0x9a) [0x507b8a]
23: /usr/bin/Xorg [0x81717f2]
24: /usr/bin/Xorg(ProcCopyArea+0x169) [0x8084179]
25: /usr/bin/Xorg(Dispatch+0x34f) [0x8085e9f]
26: /usr/bin/Xorg(main+0x47d) [0x806b71d]
27: /lib/libc.so.6(__libc_start_main+0xe5) [0xacb6e5]
28: /usr/bin/Xorg [0x806ab01]
Comment 65 Marko Vojinovic 2009-03-14 07:26:57 EDT
I tend to have lockups on a daily basis (2 or 3 times a day), and can provide a whole bunch of these backtraces, if quantity is useful to anyone. Just ask for it!

On the other hand, I have a feeling that nothing is being done about this bug for some time, and it seems that lack of backtraces is not the problem.

Would any developer/maintainer care to share with us what is the current situation, problems, etc., regarding this? I would just like to have some insight into what is going on and how hard is it to make a fix for this bug?

Best, :-)
Marko
Comment 66 Eric Donkersloot 2009-03-16 08:56:21 EDT
Looks like adding this option to xorg.conf solved the issue, I have been using
my laptop with compiz enabled for hours now, without a crash:

Option    "ExaNoComposite"  "on"

Will continue to test with this option enabled.
Comment 67 Eric Donkersloot 2009-03-16 08:57:37 EDT
*** Bug 477859 has been marked as a duplicate of this bug. ***
Comment 68 Jarod Wilson 2009-03-16 09:23:51 EDT
Semi-interestingly, I believe I've just witnessed more or less the same thing (very similar backtrace, same type of log contents and results) on a box with a radeon video card...

[...Xorg.0.log snippet...]
[mi] EQ overflowing. The server is probably stuck in an infinite loop.

Backtrace:
0: /usr/bin/Xorg(xorg_backtrace+0x26) [0x4e7b66]
1: /usr/bin/Xorg(mieqEnqueue+0x291) [0x4c86a1]
2: /usr/bin/Xorg(xf86PostMotionEventP+0xc4) [0x490e94]
3: /usr/bin/Xorg(xf86PostMotionEvent+0xa9) [0x491069]
4: /usr/lib64/xorg/modules/input//evdev_drv.so [0x34b7472]
5: /usr/bin/Xorg [0x47d745]
6: /usr/bin/Xorg [0x4691f7]
7: /lib64/libc.so.6 [0x3fb0e32f90]
8: /lib64/libc.so.6(ioctl+0x7) [0x3fb0ede037]
9: /usr/lib64/libdrm.so.2 [0x3fc9a03023]
10: /usr/lib64/libdrm.so.2(drmWaitVBlank+0x20) [0x3fc9a036c0]
11: /usr/lib64/dri/r300_dri.so [0x23d2efe]
12: /usr/lib64/dri/r300_dri.so(driWaitForVBlank+0xcb) [0x23d30ff]
13: /usr/lib64/dri/r300_dri.so(radeonCopyBuffer+0x108) [0x23d8219]
14: /usr/lib64/dri/r300_dri.so [0x23d3242]
15: /usr/lib64/xorg/modules/extensions//libglx.so [0xa027ff]
16: /usr/lib64/xorg/modules/extensions//libglx.so [0x9f6656]
17: /usr/lib64/xorg/modules/extensions//libglx.so [0x9f98f2]
18: /usr/bin/Xorg(Dispatch+0x364) [0x4468d4]
19: /usr/bin/Xorg(main+0x45d) [0x42cd1d]
20: /lib64/libc.so.6(__libc_start_main+0xe6) [0x3fb0e1e576]
21: /usr/bin/Xorg [0x42c0f9]
[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.
[mi] EQ overflowing. The server is probably stuck in an infinite loop.
Comment 69 Eric Donkersloot 2009-03-16 10:53:17 EDT
Please disregard my previous comment, I just expercienced another crash.
Comment 70 Matías Kreder 2009-03-16 17:56:08 EDT
personally, i'm not having this bug anymore adding this line to xorg.conf:

	Option      "AccelMethod" "XAA"

But i have some others problems when i try to play videos with totem, vlc, etc.
Comment 71 Orion Poplawski 2009-03-18 10:41:55 EDT
(**) intel(0): Option "AccelMethod" "XAA"

Doesn't help me (with nomodeset + NoDRI as well):

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

(no out-of-order message)

00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)
Comment 72 Marek Greško 2009-03-20 10:21:53 EDT
I also experience this problem when logging out from kde.

Setting Option "Tiling" "False" I get locks also, but not after every logout.
Comment 73 Eric Donkersloot 2009-04-16 11:20:29 EDT
Looks like the xorg server no longer crashes using the 2.6.29.1-30 kernel from updates-testing.
Resume from suspend is still not working properly when compiz is enabled, but
that is probably related to another bug.

Also, the number of frames rendered by glxgears has diminished with 50%.
I know glxgears is not a proper benchmark, but I used to have ~1200 FPS using
the latest 2.6.27 kernel and I currently have about ~650 FPS.
Comment 74 Björn Ruberg 2009-04-19 06:12:44 EDT
For me this is not solved with kernel 2.6.29. Still having these hangs.
I opened up a bugreport upstream. One of the devs suggested a way to debug that error. 
I'll try that now. You can, too.
See: https://bugs.freedesktop.org/show_bug.cgi?id=20893#c4
Comment 75 pankaj pandey 2009-04-20 04:43:35 EDT
Did you try the updated intel drivers. I installed the rpm from http://fedorapeople.org/~knol/rpms/xorg-x11-drv-i810/ and never had a lockup since (its been a few days). Earlier my laptop couldn't stand 15 mins with compiz enabled. As mentioned by Eric Donkersloot (c #73) the 2.6.29.1-30 kernel has problems in suspend/resume so i've reverted back to 2.6.27 and have not yet experienced a lockup with the new xorg drivers.
Comment 76 Eric Donkersloot 2009-04-20 05:11:33 EDT
(In reply to comment #75)
> Did you try the updated intel drivers. I installed the rpm from
> http://fedorapeople.org/~knol/rpms/xorg-x11-drv-i810/ and never had a lockup
> since (its been a few days). Earlier my laptop couldn't stand 15 mins with
> compiz enabled. As mentioned by Eric Donkersloot (c #73) the 2.6.29.1-30 kernel
> has problems in suspend/resume so i've reverted back to 2.6.27 and have not yet
> experienced a lockup with the new xorg drivers. n

Unfortunately, I cannot compile that driver for x86_64:

i830_dri.c:1162: error: ‘drm_i915_flip_t’ undeclared (first use in this function)
i830_dri.c:1162: error: (Each undeclared identifier is reported only once
i830_dri.c:1162: error: for each function it appears in.)
i830_dri.c:1162: error: expected ‘;’ before ‘flip’
i830_dri.c:1168: error: ‘flip’ undeclared (first use in this function)
make[4]: *** [i830_dri.lo] Error 1
make[4]: Leaving directory `/home/ericd/rpmbuild/BUILD/xf86-video-intel-2.5.1/src'
Comment 77 Björn Ruberg 2009-04-21 19:48:24 EDT
That drivers are outdated. It has been already reported that the bug has been implemented somewhere in the 2.5 line. So it may well be that is not yet in that driver. However, using an older driver is no real solution. This must be fixed in the future.

Perhaps you can try later 2.5 version of the kernel. If you can find out what version exactly introduced the problem, that might be a help for the intel developers.
Comment 78 Björn Ruberg 2009-04-27 13:02:20 EDT
Can someone still reproduce this on Fedora11 with 2.7 drivers?
Comment 80 Jithin Emmanuel 2009-04-29 06:33:15 EDT
Is this bug fixed in fedora 11 preview release. I could not find any info regarding these in the release notes.
Comment 81 Björn Ruberg 2009-04-29 11:11:16 EDT
It looks as if this is fixed in fedora 11 now by using the 2.7 intel driver an UXA-acceleration.
In that combination I had no freeze in three days of using together with compiz.

When I used EXA instead of UXA it freezed after one hour. 

Can someone confirm my observation?
Comment 82 Jithin Emmanuel 2009-04-29 11:48:27 EDT
Is that the default setup in fedora 11 or do we have to install or setup anything new.
Comment 83 Björn Ruberg 2009-04-29 12:19:00 EDT
It's the default setup since one week I think. To be sure look in your /var/log/Xorg.0.log and search for uxa.
Comment 84 Björn Ruberg 2009-04-29 18:37:53 EDT
I have to correct myself. Fedora 11 still freezes. But not as often as before. It freezes quite fast when playing videos using the XV-extension. 

Situation will probably get better with newer drivers. 2.8 is not far away.
Comment 85 Jithin Emmanuel 2009-05-01 22:43:46 EDT
Do does that means that until 2.8 is released this problem will exist. Funny. Very Funny.
Comment 86 Jithin Emmanuel 2009-05-05 21:41:28 EDT
Is there any update on this bug? or will fedora 11 be released with with one like how ubuntu screwed users with intel.
Comment 87 Björn Ruberg 2009-05-06 03:11:49 EDT
Well, it's not that but. Fedora 11 freezes significantly more rare. Didn't have a free for three days now. In Fedora 10 there were three per day.
Comment 88 Jithin Emmanuel 2009-05-06 03:48:53 EDT
@Bjorn . For 3 days with normal use and no freeze means its fixed right? . Can this be confirmed by any fedora devs?
Comment 89 Björn Ruberg 2009-05-06 04:08:30 EDT
It's definetly NOT fixed.(I had a freeze on Fedora 11 just three days ago. There was no relevant software update between) It's just better.
Comment 90 Tom "spot" Callaway 2009-05-06 08:28:28 EDT
Guys, I'm not an X developer, but keep this in mind:

The error message that this bug is centered around is a sortof catchall error that the driver throws when it gets into a bad state. It is probable that a lot of your X driver problems are unique. This "superbug" isn't really resolvable in its current state. If you're seeing an X crash on Fedora 10 or 11, I would strongly encourage you to open a new bugzilla ticket and be sure to include your xorg.conf (if you're using one) and a copy of the Xorg.#.log file showing the startup and crash.
Comment 91 David Crowe 2009-05-06 11:16:50 EDT
(In reply to comment #90)
> Guys, I'm not an X developer, but keep this in mind:
> 
> The error message that this bug is centered around is a sortof catchall error
> that the driver throws when it gets into a bad state. It is probable that a lot
> of your X driver problems are unique. This "superbug" isn't really resolvable
> in its current state. If you're seeing an X crash on Fedora 10 or 11, I would
> strongly encourage you to open a new bugzilla ticket and be sure to include
> your xorg.conf (if you're using one) and a copy of the Xorg.#.log file showing
> the startup and crash.  

one of the problems here is we aren't getting _ANY_ developer support.  since the bug switched from a blocker for F10 by jkeating in comment #25 there has been exactly zero developer help.  there has been plenty of Xorg.*.log files and helpful stabs in the dark from users - but, again, zero help from the developers.

any chance we can get some attention to this?  as i and many other users have reported - this is extremely debilitating when it happens and its random.
Comment 92 Ben Gamari 2009-05-06 11:41:27 EDT
As has been mentioned before, "EQ overflowing" message is a generic symptom of the xserver being stuck while blocking. Generally this is caused by a bug in the intel driver which causes the GPU to crash. It is probably that this bug report is in fact describing multiple bugs, which immediately makes things much harder to debug. Moreover, the infrastructure for debugging these sorts of failures has only been introduced into the mainline kernel very recently. I think now, however, we should finally have batchbuffer dumping in fedora kernels.

If you are affected by this bug, you need to install intel_gpu_tools (it seems to be packaged at this point) and collect GPU ring/batch-buffer dump whenever the machine crashes. You then need to open a bug at bugs.freedesktop.org under the xorg intel driver component. The bug's title take the form of "[$HW GEM KMS] $DESCRIPTION on xf86-video-intel-$VER" where $HW is the type of GPU you are running on (GM965, 945, 855, etc). Be sure to attach the GPU dump you collected, xorg.log, and dmesg output to the bug. I'm not sure why no one has mentioned intell_gpu_dump yet, but it's a very useful tool for tracking down these issues.

This is the only way I can see this bug being resolved. Keeping this sort of report in Redhat's bugzilla just doesn't make any sense, it's definitely an intel issue. That being said, it could take a while to get this fixed. These sorts of bugs are extremely difficult to track down, even with a GPU dump.

If you are feeling adventurous, you might also want to consider running the DDX (and perhaps kernel) from git for a while. This is what I do and I've seen very few crashes recently. However, consider this if and _only_ if you are willing to debug and contribute.

Hopefully this helps. Feel free to reference any bugs you open on this bug but further discussion here isn't going to help anyone. If anything, this bug should be turned into a tracker.
Comment 94 Will Woods 2009-05-06 12:04:27 EDT
There's already a tracker bug for this: bug 465884 (aka eq-overflow).

If you really want to get developer attention and get your problem(s) fixed, please follow Ben's instructions.

intel-gpu-tools has indeed been packaged for Rawhide/F11. Not sure if it's possible or useful to package it for F10.

Here's a convenient link to start filing an Xorg intel driver bug on freedesktop bugzilla:
https://bugs.freedesktop.org/enter_bug.cgi?product=xorg&component=Driver/intel
Comment 95 David Crowe 2009-05-06 12:12:46 EDT

thanks ben and will.  that gives us a much more productive way to go forward.

it would be very useful for the short term to have intel-gpu-tools packaged for F10 - for me at least.

i understand it can be difficult to track down but we didn't even have a
starting point to gather and send in useful information until now.  much
appreciated.
Comment 96 Ben Gamari 2009-05-06 18:12:40 EDT
(In reply to comment #95)
> 
> thanks ben and will.  that gives us a much more productive way to go forward.
> 
Any time!

> it would be very useful for the short term to have intel-gpu-tools packaged for
> F10 - for me at least.
>
The problem with this is that the F10 kernels don't have the necessary support for batch buffer dumping. Personally, I wouldn't hold out too much hope for fixing these issues on F10. There has been a lot of flux in the graphics output stack recently and trying to backport these changes wouldn't be a particularly productive use of developer time. It would be most helpful if people would work with more recent code.
Comment 97 David Crowe 2009-05-06 18:41:11 EDT
ok - i'll need to wait until i can put enough time into this after F11 ships.  at least we have a way to help move this forward.

thanks again.
Comment 98 Matías Kreder 2009-05-26 18:25:28 EDT
I'm having good luck with this workaround, I'd like that someone test it and
confirm if it works or not. I'm running kernel 2.6.29.2-52.fc10.i686 from koji.

http://koji.fedoraproject.org/koji/buildinfo?buildID=99901

Could you please let me know if it works with this kernel? or I am just
experiencing lucky. 

please, let me know any news on this.
Comment 99 Vedran Miletić 2009-09-06 04:45:40 EDT
Updating version to Fedora 11 per comments.
Comment 100 Vedran Miletić 2009-09-06 05:23:02 EDT
*** Bug 470094 has been marked as a duplicate of this bug. ***
Comment 101 Vedran Miletić 2009-09-06 05:24:53 EDT
*** Bug 501256 has been marked as a duplicate of this bug. ***
Comment 102 Vedran Miletić 2009-09-06 05:25:15 EDT
*** Bug 506871 has been marked as a duplicate of this bug. ***
Comment 103 Vedran Miletić 2009-09-06 05:25:51 EDT
*** Bug 513245 has been marked as a duplicate of this bug. ***
Comment 104 Vedran Miletić 2009-09-06 05:26:09 EDT
*** Bug 520274 has been marked as a duplicate of this bug. ***
Comment 105 Vedran Miletić 2009-09-06 05:28:06 EDT
*** Bug 454069 has been marked as a duplicate of this bug. ***
Comment 106 Vedran Miletić 2009-09-06 05:29:14 EDT
*** Bug 472935 has been marked as a duplicate of this bug. ***
Comment 107 Vedran Miletić 2009-09-06 05:29:48 EDT
*** Bug 473195 has been marked as a duplicate of this bug. ***
Comment 108 Matěj Cepl 2009-11-05 13:19:58 EST
Since this bugzilla report was filed, there have been several major updates in various components of the Xorg system, which may have resolved this issue. Users who have experienced this problem are encouraged to upgrade their system to the latest version of their packages. For packages from updates-testing repository you can use command

yum upgrade --enablerepo='*-updates-testing'

Alternatively, you can also try to test whether this bug is reproducible with the upcoming Fedora 12 distribution by downloading LiveMedia of F12 Beta available at http://alt.fedoraproject.org/pub/alt/nightly-composes/ . By using that you get all the latest packages without need to install anything on your computer. For more information on using LiveMedia take a look at https://fedoraproject.org/wiki/FedoraLiveCD .

Please, if you experience this problem on the up-to-date system, let us now in the comment for this bug, or whether the upgraded system works for you.

If you won't be able to reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you.

[This is a bulk message for all open Fedora Rawhide Xorg-related bugs. I'm adding myself to the CC list for each bug, so I'll see any comments you make after this and do my best to make sure every issue gets proper attention.]
Comment 109 Thomas Fitzsimmons 2009-11-05 15:05:07 EST
I haven't seen this for a while on F11.  I'll keep an eye on it when I upgrade to F12.
Comment 110 Tim Lauridsen 2009-11-06 01:15:38 EST
I have not seen this in F12 Beta updated to current rawhide.
Comment 111 Derrick 2009-11-20 12:54:28 EST
I have just upgraded from F11 hoping this would be fixed in 12 but it got worse... In 11 my X was stable so long as I didn't use compiz. Now it just randomly locks up and forces remote login to reboot.

lspci gives:


00:00.0 Host bridge: Intel Corporation 82845G/GL[Brookdale-G]/GE/PE DRAM Controller/Host-Hub Interface (rev 01)
00:02.0 VGA compatible controller: Intel Corporation 82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device (rev 01)
Comment 112 Derrick 2009-11-20 12:56:03 EST
Created attachment 372562 [details]
eq overflowing on fedora 12 xorg.log
Comment 113 Hideki Yoshida 2009-11-21 06:36:12 EST
Created attachment 372726 [details]
EQ Overflowing lockups with xorg-x11-drv-intel-2.9.1-1.fc12.i686

I am also having EQ Overflowing lockups withup xorg-x11-drv-intel-2.9.1-1.fc12.i686.
Remote login works.

00:00.0 Host bridge: Intel Corporation Mobile 915GM/PM/GMS/910GML Express Proces
sor to DRAM Controller (rev 03)
00:02.0 VGA compatible controller: Intel Corporation Mobile 915GM/GMS/910GML Exp
ress Graphics Controller (rev 03)
Comment 114 Marko Vojinovic 2009-11-24 09:42:55 EST
I have installed the final release of Fedora 12, and have not seen any of this bug for a couple of days now. It appears fixed, at least for Intel GM965. Everything related to graphics works as expected, 2D, 3D, UXA acceleration, Compiz and all, etc. Zero problems.

I have to say that I am very happy that this long-standing issue is (apparently) resolved. Big thanks to everyone! :-)

Best, :-)
Marko
Comment 115 Richard Schwarting 2009-11-25 23:03:05 EST
Created attachment 373909 [details]
Xorg.0.log from IBM Thinkpad x41t with intel 915GM

Hi.  I no longer had this bug during most of Fedora 11, but now that I've upgraded to Fedora 12, I get it at least once a day.

Particulars:
* IBM Thinkpad x41t tablet
* Intel 915GM 
* using dual head with a second monitor in such a way that disables Xv (resolution too large? bug 538727)
* compiz disabled (doesn't work anyway due to 538727)

I'm happy to try to try to attach GDB to X when it next freezes and look for something if that'll help.
Comment 116 Vedran Miletić 2009-11-26 08:52:21 EST
It seems this bug is present for some (but not all) in Fedora 12.
Comment 117 Danny Yee 2009-11-26 19:47:03 EST
Has anyone experiencing this problem with Fedora 11 and an Intel G45/G43 chipset done the upgrade to Fedora 12?  (In my case, onboard video on an Asus P5Q-VM motherboard.)

I don't really want to upgrade my main desktop and have this problem get any worse!
Comment 118 Vedran Miletić 2009-11-27 02:41:45 EST
I have P5QL-EM, and have had problems with it in Fedora 11. On the other hand, Fedora 12 works nice.
Comment 119 Richard Guest 2009-11-27 16:14:42 EST
Yeah...

FWIW since upgrading to F12, my Dell Latitude E4300 with intel GM45 chipset, I haven't seen this problem.
Comment 120 Vedran Miletić 2009-11-27 16:31:08 EST
So, let's try to make a summary here what is fixed:
Tim Lauridsen has 945GM and has no issue, but used to have it.
Me and Marko Vojnović have GM965 and have no issue in Fedora 12; I don't even remember having it in Fedora 11 either.
I also have G43 at work and it works with Fedora 12 (but it certainly *did* break with Fedora 11 at some point).

Outstanding:
Derick has 845G and it got worse with Fedora 12.
Richard Schwarting and Hideki Yoshida have 915GM that has issue with Fedora 12.

Guys, any other mobile/desktop chipsets? 815? 830? 865? G31/G33?
Comment 121 Vedran Miletić 2009-11-27 16:43:43 EST
I just marked all atachments related to previous versions of Fedora as obsolete, due to many changes in X.Org stack in latest Fedora.

I apologize for bugmail it created.

Logs from Fedora 12 are welcome.
Comment 122 Danny Yee 2009-12-05 17:44:19 EST
Ok, upgrading to Fedora 12 seems to have fixed the problem for me.  That's with the onboard video on an ASUS P5Q-VM motherboard - "Intel G45/G43 Chipset" - driving a 1920x1200 monitor through VGA.
Comment 123 p.johns 2009-12-07 00:22:33 EST
same as Comment #111 From Derrick for me, worse in f12
f11 was stable with following in xorg.conf

	Identifier  "Videocard0"
	Driver      "intel"
	Option      "AccelMethod" "EXA"  
	Option      "MigrationHeuristic" "greedy"
	Option      "Tiling" "False"

as long as I didn't use compiz.

one improvement over f11, f12 doesn't need "Tiling" "False" option to stop 'tearing'

am attaching Xorg.0.log.old from after freeze.
the following is an excerpt from /var/log/messages during graphics freeze. it is repeated every 2 or 4 minutes.

	Dec  4 18:22:40 localhost kernel: INFO: task i915/0:108 blocked for more than 120 seconds.
	Dec  4 18:22:40 localhost kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
	Dec  4 18:22:40 localhost kernel: i915/0        D f65bb598     0   108      2 0x00000000
	Dec  4 18:22:40 localhost kernel: f65dbf14 00000046 fecf6973 f65bb598 c09ef6ec c09f4120 f65bb598 f65dbee0
	Dec  4 18:22:40 localhost kernel: c09f4120 c09f4120 c09f4120 000d2fb2 f65dbf0c 00000000 d2cfff97 0000010e
	Dec  4 18:22:40 localhost kernel: c1d8f120 f65bb300 00000000 f65dbf18 c0430cc4 00000000 f649f014 f65bb300
	Dec  4 18:22:40 localhost kernel: Call Trace:
	Dec  4 18:22:40 localhost kernel: [<c0430cc4>] ? finish_task_switch+0xa4/0xbf
	Dec  4 18:22:40 localhost kernel: [<c07655f8>] __mutex_lock_common+0xde/0x12d
	Dec  4 18:22:40 localhost kernel: [<c076565e>] __mutex_lock_slowpath+0x17/0x1a
	Dec  4 18:22:40 localhost kernel: [<c0765747>] ? mutex_lock+0x2e/0x3c
	Dec  4 18:22:40 localhost kernel: [<c0765747>] mutex_lock+0x2e/0x3c
	Dec  4 18:22:40 localhost kernel: [<f7d91c35>] i915_gem_retire_work_handler+0x29/0x66 [i915]
	Dec  4 18:22:40 localhost kernel: [<c0446238>] worker_thread+0x13c/0x1bc
	Dec  4 18:22:40 localhost kernel: [<f7d91c0c>] ? i915_gem_retire_work_handler+0x0/0x66 [i915]
	Dec  4 18:22:40 localhost kernel: [<c0449be1>] ? autoremove_wake_function+0x0/0x34
	Dec  4 18:22:40 localhost kernel: [<c04460fc>] ? worker_thread+0x0/0x1bc
	Dec  4 18:22:40 localhost kernel: [<c0449937>] kthread+0x70/0x75
	Dec  4 18:22:40 localhost kernel: [<c04498c7>] ? kthread+0x0/0x75
	Dec  4 18:22:40 localhost kernel: [<c04041a7>] kernel_thread_helper+0x7/0x10
	Dec  4 18:24:40 localhost kernel: INFO: task i915/0:108 blocked for more than 120 seconds.
	Dec  4 18:24:40 localhost kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
	Dec  4 18:24:40 localhost kernel: i915/0        D f65bb598     0   108      2 0x00000000
	Dec  4 18:24:40 localhost kernel: f65dbf14 00000046 fecf6973 f65bb598 c09ef6ec c09f4120 f65bb598 f65dbee0
	Dec  4 18:24:40 localhost kernel: c09f4120 c09f4120 c09f4120 000d2fb2 f65dbf0c 00000000 d2cfff97 0000010e
	Dec  4 18:24:40 localhost kernel: c1d8f120 f65bb300 00000000 f65dbf18 c0430cc4 00000000 f649f014 f65bb300
	Dec  4 18:24:40 localhost kernel: Call Trace:
	Dec  4 18:24:40 localhost kernel: [<c0430cc4>] ? finish_task_switch+0xa4/0xbf
	Dec  4 18:24:40 localhost kernel: [<c07655f8>] __mutex_lock_common+0xde/0x12d
	Dec  4 18:24:40 localhost kernel: [<c076565e>] __mutex_lock_slowpath+0x17/0x1a
	Dec  4 18:24:40 localhost kernel: [<c0765747>] ? mutex_lock+0x2e/0x3c
	Dec  4 18:24:40 localhost kernel: [<c0765747>] mutex_lock+0x2e/0x3c
	Dec  4 18:24:40 localhost kernel: [<f7d91c35>] i915_gem_retire_work_handler+0x29/0x66 [i915]
	Dec  4 18:24:40 localhost kernel: [<c0446238>] worker_thread+0x13c/0x1bc
	Dec  4 18:24:40 localhost kernel: [<f7d91c0c>] ? i915_gem_retire_work_handler+0x0/0x66 [i915]
	Dec  4 18:24:40 localhost kernel: [<c0449be1>] ? autoremove_wake_function+0x0/0x34
	Dec  4 18:24:40 localhost kernel: [<c04460fc>] ? worker_thread+0x0/0x1bc
	Dec  4 18:24:40 localhost kernel: [<c0449937>] kthread+0x70/0x75
	Dec  4 18:24:40 localhost kernel: [<c04498c7>] ? kthread+0x0/0x75
	Dec  4 18:24:40 localhost kernel: [<c04041a7>] kernel_thread_helper+0x7/0x10

can ssh into machine but only way i can get display back is to reboot.

new Bug 539327 also describes same problem i see in f12
and Bug 538563

from lspci:
00:00.0 Host bridge: Intel Corporation 82845G/GL[Brookdale-G]/GE/PE DRAM Controller/Host-Hub Interface (rev 01)
00:02.0 VGA compatible controller: Intel Corporation 82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device (rev 01)
Comment 124 p.johns 2009-12-07 00:25:28 EST
Created attachment 376583 [details]
Xorg.0.log.old from after freeze in f12
Comment 125 Adam Williamson 2009-12-11 15:07:43 EST
This bug is a problem. The message "EQ overflowing. The server is probably stuck in an infinite loop." is a very generic error and can occur with many bugs that are not the same as each other. This has led to people reporting several completely different bugs into this report, and it's now very confused.

I'm going to close this report. Can anyone who still has live bugs involving this message please file a new report (or add on to another existing report if you're _sure_ it's the same problem)? Include your complete Xorg.0.log and any other appropriate info (see https://fedoraproject.org/wiki/How_to_debug_Xorg_problems ) and do _not_ mention the 'EQ overflowing' message itself in the bug's summary, or else we'll just end up with this situation again.

Apologies for the confusion, and thanks!

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Note You need to log in before you can comment on or make changes to this bug.