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.
Created attachment 318143 [details] xorg.conf Xorg.conf - nothing too interesting here. 'intel' driver, 24bpp.
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!
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...
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
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.
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.
*** Bug 465707 has been marked as a duplicate of this bug. ***
Created attachment 322796 [details] Xorg log file for X hang up after enabling destop effects on MacBook2
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.
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.
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
Forgot to tell that my system is running F9, upgraded to Rawhide
*** Bug 470422 has been marked as a duplicate of this bug. ***
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.
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.
Created attachment 323391 [details] My Xorg.0.log I am seeing this here as well... attaching my Xorg.0.log.old (after booting)
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
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.
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.
Created attachment 323687 [details] Xorg log file with EQ errors
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.
i happend again today :( $ uname -r 2.6.27.5-109.fc10.i686
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?
(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.
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.
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 :)
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
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
Created attachment 325112 [details] Xorg log file with EQ errors
This is still a problem for me. My X60s is still kind of useless with this breakage.
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
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.
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.
Created attachment 327555 [details] Xorg.0.log.old after from X lockup
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]
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.
Happens on my T61 w/intel x3100 too, but usually takes hours, if not days, before it hits.
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)
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?
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.
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.
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.)
(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?
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.
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
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/
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?
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?
(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.
(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.
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. ??
(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
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.
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.
(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.
> 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.
(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?
> 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)
> > 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.
(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...
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.
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
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]
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
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.
*** Bug 477859 has been marked as a duplicate of this bug. ***
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.
Please disregard my previous comment, I just expercienced another crash.
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.
(**) 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)
I also experience this problem when logging out from kde. Setting Option "Tiling" "False" I get locks also, but not after every logout.
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.
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
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.
(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'
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.
Can someone still reproduce this on Fedora11 with 2.7 drivers?
Is this bug fixed in fedora 11 preview release. I could not find any info regarding these in the release notes.
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?
Is that the default setup in fedora 11 or do we have to install or setup anything new.
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.
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.
Do does that means that until 2.8 is released this problem will exist. Funny. Very Funny.
Is there any update on this bug? or will fedora 11 be released with with one like how ubuntu screwed users with intel.
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.
@Bjorn . For 3 days with normal use and no freeze means its fixed right? . Can this be confirmed by any fedora devs?
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.
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.
(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.
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.
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
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.
(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.
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.
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.
Updating version to Fedora 11 per comments.
*** Bug 470094 has been marked as a duplicate of this bug. ***
*** Bug 501256 has been marked as a duplicate of this bug. ***
*** Bug 506871 has been marked as a duplicate of this bug. ***
*** Bug 513245 has been marked as a duplicate of this bug. ***
*** Bug 520274 has been marked as a duplicate of this bug. ***
*** Bug 454069 has been marked as a duplicate of this bug. ***
*** Bug 472935 has been marked as a duplicate of this bug. ***
*** Bug 473195 has been marked as a duplicate of this bug. ***
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.]
I haven't seen this for a while on F11. I'll keep an eye on it when I upgrade to F12.
I have not seen this in F12 Beta updated to current rawhide.
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)
Created attachment 372562 [details] eq overflowing on fedora 12 xorg.log
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)
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
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.
It seems this bug is present for some (but not all) in Fedora 12.
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!
I have P5QL-EM, and have had problems with it in Fedora 11. On the other hand, Fedora 12 works nice.
Yeah... FWIW since upgrading to F12, my Dell Latitude E4300 with intel GM45 chipset, I haven't seen this problem.
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?
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.
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.
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)
Created attachment 376583 [details] Xorg.0.log.old from after freeze in f12
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