I am running nvidia-drivers-180.37, xorg-server-1.5.3-r5 and KDE 4.2.1 on two systems. The first (Intel chipset, Intel HT CPU, AGP, nVidia 8xxx, single screen) is not affected. The second system is affected (nVidia chipset, Athlon64 X2 CPU, PCIe, nVidia 7xxx, nv-Twinview dual-screen with Xinerama). The system is affected independent of desktop effects, watching videos or idling. But it occurs more often if I scroll or switch windows. The bug is, that X suddenly freezes. Sometimes X freezes completely (mouse cursor freezes, too), sometimes the mouse cursor is still moveable (but cursor animation stopped) until I try to switch to console - that makes the cursor also freeze instead of switching to console. Usually I rebooted but today I discovered when leaving the system alone for 10 minutes or so it comes back to live. Here is what I extracted from the Xorg log and dmesg: [mi] EQ overflowing. The server is probably stuck in an infinite loop. Backtrace: 0: /usr/bin/X(xorg_backtrace+0x26) [0x4e0a76] 1: /usr/bin/X(mieqEnqueue+0x27b) [0x4c31db] 2: /usr/bin/X(xf86PostMotionEventP+0xf1) [0x48f741] 3: /usr/bin/X(xf86PostMotionEvent+0xc3) [0x48f8e3] 4: /usr/lib64/xorg/modules/input//evdev_drv.so [0x7f215ac1a48f] 5: /usr/bin/X [0x47a035] 6: /usr/bin/X [0x46b980] 7: /lib/libpthread.so.0 [0x7f2160871890] 8: /usr/lib64/xorg/modules/drivers//nvidia_drv.so(_nv001302X+0x3a6) [0x7f215be28ad6] 9: /usr/lib64/xorg/modules/drivers//nvidia_drv.so(_nv001783X+0x6d) [0x7f215be28ecd] 10: /usr/lib64/xorg/modules/drivers//nvidia_drv.so [0x7f215c06da23] 11: /usr/lib64/xorg/modules/drivers//nvidia_drv.so [0x7f215c0868cc] 12: /usr/lib64/xorg/modules/drivers//nvidia_drv.so [0x7f215c08775a] 13: /usr/lib64/xorg/modules/drivers//nvidia_drv.so [0x7f215c03db58] 14: /usr/bin/X [0x512669] 15: /usr/bin/X [0x4eea91] 16: /usr/bin/X(BlockHandler+0x4f) [0x44bebf] 17: /usr/bin/X(WaitForSomething+0x12b) [0x4de5cb] 18: /usr/bin/X(Dispatch+0x7b) [0x44862b] 19: /usr/bin/X(main+0x415) [0x430565] 20: /lib/libc.so.6(__libc_start_main+0xf4) [0x7f215e7434a4] 21: /usr/bin/X [0x42f969] [mi] mieqEnequeue: out-of-order valuator event; dropping. [mi] EQ overflowing. The server is probably stuck in an infinite loop. ... (last 2 lines repeated over and over, and after a while:) [mi] EQ overflowing. The server is probably stuck in an infinite loop. [mi] EQ overflowing. The server is probably stuck in an infinite loop. [mi] EQ overflowing. The server is probably stuck in an infinite loop. ... dmesg: [18309.235808] NVRM: Xid (0001:00): 26, Ch 000001ff M 00001ffc D ffffffff intr ffffffff [18309.320585] NVRM: Xid (0001:00): 1, Ch 000001ff M 00001ffc D ffffffff intr ffffffff I am pretty sure this is related to an kernel or xorg upgrade, not to an nvidia driver upgrade. I found some other sources reporting this for intel graphics and ATI, too - which supports my thesis: 1. http://bugs.gentoo.org/show_bug.cgi?id=253813 2. https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/287063 3. https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/259808 Reproducible: Sometimes Steps to Reproduce: Usually happens while moving the input device and putting work on the gpu at the same times, e.g. move around windows playing video content or scroll heavy pages in firefox. Probably related to evdev support in xorg (I configured for evdev).
Created attachment 185536 [details] output of nvidia-bug-report.sh Attaching nvidia bug report log as it gives a pretty complete system overview.
Upgrading to ~xf86-input-evdev-2.2.0 seems to improve on this a lot. Although I did not do extensive testing, the "EQ overflowing" messages seem to be gone. So prepending the summary with "nvidia-drivers" is probably misleading.
Confirmed that this is not only nvidia-related. Same problem on Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 03). This was on my Thinkpad X41 Tablet. Running: Linux-2.6.29-hh1-i686-Intel-R-_Pentium-R-_M_processor_1.50GHz-with-glibc2.0 xorg-server-1.5.3-r5 xorg-x11-7.4 xfce4-4.6.0 11-drivers/xf86-input-evdev-2.2.0-r1 Xorg.0.log snippet: ... [mi] EQ overflowing. The server is probably stuck in an infinite loop. Backtrace: 0: /usr/bin/X(xorg_backtrace+0x38) [0x81369b8] [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. (continued until I ssh'd and kill -9'd X)
Same problem on Radeon Video: 01:00.1 Display controller: ATI Technologies Inc RV380 [Radeon X600] on driver: x11-drivers/xf86-video-ati-6.12.1-r1 USE="dri" System: Linux 2.6.29-gentoo #8 SMP i686 Intel(R) Pentium(R) 4 CPU 2.80GHz GenuineIntel GNU/Linux X.Org X Server 1.5.3 Release Date: 5 November 2008 X Protocol Version 11, Revision 0 xf86-input-evdev-2.2.0-r1 Xorg.log: (EE) Logitech USB-PS/2 Optical Mouse: Read error: Resource temporarily unavailable [mi] EQ overflowing. The server is probably stuck in an infinite loop. Backtrace: 0: X(xorg_backtrace+0x38) [0x81427a4] [mi] EQ overflowing. The server is probably stuck in an infinite loop. ....
I can confirm this bug. Sometimes X freezes and I have to kill it per remote ssh-login. Problems started with updateing to Xorg 1.5.3-r5.
Confirming. Upgraded to latest shiny xserver-1.5 generation. Problem description: Start of X. Cursor moveable but nothing else works. Can't change to text console or anything -> reboot by power button. (Why the %&$&% was X zapping turned off default....%&$&%$) Then looking at X log same traces as described by others. Observed on 945GM with intel driver. Up/downgrading minor ebuild revisions on xserver and intel driver did not change anything.
Can't say it is the same bug (the "EQ overflowing" is a symptom of something going wrong, but can have various issues) but I had this when I upgraded two days ago (Xorg upgrade, drivers, ...). I have an Intel i915 GA. I resolved the issue by disabling DRI (Option "DRI" "False") in the "Device" section of xorg.conf. This leaves me with software OpenGL rendering, but I don't play 3D games anyway ;-)
I reproduce this bug by launching GLX or SDL games. At first time game starting successfully, but in second one - it put Xorg in this infinity loop.
Deactivating DRI didn't do it for me. However it is more infrequent since then. xorg.conf: Section "Device" Option "DRI" "false" EndSection Xorg.0.log: ... [mi] EQ overflowing. The server is probably stuck in an infinite loop. [mi] mieqEnequeue: out-of-order valuator event; dropping. [mi] EQ overflowing. The server is probably stuck in an infinite loop. [mi] EQ overflowing. The server is probably stuck in an infinite loop. [mi] EQ overflowing. The server is probably stuck in an infinite loop. [mi] EQ overflowing. The server is probably stuck in an infinite loop. ...
Have the same problem with x86, xf86-video-intel No sucess: 1. Back from ~x86 to stable 2. Switched off X11 overlay 3. Tested different versions of xorg, evdev, mesa... 4. Reduilded all (emerge -euDN world) Now... May be my CFLAFS are "overoptimized" for gcc-4.3.3-r2 ? So... I masked gcc-4.3.3-r2 and now rebuilding world (emerge -euDN world) with "safe" optimization. Where: CFLAGS="-O2 -march=native -mfpmath=sse -mmmx -msse2 -msse3 -mssse3 -pipe -fomit-frame-pointer" Become: CFLAGS="-O2 -march=native -pipe -fomit-frame-pointer"
may be, we should adapt the summary for all people with same problems. nvidia-drivers is inadäquate...
(In reply to comment #11) > may be, we should adapt the summary for all people with same problems. > nvidia-drivers is inadäquate... I originally posted this report not including "nvidia-drivers" in the summary but it was changed by loki_val. My original suspection was that the problem lies somewhere in evdev. I just want to point that out again. Meanwhile I found out that while all my systems are affected, my home desktop system (nvidia on intel platform) and my laptop (sis igp platform) are the only machines which do not hard lock but just freeze for some seconds.
> Now... May be my CFLAFS are "overoptimized" for gcc-4.3.3-r2 ? > So... I masked gcc-4.3.3-r2 and now rebuilding world (emerge -euDN world) with > "safe" optimization. > > Where: CFLAGS="-O2 -march=native -mfpmath=sse -mmmx -msse2 -msse3 -mssse3 -pipe > -fomit-frame-pointer" > Become: CFLAGS="-O2 -march=native -pipe -fomit-frame-pointer" No sucess. I'm afraid that problem in glibc 2.9.
same problem here on one machine (intel Q45 chipset, nvidia-drivers, KDE 4.2). have to use Ctrl-Alt-Backspace to get out of the situation :)
same here with 00:02.1 Display controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 04)
also having the probem here but i can replecate the falue it hapend evey time i start secondlife-bin this is my display controller ---------------8<---------------8<--------------->8--------------->8--------------- 00:00.0 Host bridge [0600]: Intel Corporation Mobile 4 Series Chipset Memory Controller Hub [8086:2a 40] (rev 07) Kernel driver in use: agpgart-intel 00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 4 Series Chipset Integrated Graph ics Controller [8086:2a42] (rev 07) 00:02.1 Display controller [0380]: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Con troller [8086:2a43] (rev 07) ---------------8<---------------8<--------------->8--------------->8--------------- i have the following versions of secondlife and Xorg-server ---------------8<---------------8<--------------->8--------------->8--------------- x11-base/xorg-server-1.5.3-r6 USE="dmx hal ipv6 kdrive nptl sdl xorg (-3dfx) -debug -minimal -tslib" INPUT_DEVICES="evdev keyboard mouse synaptics -acecad -aiptek -calcomp -citron -digitaledge -dmc -dynapro -elo2300 -elographics -fpit -hyperpen -jamstudio -joystick -magellan -microtouch -mutouch -palmax -penmount -spaceorb -summa -tek4957 -tslib -ur98 -virtualbox -vmmouse -void -wacom" VIDEO_CARDS="fbdev intel vesa -apm -ark -ast -chips -cirrus -dummy -epson -fglrx (-geode) -glint -i128 (-i740) (-impact) (-imstt) -mach64 -mga -neomagic (-newport) -nv -nvidia -r128 -radeon -radeonhd -rendition -s3 -s3virge -savage -siliconmotion -sis -sisusb (-sunbw2) (-suncg14) (-suncg3) (-suncg6) (-sunffb) (-sunleo) (-suntcx) -tdfx -tga -trident -tseng -v4l (-vermilion) -via -virtualbox -vmware -voodoo (-xgi) x11-drivers/xf86-input-evdev-2.1.3 USE="hal -debug" x11-drivers/xf86-input-keyboard-1.3.2 USE="-debug" x11-drivers/xf86-input-mouse-1.4.0 USE="-debug" x11-drivers/xf86-input-synaptics-1.0.0 USE="hal -debug" x11-drivers/xf86-video-fbdev-0.4.0 USE="-debug" x11-drivers/xf86-video-intel-2.6.3-r1 USE="dri -debug" x11-drivers/xf86-video-vesa-2.2.0 USE="-debug" kde-base/kdebase-startkde-3.5.10-r5 USE="-debug" games-simulation/secondlife-bin-1.22.11 ---------------8<---------------8<--------------->8--------------->8-------------- i wll attach the Xorg.log note im running x86_64 I have a few questions i would apprciate if somewone (i know outsid the sope of the beg): Is the source of this problem known? Do i nead to recompile somthing to get a good stacktrace os is this one vaid? Can i do any thesting with newer versions? Do you nead extra info? thanks !
Created attachment 195136 [details] Xorg.log of crash while starting secondlife-bin upload of Xorg.log of crash while starting secondlife-bin i have no debug useflag enabed(see my previus post)
For me it was fixed by using the new nvidia driver which has the smp fix for some geforce chipsets. But I suppose that was just another instance of the same symptom. Since this failure is completely gone and was partially gone before I'd like to suggest to also upgrade your evdev driver in combination with your graphic driver. Also I reduced my xorg.conf to the absolutely nessecary minimum (since everything is autodetected and hotplug now anyway).
=x11-drivers/nvidia-drivers-180.60 didn't fix it for me. Only downgrading xorg fixed it. Now using =x11-base/xorg-server-1.3.0.0-r6. I can confirm probs with =x11-base/xorg-server-1.5.3-r6 and =x11-base/xorg-server-1.5.3-r7. First probs came with new xorg-server 1.5.
Anyone care to tell me what's going on here and why this was dumped on our laps? Thanks
Can confirm this problem, but I'm also not sure where to search for the reason. Here (xorg-1.5.3-r6, nvidia-drivers-173.14.20, vanilla-sources-2.6.30.5) the problem happens only sometimes, but with the already mentioned errors in xorg.log: AUDIT: Fri Sep 11 10:20:01 2009: 5600 X: client 4 rejected from local host ( uid=1608 gid=10 pid=23309 ) Auth name: MIT-MAGIC-COOKIE-1 ID: -1 [mi] EQ overflowing. The server is probably stuck in an infinite loop. Backtrace: 0: /usr/bin/X(xorg_backtrace+0x3c) [0x8128e8c] 1: /usr/bin/X(mieqEnqueue+0x235) [0x81091e5] 2: /usr/bin/X(xf86PostMotionEventP+0xd9) [0x80be1f9] 3: /usr/lib/xorg/modules/input//evdev_drv.so [0xa57fafd1] 4: /usr/bin/X [0x80c50c6] 5: /usr/bin/X [0x80acf95] 6: [0xb7ee8400] [mi] mieqEnequeue: out-of-order valuator event; dropping. [mi] EQ overflowing. The server is probably stuck in an infinite loop. [...] This replicates about 200 times, then followed by a (II) NVIDIA(0): Initialized GPU GART. and some binary crap. Would be quite happy to have a solution for that, since it's quite hard to work with such an unstable system currently ...
EVerything points to an nvidia bug but for some reason, nvidia maintainers thought otherwise without telling us why. Please upgrade your nvidia drivers to a newer versions, hopefully that should make the issue go away. If not, though luck, get in touch with nvidia and/or its maintainers. Thanks
I don't second the opinion of pushing it to nvidia. I've tried every driver from this list: nvidia-drivers-173.14.15.ebuild nvidia-drivers-173.14.18.ebuild nvidia-drivers-173.14.20.ebuild nvidia-drivers-180.29.ebuild nvidia-drivers-180.60.ebuild nvidia-drivers-185.18.14.ebuild nvidia-drivers-185.18.29.ebuild nvidia-drivers-185.18.31.ebuild nvidia-drivers-190.18.ebuild nvidia-drivers-190.25.ebuild nvidia-drivers-96.43.13.ebuild And the only one which does make it more or less stable, is the currently used 173.14.20 . So, IMHO this should be investigated further.
I'm the OR and I am pretty convinced this is no nvidia bug, just something which comes into play with nvidia (and some other driver vendors) and the evdev subsystem. Since I upgraded evdev, xorg and nvidia I never experienced this problem again.
Created attachment 203900 [details] Log file Not an Nvidia only bug.
Please all upgrade to xorg-server 1.6. That's all I can recommend to try to figure it out. Thanks
Been there, done that, switched back again, because it didn't work (for me). To the OR: Would you mind telling me (resp. us) what version you're running now for evdev xorg nvidia and kernel? I would like to reproduce if it's running with the same settings on my system, too.
(In reply to comment #27) > Been there, done that, switched back again, because it didn't work (for me). > > To the OR: Would you mind telling me (resp. us) what version you're running now > for evdev xorg nvidia and kernel? I would like to reproduce if it's running > with the same settings on my system, too. > Oh, did forget to mention: With the following components my system is _almost_ stable (sometimes crashes after many hours, depending on usage): x11-base/xorg-server-1.5.3-r6 x11-drivers/nvidia-drivers-173.14.20 x11-drivers/xf86-input-evdev-2.2.4 sys-kernel/vanilla-sources-2.6.30.5
I still hope to find a solution for this, since the just finished update didn't help either: I now installed the following packages: =x11-drivers/nvidia-drivers-190.25 =media-video/nvidia-settings-190.25 =x11-base/xorg-x11-7.4 =x11-base/xorg-server-1.6.3.901 =x11-drivers/xf86-input-evdev-2.2.4 =x11-drivers/xf86-input-keyboard-1.3.2 =x11-drivers/xf86-input-mouse-1.4.0 =sys-kernel/vanilla-sources-2.6.30.5 The system came up fine, but after 13 minutes of normal usage the complete system was freezing while getting a black display. There was - although USE=debug was set - no crash information in the logs at all. Now, after second reboot, there's an uptime of 18 minutes, and waiting for the next crash... So, I'm quite sure that there's still a problem, and not with nvidia, so I would like to see this bug reopened.
I won't reopen because I'm 99.99% sure that it's a _graphics_ driver issue. Driver has a bug, GPU stalls and the server keeps waiting for it to finish drawing something. Event queue fills up, hell breaks loose. I full well know that not everyone here has an nvidia card, but I'm trying to tell you all is that it's a graphics bug. All of you think that you have the same bug because the consequences are the same : EQ overflowing. Now please, all of you please upgrade to the latest ~arch xorg-server and X driver, see if the situation improves and if not, please _each_ file a bug against your X driver. @nVidia guys, I'm adding you back so you don't reassign EQ overflowing bugs back to x11 or mark them as a dupe of this one. EQ overflow is just a collateral damage of a driver/GPU failure. Thanks to all :)
Created attachment 204128 [details] Package list For everyone who is curious (and in reply to Frank) I attach the output of: $ for i in x11-drivers x11-base x11-libs sys-kernel; do equery l $i/; done > /tmp/packages.txt Note that I have no old-style drivers (like keyboard/mouse) installed - just evdev. I will also attach my xorg.conf. This is from a working setup - no crashes, especially no EQ overflowing.
Created attachment 204129 [details] xorg.conf of working setup Attached as announced previously.
For what it's worth: (II) NVIDIA(0): Initialized GPU GART. (WW) NVIDIA(0): WAIT (2, 7, 0x8000, 0x00005cb4, 0x0000c4e8) (WW) NVIDIA(0): WAIT (0, 7, 0x8000, 0x0000c4e8, 0x0000c4e8) (WW) NVIDIA(0): WAIT (2, 6, 0x8000, 0x00009628, 0x00009638) (WW) NVIDIA(0): WAIT (0, 6, 0x8000, 0x00009638, 0x00009638) (II) NVIDIA(0): Initialized GPU GART. (WW) NVIDIA(0): WAIT (2, 6, 0x8000, 0x00000024, 0x000008f4) (WW) NVIDIA(0): WAIT (1, 6, 0x8000, 0x00000024, 0x000008f4) [mi] EQ overflowing. The server is probably stuck in an infinite loop. Backtrace: 0: /usr/bin/X (xorg_backtrace+0x28) [0x46d1c8] 1: /usr/bin/X (mieqEnqueue+0x203) [0x468d93] 2: /usr/bin/X (xf86PostMotionEventP+0xc4) [0x495c44] 3: /usr/lib64/xorg/modules/input/evdev_drv.so (0x7f4cb149b000+0x5669) [0x7f4cb14a0669] 4: /usr/bin/X (0x400000+0x83cc7) [0x483cc7] 5: /usr/bin/X (0x400000+0x121576) [0x521576] 6: /lib/libpthread.so.0 (0x7f4cb71db000+0xf8b0) [0x7f4cb71ea8b0] 7: /usr/lib64/xorg/modules/drivers/nvidia_drv.so (_nv001457X+0x91) [0x7f4cb2a37fa1]
This should be probably reopened, I've been having similar issues lately, this is a tail of Xorg log from just few minutes ago: [ 80191.572] [mi] EQ overflowing. The server is probably stuck in an infinite loop. [ 80191.611] Backtrace: [ 80191.669] 0: /usr/bin/X (xorg_backtrace+0x28) [0x45e058] [ 80191.669] 1: /usr/bin/X (mieqEnqueue+0x1eb) [0x459e5b] [ 80191.669] 2: /usr/bin/X (xf86PostMotionEventP+0xc8) [0x47ed98] [ 80191.669] 3: /usr/bin/X (xf86PostMotionEvent+0xa9) [0x47ef59] [ 80191.669] 4: /usr/lib/xorg/modules/input/synaptics_drv.so (0x7fbea11b6000+0x3a18) [0x7fbea11b9a18] [ 80191.669] 5: /usr/lib/xorg/modules/input/synaptics_drv.so (0x7fbea11b6000+0x5dc8) [0x7fbea11bbdc8] [ 80191.669] 6: /usr/bin/X (0x400000+0x7d447) [0x47d447] [ 80191.669] 7: /usr/bin/X (0x400000+0x10cd59) [0x50cd59] [ 80191.669] 8: /lib/libpthread.so.0 (0x7fbea2f2d000+0xf120) [0x7fbea2f3c120] [ 80191.669] 9: /lib/libc.so.6 (ioctl+0x7) [0x7fbea16a3b47] [ 80191.669] 10: /usr/lib/libdrm_intel.so.1 (0x7fbe9feb4000+0x55ed) [0x7fbe9feb95ed] [ 80191.669] 11: /usr/lib/xorg/modules/drivers/intel_drv.so (0x7fbea00bf000+0x12f08) [0x7fbea00d1f08] [ 80191.669] 12: /usr/lib/xorg/modules/drivers/intel_drv.so (0x7fbea00bf000+0x14927) [0x7fbea00d3927] [ 80191.669] 13: /usr/bin/X (0x400000+0x12b729) [0x52b729] [ 80191.670] 14: /usr/bin/X (0x400000+0x124270) [0x524270] [ 80191.670] 15: /usr/bin/X (BlockHandler+0x4b) [0x42522b] [ 80191.670] 16: /usr/bin/X (WaitForSomething+0x141) [0x462cf1] [ 80191.670] 17: /usr/bin/X (0x400000+0x40cc2) [0x440cc2] [ 80191.670] 18: /usr/bin/X (0x400000+0x24db5) [0x424db5] [ 80191.670] 19: /lib/libc.so.6 (__libc_start_main+0xfd) [0x7fbea15f8bbd] [ 80191.670] 20: /usr/bin/X (0x400000+0x24969) [0x424969] Interesting packages: - x11-base/xorg-server-1.8.0 - x11-drivers/xf86-video-intel-2.11.0 - sys-kernel/vanilla-sources-2.6.34_rc6 Any suggestions about further debugging?
(In reply to comment #34) > Any suggestions about further debugging? That error message is just the visible part of the iceberg and usually indicates a wedged GPU driver. Please file a separate bug and we'll try to sort it out. Thanks
I support comment 34. I have exactly the same stack trace. System hangs unpredictably, but not too often. Versions: x11-base/xorg-server-1.8.1.901 x11-drivers/xf86-video-intel-2.11.0 sys-kernel/gentoo-sources-2.6.34-r1 with tuxonice patches (3.1.1.1) Oleg
x11-base/xorg-server-1.8.1.901 has the mi overlay removed since "no one" uses it. Except it turns out NVIDIA needs it and so do intel driver versions older than 2.12.0. So you need to either upgrade to xorg-server-1.8.1.902 or get a newer version of intel drivers.
Argh, this problem is back for me. Just this time the affected system (from the OR) is NOT affected, but the other system is affected (the one I mentioned first). The system usually becomes unstable when I press Ctrl+Esc in KDE and the system monitor opens.
(In reply to comment #37) > x11-base/xorg-server-1.8.1.901 has the mi overlay removed since "no one" uses > it. Except it turns out NVIDIA needs it and so do intel driver versions older > than 2.12.0. So you need to either upgrade to xorg-server-1.8.1.902 or get a > newer version of intel drivers. > The mi overlay is back with xorg-server 1.8.99.903 (1.9 RC3) http://lists.freedesktop.org/archives/xorg/2010-June/050547.html I'm using 1.8.1.902 and still get the error message with nvidia-drivers 256.35 nvidia will backport the support for xorg 1.9 to the 256.* drivers (http://www.nvnews.net/vbulletin/showpost.php?p=2280645&postcount=4). To sum up: wait for xorg 1.9 and a newer nvidia driver.
Ok my mistake, users of 1.8.1.901 or 1.8.1.902 need to upgrade to 1.8.1.903. The recent users on this bug have been using intel drivers and not NVIDIA, so that doesn't matter.
I've moved back to gentoo-sources-2.6.33-r2 and problems are gone. I'm not sure, what does it mean. Versions: x11-base/xorg-server-1.8.1.902 x11-drivers/xf86-video-intel-2.12.0 Oleg
Hi all, Same problem here with nouveau. Before the loop there was some PGRAPH-problem in the nouveau driver according to the logs. drm? - gentoo 2.6.35-gentoo-r4 - x11-base/xorg-drivers-1.9 with input_devices_evdev input_devices_synaptics - x11-base/xorg-server-1.9 - x11-drivers/xf86-input-evdev-2.5 - x11-drivers/xf86-video-nouveau-0.0.16_pre20100819 - x11-libs/libdrm-2.4.21-r1 /var/log/Xorg.0.log.old [ 54.850] (II) NOUVEAU(0): Printing DDC gathered Modelines: [ 54.850] (II) NOUVEAU(0): Modeline "1680x1050"x0.0 120.50 1680 1712 1760 1888 1050 1051 1054 1064 -hsync -vsync (63.8 kHz) [ 1341.891] (II) AIGLX: Suspending AIGLX clients for VT switch [ 1341.891] (II) NOUVEAU(0): NVLeaveVT is called. [ 1355.491] (II) Open ACPI successful (/var/run/acpid.socket) [ 1356.075] (II) AIGLX: Resuming AIGLX clients after VT switch [ 1356.098] (II) NOUVEAU(0): NVEnterVT is called. [ 1359.399] (II) NOUVEAU(0): EDID vendor "LPL", prod id 62208 [ 1360.328] (II) NOUVEAU(0): DDCModeFromDetailedTiming: 1680x1050 Warning: We only handle separate sync. [ 1360.515] (II) NOUVEAU(0): Printing DDC gathered Modelines: [ 1360.865] (II) NOUVEAU(0): Modeline "1680x1050"x0.0 120.50 1680 1712 1760 1888 1050 1051 1054 1064 -hsync -vsync (63.8 kHz) [ 1363.526] (--) AlpsPS/2 ALPS GlidePoint: touchpad found [ 10032.447] [mi] EQ overflowing. The server is probably stuck in an infinite loop. [ 10032.447] Backtrace: [ 10032.552] 0: /usr/bin/X (xorg_backtrace+0x28) [0x461b78] [ 10032.552] 1: /usr/bin/X (mieqEnqueue+0x1eb) [0x4a59cb] [ 10032.552] 2: /usr/bin/X (xf86PostMotionEventP+0xbe) [0x46d03e] [ 10032.576] 3: /usr/lib64/xorg/modules/input/evdev_drv.so (0x7fd9a7461000+0x428f) [0x7fd9a746528f] [ 10032.576] 4: /usr/bin/X (0x400000+0x64b77) [0x464b77] [ 10032.576] 5: /usr/bin/X (0x400000+0x114df9) [0x514df9] [ 10032.576] 6: /lib/libpthread.so.0 (0x7fd9acac9000+0xf410) [0x7fd9acad8410] [ 10032.576] 7: /usr/lib64/xorg/modules/drivers/nouveau_drv.so (0x7fd9a9c72000+0x6cab) [0x7fd9a9c78cab] [ 10032.576] 8: /usr/lib64/xorg/modules/libexa.so (0x7fd9a9400000+0x989f) [0x7fd9a940989f] [ 10032.576] 9: /usr/bin/X (0x400000+0xe3676) [0x4e3676] [ 10032.576] 10: /usr/bin/X (0x400000+0x4654b) [0x44654b] [ 10032.576] 11: /usr/bin/X (0x400000+0x48839) [0x448839] [ 10032.576] 12: /usr/bin/X (0x400000+0x248ca) [0x4248ca] [ 10032.576] 13: /lib/libc.so.6 (__libc_start_main+0xfd) [0x7fd9aba50d2d] [ 10032.576] 14: /usr/bin/X (0x400000+0x24469) [0x424469] /var/log/messages Sep 6 22:37:22 gentoo kernel: [10025.791493] [drm] nouveau 0000:01:00.0: PGRAPH_ILLEGAL_MTHD - Ch 2/0 Class 0x5039 Mthd 0x0500 Data 0xfffff57b:0x06000000 Sep 6 22:37:22 gentoo kernel: [10025.791514] [drm] nouveau 0000:01:00.0: PGRAPH_ILLEGAL_MTHD - Ch 2/0 Class 0x5039 Mthd 0x0500 Data 0xfffff57b:0xfffff57b Sep 6 22:37:22 gentoo kernel: [10025.791535] [drm] nouveau 0000:01:00.0: PGRAPH_ILLEGAL_MTHD - Ch 2/0 Class 0x5039 Mthd 0x0500 Data 0x88888888:0x88888884 Sep 6 22:37:22 gentoo kernel: [10025.791558] [drm] nouveau 0000:01:00.0: PGRAPH_ILLEGAL_MTHD - Ch 2/0 Class 0x5039 Mthd 0x0500 Data 0x88888888:0x88888888 Sep 6 22:37:22 gentoo kernel: [10025.791578] [drm] nouveau 0000:01:00.0: PGRAPH_ILLEGAL_MTHD - Ch 2/0 Class 0x5039 Mthd 0x0500 Data 0xffffffff:0xffffffff Sep 6 22:37:22 gentoo kernel: [10025.791601] [drm] nouveau 0000:01:00.0: PGRAPH_ILLEGAL_MTHD - Ch 2/0 Class 0x5039 Mthd 0x0500 Data 0xffffffff:0xffffffff Sep 6 22:37:22 gentoo kernel: [10025.791622] [drm] nouveau 0000:01:00.0: PGRAPH_ILLEGAL_MTHD - Ch 2/0 Class 0x5039 Mthd 0x0500 Data 0x88888888:0x88888888 Sep 6 22:37:22 gentoo kernel: [10025.791644] [drm] nouveau 0000:01:00.0: PGRAPH_ILLEGAL_MTHD - Ch 2/0 Class 0x5039 Mthd 0x0500 Data 0x88888888:0x88888888 Sep 6 22:37:22 gentoo kernel: [10025.791665] [drm] nouveau 0000:01:00.0: PGRAPH_ILLEGAL_MTHD - Ch 2/0 Class 0x5039 Mthd 0x0500 Data 0xffffffff:0xffffffff Sep 6 22:37:22 gentoo kernel: [10025.791687] [drm] nouveau 0000:01:00.0: PGRAPH_ILLEGAL_MTHD - Ch 2/0 Class 0x5039 Mthd 0x0500 Data 0xffffffff:0xffffffff Sep 6 22:37:22 gentoo kernel: [10025.791709] [drm] nouveau 0000:01:00.0: PGRAPH_ILLEGAL_MTHD - Ch 2/0 Class 0x5039 Mthd 0x0500 Data 0x88888888:0x88888888 Sep 6 22:37:22 gentoo kernel: [10025.791729] [drm] nouveau 0000:01:00.0: PGRAPH_ILLEGAL_MTHD - Ch 2/0 Class 0x5039 Mthd 0x0500 Data 0x88888888:0x88888888 Sep 6 22:37:22 gentoo kernel: [10025.791751] [drm] nouveau 0000:01:00.0: PGRAPH_ILLEGAL_MTHD - Ch 2/0 Class 0x5039 Mthd 0x0500 Data 0xffffffff:0xffffffff Sep 6 22:37:22 gentoo kernel: [10025.791773] [drm] nouveau 0000:01:00.0: PGRAPH_ILLEGAL_MTHD - Ch 2/0 Class 0x5039 Mthd 0x0500 Data 0xffffffff:0xffffffff Sep 6 22:37:22 gentoo kernel: [10025.791793] [drm] nouveau 0000:01:00.0: PGRAPH_ILLEGAL_MTHD - Ch 2/0 Class 0x5039 Mthd 0x0500 Data 0xffffffff:0xd32a0000 Sep 6 22:37:22 gentoo kernel: [10025.791815] [drm] nouveau 0000:01:00.0: PGRAPH_ILLEGAL_MTHD - Ch 2/0 Class 0x5039 Mthd 0x0500 Data 0xffffffff:0xffffffff Sep 6 22:37:22 gentoo kernel: [10025.791837] [drm] nouveau 0000:01:00.0: PGRAPH_ILLEGAL_MTHD - Ch 2/0 Class 0x5039 Mthd 0x0500 Data 0xffffffff:0xffd70b00 Sep 6 22:37:22 gentoo kernel: [10025.791858] [drm] nouveau 0000:01:00.0: PGRAPH_ILLEGAL_MTHD - Ch 2/0 Class 0x5039 Mthd 0x0500 Data 0xffffffff:0xffffffff Sep 6 22:37:22 gentoo kernel: [10025.791880] [drm] nouveau 0000:01:00.0: PGRAPH_ILLEGAL_MTHD - Ch 2/0 Class 0x5039 Mthd 0x0500 Data 0xffffffff:0xffffffff Sep 6 22:37:22 gentoo kernel: [10025.791900] [drm] nouveau 0000:01:00.0: PGRAPH_ILLEGAL_MTHD - Ch 2/0 Class 0x5039 Mthd 0x0500 Data 0xffffffff:0xffffffff
To all those that think they have this issue, let me be very clear : You are not having the same bug! The "EQ overflow" message is just a *consequence* of bugs elsewhere, most likely in graphics drivers. So if you can reliably reproduce the issue, please file *separate* bugs for *each* issue. Thanks
please close this is not getting fixed (anymore) anyway this will give everyboddy the opertunity to open new bugs(look at the x11 debug wiki!!!!!) (infobox.oleg@wo.cz can you make a debug buld for this kernel and trace it when hang? use sysrq+Sync sysrq+reBoot see kernal doc for more info thanks)
(In reply to comment #44) > please close this is not getting fixed (anymore) anyway > > this will give everyboddy the opertunity to open new bugs(look at the x11 debug > wiki!!!!!) > > (infobox.oleg@wo.cz can you make a debug buld for this kernel and trace it when > hang? use sysrq+Sync sysrq+reBoot see kernal doc for more info thanks) I can't. My packages' version are far away from what I had back then (I have current ~amd64). And I don't experience these problems anymore. Sorry.
