this bug is really for downstream tracking. http://bugs.freedesktop.org/show_bug.cgi?id=18879 I'm gonna test the patch, if it works maybe it could be added to gentoo-sources-2.6.28-r1? Reproducible: Always
initial test of the patch shows no problems and it resolves the issue.
last test of patch doesn't exactly work, need to test the latest patch yet.
Please apply these 2 patches in this order: http://git.kernel.org/?p=linux/kernel/git/anholt/drm-intel.git;a=commitdiff_plain;h=9f4f07ceb1716d8796089fcef91621c5f07c872a http://git.kernel.org/?p=linux/kernel/git/anholt/drm-intel.git;a=commitdiff_plain;h=e1a6fcee467556a7e955fe1f7ccc134dd2f974e7 Does that solve the bug?
gotta double check this answer after while, but no.
I'm calling it a no go, but not sure if it will work without the libdrm patch. should cc the maintainer of that.
Please test it first. Then we will take appropriate action.
Daniel, I'm not sure why we should test this patches separately when maintainer told us what is required for this bug to be fixed: http://bugs.freedesktop.org/show_bug.cgi?id=18879#c36 And in another URL: https://bugs.freedesktop.org/show_bug.cgi?id=18922 it was confirmed to fix similar issue. In any case I found this bug too late to test everything separately. I already have, mentioned in comment #3 patches applied and the another patch for libdrm: http://cgit.freedesktop.org/mesa/drm/patch/?id=f4f76a6894b40abd77f0ffbf52972127608b9bca With this fixes my X became a bit more stable. CC'ing X11 for libdrm bits. Please, apply. To make this bug searchable here is copy of backtrace: Backtrace: 0: /usr/X11R6/bin/X(xorg_backtrace+0x26) [0x4ee1a6] 1: /usr/X11R6/bin/X(mieqEnqueue+0x291) [0x4cebd1] 2: /usr/X11R6/bin/X(xf86PostMotionEventP+0xc4) [0x498554] 3: /usr/X11R6/bin/X(xf86PostMotionEvent+0xb1) [0x498731] 4: /usr/lib/xorg/modules/input//evdev_drv.so [0x7f26a0a559b2] 5: /usr/X11R6/bin/X [0x481625] 6: /usr/X11R6/bin/X [0x472147] 7: /lib/libpthread.so.0 [0x7f26b9bbf080] 8: /lib/libc.so.6(ioctl+0x7) [0x7f26b8221d87] 9: /usr/lib/libdrm.so.2 [0x7f26b6dfe8d3] 10: /usr/lib/libdrm.so.2(drmWaitVBlank+0x20) [0x7f26b6dfed70] 11: /usr/lib/dri/i965_dri.so [0x7f26a5ccb85e] 12: /usr/lib/dri/i965_dri.so(driWaitForVBlank+0x110) [0x7f26a5ccbaf0] 13: /usr/lib/dri/i965_dri.so(intelSwapBuffers+0xe5) [0x7f26a5cd53d5] 14: /usr/lib/dri/i965_dri.so [0x7f26a5cccdef] 15: /usr/lib/xorg/modules/extensions//libglx.so [0x7f26b7659b5f] 16: /usr/lib/xorg/modules/extensions//libglx.so [0x7f26b764d936] 17: /usr/lib/xorg/modules/extensions//libglx.so [0x7f26b7650bd2] 18: /usr/X11R6/bin/X(Dispatch+0x364) [0x44d754] 19: /usr/X11R6/bin/X(main+0x45d) [0x43376d] 20: /lib/libc.so.6(__libc_start_main+0xe6) [0x7f26b8162586] 21: /usr/X11R6/bin/X [0x432b49] [mi] mieqEnequeue: out-of-order valuator event; dropping. [mi] EQ overflowing. The server is probably stuck in an infinite loop.
Sorry, we don't apply random patches without confirmation of the fix from a Gentoo user, or upstream blessing in the form of Linus or linux-stable. In fact, the discussion on this bug and the upstream one includes considerable doubt as to whether this actually fixes the problem. Also note that the upstream comment you refer to was posted after mine was. I'm also a bit confused by your comment. So, you ran into the bug too? What do you mean by you didn't test everything "separately"? Did applying everything actually fix the bug? What do you mean by "a bit more stable" - that seems to indicate that the bug still exists, if only less frequently?
Daniel, sorry, I was not enough clear. My issue with X11 is that whenever I stopped X11 I got backtrace you see in comment #7 and X11 failed to stop, so I had to kill it (problem is even worth since it left driver in bad conditions so subsequent start hanged my notebook and I had to restart it). Although I've reproduced the bug in different conditions backtrace was very similar to what was reported in [1] (I even just copied backtrace from there here). I applied all three patches and this problem went away. So at least there are two confirmations (one in [1] and my own success) that these patches fix something. I speak something because this bug reveals that there are further situations in which this backtrace and problem exists. > So, you ran into the bug too? Not sure. I have not tried to suspend/resume that notebook yet. > What do you mean by you didn't test everything "separately"? I meant that I have not tested only kernel side without libdrm. > Did applying everything actually fix the bug? What do you mean by "a bit more > stable" - that seems to indicate that the bug still exists, if only less > frequently? The more we speak the more I'm sure that some error gone. Previously I had no chances to restart X11 but now I did that many time already and no sign of this problem. Caleb, what problems you have applying patch to libdrm? If you need any assistance just ask. It good idea to get another confirmation that these patches fix suspend/resume issue too. [1] https://bugs.freedesktop.org/show_bug.cgi?id=18922
OK, thanks for the positive report - that is all that we needed. I've queued the patches for the next 2.6.28 release (due out in the next day or two), so I'll reassign this for libdrm patch inclusion.
sorry was trying to get the patch to apply to 2.4.3 but it didn't work... does it apply to 2.4.4? or is it in 2.4.4? any help getting the libdrm patch applied would be helpful. this bug is a side priority as I don't actually switch to VT much, I don't use resume suspend at all.
Caleb, I have not noticed 2.4.4 was already released. Yes, patch is already there, but since libdrm is package.masked probably you'll want to apply patch to 2.4.3 at this moment. Just do: wget 'http://cgit.freedesktop.org/mesa/drm/patch/?id=f4f76a6894b40abd77f0ffbf52972127608b9bca' -O libdrm-2.4.3.patch cd $PORTDIR/x11-libs/libdrm ebuild libdrm-2.4.3.ebuild unpack cd $PORTAGE_TMPDIR/x11-libs/libdrm-2.4.3/work/libdrm-2.4.3 patch -p1 -i libdrm-2.4.3.patch cd $PORTDIR/x11-libs/libdrm ebuild libdrm-2.4.3.ebuild merge
Please do try with 2.4.4. I'm only keeping it in p.mask because some API was dropped since 2.4.3, but the latest stable Intel driver is still using it somehow. I don't think it should cause it trouble, but I'm playing it safe for now. Thanks
2.4.4 is unmasked as I was told not to worry (too much) about my API woes. Closing fixed.
sorry I couldn't get on testing this again sooner, just tested, works for me, nice to be able to switch again. thanks guys.
Rémi, just to report back. Yup, I've tried it with SiS, radeon, intel and openchrome drivers and all of them builds find with this newer libdrm and intel, SiS works, radeon and openchrome still untested (need to reboot running X sessions, but will do that later...).
Yet this(In reply to comment #16) > and intel, SiS works, radeon and openchrome still untested (need to reboot running X sessions, but will do that later...). I run the proprietary “ati-driver-8.561” here, and it still gets a flood of errors. It looks very much not fixed. Or is this because I have the “zen-sources-2.6.29_rc2-r1 installed”? Please reopen this bug. ### The errors: (the [mi] line repeats hundreds of times) ###################### [mi] EQ overflowing. The server is probably stuck in an infinite loop. ⋮ Backtrace: 0: /usr/bin/X(xorg_backtrace+0x26) [0x4e4786] 1: /usr/bin/X(mieqEnqueue+0x289) [0x4c5c99] 2: /usr/bin/X(xf86PostMotionEventP+0xc4) [0x471e14] 3: /usr/bin/X(xf86PostMotionEvent+0xaf) [0x471fdf] 4: /usr/lib64/xorg/modules/input//evdev_drv.so [0x7ffc2fde401a] 5: /usr/bin/X [0x4846e5] 6: /usr/bin/X [0x468c9e] 7: /lib/libpthread.so.0 [0x3ff8c0ea00] 8: /usr/lib/libpixman-1.so.0 [0x3001c28511] 9: /usr/lib64/xorg/modules//libfb.so(fbCopyNtoN+0x273) [0x7ffc44961533] 10: /usr/lib64/xorg/modules//libfb.so(fbCopyRegion+0x200) [0x7ffc44960460] 11: /usr/lib64/xorg/modules//libfb.so(fbDoCopy+0x443) [0x7ffc449609b3] 12: /usr/lib64/xorg/modules//libfb.so(fbCopyArea+0x4c) [0x7ffc44960b4c] 13: /usr/lib64/xorg/modules//libxaa.so [0x7ffc446fa8da] 14: /usr/lib64/xorg/modules//libxaa.so [0x7ffc44741828] 15: /usr/bin/X [0x5267b2] 16: /usr/bin/X [0x4f47fd] 17: /usr/bin/X(compReallocPixmap+0x9f) [0x4f491f] 18: /usr/bin/X(compResizeWindow+0x93) [0x4f3d83] 19: /usr/bin/X(ConfigureWindow+0xa77) [0x433797] 20: /usr/bin/X(ProcConfigureWindow+0x8d) [0x44592d] 21: /usr/bin/X(Dispatch+0x364) [0x4462a4] 22: /usr/bin/X(main+0x45d) [0x42d12d] 23: /lib/libc.so.6(__libc_start_main+0xe6) [0x3ff801e5c6] 24: /usr/bin/X [0x42c519] [mi] mieqEnequeue: out-of-order valuator event; dropping. [mi] EQ overflowing. The server is probably stuck in an infinite loop. ⋮ Backtrace: 0: /usr/bin/X(xorg_backtrace+0x26) [0x4e4786] 1: /usr/bin/X(xf86SigHandler+0x39) [0x4845f9] 2: /lib/libc.so.6 [0x3ff8032290] 3: /usr/lib64/xorg/modules//libxaa.so [0x7ffc44741acc] 4: /usr/lib64/xorg/modules//libxaa.so [0x7ffc447422d0] 5: /usr/bin/X [0x524548] 6: /usr/bin/X(miGlyphs+0x5a7) [0x50a5d7] 7: /usr/lib64/xorg/modules//libxaa.so(XAAGlyphs+0x1f8) [0x7ffc44724168] 8: /usr/bin/X [0x524861] 9: /usr/bin/X [0x5157e4] 10: /usr/bin/X(Dispatch+0x364) [0x4462a4] 11: /usr/bin/X(main+0x45d) [0x42d12d] 12: /lib/libc.so.6(__libc_start_main+0xe6) [0x3ff801e5c6] 13: /usr/bin/X [0x42c519] Fatal server error: Caught signal 11. Server aborting Failed to set aperture, ret = 0x00000001
(In reply to comment #17) > I run the proprietary “ati-driver-8.561” here, and it still gets a flood of > errors. > It looks very much not fixed. Or is this because I have the > “zen-sources-2.6.29_rc2-r1 installed”? Please open a new one. Let's not mix issues that are unlikely to be related. Thanks
