Created attachment 26967 [details] xorg log file If I close my laptop lid X server freezes. Just a blank screen in the result. I need sys req RSEIUB to reboot, though I can ssh to the box. From Xorg.0.log [mi] EQ overflowing. The server is probably stuck in an infinite loop. Backtrace: 0: /usr/bin/X(xorg_backtrace+0x3b) [0x81353ab] 1: /usr/bin/X(mieqEnqueue+0x2d9) [0x8114ea9] 2: /usr/bin/X(xf86PostButtonEvent+0x105) [0x80ce555] 3: /usr/lib/xorg/modules/input//synaptics_drv.so [0xb7357951] 4: /usr/lib/xorg/modules/input//synaptics_drv.so [0xb7359eb9] 5: /usr/bin/X [0x80c76a7] 6: /usr/bin/X [0x80b82ac] 7: [0xb7ef7400] 8: /usr/lib/libdrm_intel.so.1 [0xb787a475] 9: /usr/lib/libdrm_intel.so.1(drm_intel_bo_wait_rendering+0x12) [0xb7877432] 10: /usr/lib/dri/i965_dri.so(intelFinish+0x51) [0xb73fd681] 11: /usr/lib/dri/i965_dri.so(_mesa_Finish+0x41) [0xb745a5c1] 12: /usr/lib/xorg/modules/extensions//libglx.so [0xb7990431] 13: /usr/lib/xorg/modules/extensions//libglx.so [0xb7994eaa] 14: /usr/bin/X(Dispatch+0x33f) [0x808d66f] 15: /usr/bin/X(main+0x3bd) [0x80723dd] 16: /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe5) [0xb7be6775] 17: /usr/bin/X [0x8071891] [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.
Forgot to mention I use KMS.
I have a nearly-identical freeze, leading me to believe that closing the lid isn't necessary. My computer is set to have a screensaver after 15 minutes idle; then after another 15 minutes idle (ie 30 minutes total) to turn off the screen. At this point, the laptop may come back normally -- however after a long time (overnight) the screen stays off regardless of any input. I ALT+SysReq+REISUB to reboot.
Can you give this patch a try? I *think* I've been seeing the same issue since the tearing fix went in, and this could be the cause. diff --git a/src/i830_video.c b/src/i830_video.c index 1ff80a0..a34d945 100644 --- a/src/i830_video.c +++ b/src/i830_video.c @@ -1733,6 +1733,9 @@ i830_covering_crtc (ScrnInfoPtr pScrn, crtc_box_ret->y2 = 0; for (c = 0; c < xf86_config->num_crtc; c++) { + if (!crtc->enabled) + continue; + crtc = xf86_config->crtc[c]; i830_crtc_box (crtc, &crtc_box); i830_box_intersect (&cover_box, &crtc_box, box);
Err this one might work better. Both the video and DRI2 swapbuffers code share this path. diff --git a/src/i830_video.c b/src/i830_video.c index 1ff80a0..962d1f7 100644 --- a/src/i830_video.c +++ b/src/i830_video.c @@ -1734,6 +1734,10 @@ i830_covering_crtc (ScrnInfoPtr pScrn, for (c = 0; c < xf86_config->num_crtc; c++) { crtc = xf86_config->crtc[c]; + + if (!crtc->enabled) + continue; + i830_crtc_box (crtc, &crtc_box); i830_box_intersect (&cover_box, &crtc_box, box); coverage = i830_box_area (&cover_box);
It seems that #22283 is very similar to this and could be a dup. Thoughts?
*** Bug 22283 has been marked as a duplicate of this bug. ***
*** Bug 22241 has been marked as a duplicate of this bug. ***
On my system (specs and info listed in bug 22241), running: sudo xset dpms force off && sleep 5 && sudo xset dpms force on completes without issue - the system comes back, fully functional, after 5 seconds. However, if I increase the sleep duration to 40 I get the same hang I get when Gnome kicks in DPMS.
The fix at http://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/390917 solved this for me.
@Jesse. I applied you patch. There are 2 cases. 1. Now its working when I close lid *on AC power*. It correctly locks screen with no freeze. But I am facing the issue described in comment 9. I wait for 1 min it locks up. Nothing in logs, might be a different issue. 2. If I close my lid on battery power, it freezes instantly. Guess a different path is executed when lid closed under battery power.
One more thing sudo xset dpms force off && sleep 5 && sudo xset dpms force on freezes me instantly with nothing on Xorg log
On my laptop I can close the LID once, though the screen gets a bit corrupted like in this picture: http://yen.ipipan.waw.pl/~ed/DSC00230.JPG (changing to console and back fixes it). The second time always hangs my machine. By the way (don't nkow, if it is related), the screen backlight is NOT turned off after the lid is closed and it shines all the time - I can turn it off with vbetool dpms off.
(In reply to comment #9) > The fix at http://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/390917 > solved this for me. > That is only a workaround. As mentioned in the cited bug report, the problem is actually a bug at the driver level. It would be appreciated if you could try the fixes described on this bug.
Created attachment 27053 [details] [review] don't count disabled CRTCs as covering My last patch checked the wrong CRTC field. One reporter said something like this worked for them... Can you give it a try?
@jesse tried out the latest patch does not work. Closed lid in ac power and after a few seconds opened and froze. For xorg log [mi] EQ overflowing. The server is probably stuck in an infinite loop. [mi] mieqEnqueue: more than six valuator events; dropping. [mi] EQ overflowing. The server is probably stuck in an infinite loop. [mi] mieqEnqueue: more than six valuator events; dropping. [mi] EQ overflowing. The server is probably stuck in an infinite loop. [mi] mieqEnqueue: more than six valuator events; dropping. [mi] EQ overflowing. The server is probably stuck in an infinite loop. [mi] mieqEnqueue: more than six valuator events; dropping.
(In reply to comment #14) > My last patch checked the wrong CRTC field. One reporter said something like > this worked for them... Can you give it a try? For me this survived a 3 minute dpms off and came back fine. I'm not 100% sure this is the problem I was seeing on my setup tho', so I'll confirm via the natural test I've done in the past to be sure. I wont be able to confirm that until later tho'.
Yes, it seems to have fixed the problem for me (just did my previous test - wait for g-p-m to kick in the screen blank and wait for a while). Seems good. Thanks :)
(In reply to comment #14) > Created an attachment (id=27053) [details] > don't count disabled CRTCs as covering > > My last patch checked the wrong CRTC field. One reporter said something like > this worked for them... Can you give it a try? > Situations just reversed for me. It behaves correctly when I close lid on battery power. And if I close laptop in in ac power it freezes. I use intel gm 965.
sudo xset dpms force off && sleep 5 && sudo xset dpms force on still freezes my system with latest patch.
Created attachment 27063 [details] [review] add kms support for covering crtc check Last one didn't have kms support, this one works for me though (also includes another bit to control swapbuffers behavior).
@Jesse. I am able to apply your patches. git apply --check patch error: patch failed: src/drmmode_display.c:71 error: src/drmmode_display.c: patch does not apply error: patch failed: src/i830.h:414 error: src/i830.h: patch does not apply error: patch failed: src/i830_display.c:1256 error: src/i830_display.c: patch does not apply error: patch failed: src/i830_dri.c:299 error: src/i830_dri.c: patch does not apply error: patch failed: src/i830_driver.c:171 error: src/i830_driver.c: patch does not apply error: patch failed: src/i830_video.c:1734 error: src/i830_video.c: patch does not apply I got the sources from git://git.freedesktop.org/git/xorg/driver/xf86-video-intel
On my Ubuntu Jaunty system, I have not seen this hang once I installed: xserver-xorg-video-intel_2.7.99.901+git20090623.zdpmsfix-0ubuntu0sarvatt~jaunty_amd64.deb provided by Sarvatt in #intel-gfx, along with the rest of the updates in the xorg-edgers package archive. From what I understand, this package contains the patch in comment 14. I do not have KMS enabled (as far as I know).
(In reply to comment #20) > Created an attachment (id=27063) [details] > add kms support for covering crtc check > > Last one didn't have kms support, this one works for me though (also includes > another bit to control swapbuffers behavior). > I can confirm that this path works. I use kms and have intel gm 965. @Carty In reply to comment #22 I can also confirm that its not fixed in the ubuntu package you mentioned.
(In reply to comment #22) > On my Ubuntu Jaunty system, I have not seen this hang once I installed: > > xserver-xorg-video-intel_2.7.99.901+git20090623.zdpmsfix-0ubuntu0sarvatt~jaunty_amd64.deb > > provided by Sarvatt in #intel-gfx, along with the rest of the updates in the > xorg-edgers package archive. This seems to have introduced a separate bug. When starting my system with an external display attached, the internal display is enabled (X acts like it is there and functioning) but powered off. The external display is on. If I turn the external display off with: xrandr --output VGA1 --off then the internal display powers back on. I don't know if this is directly connected to the dpmsfix patch or if it is a coincidence due to another intel git update.
Hm, the patch shouldn't have affected whether outputs are on... I'll double check. Sounds like the last one works though, in that it prevents the hangs. Thanks for testing.
It is quite possible that the output issue is a coincidence. I can do some extra if it would be helpful.
(In reply to comment #26) > It is quite possible that the output issue is a coincidence. I can do some > extra if it would be helpful. > Spoke with Hezekiah M. Carty about it in IRC and his LVDS problem started in this commit (or in the SwapbuffersWait commit that was included in the patch) - Fix LFP data block fetch 15af8ea6ab6998bbab9f4eeda227565c409da229 Everything until the "Don't change the blank/sync width when calculating scaled modes" commit worked fine, and its broken with intel git master as well for him.
Fix pushed, thanks everyone. commit 5d80e24b5fc6d6028028da6ded35389c08bfce29 Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Wed Jun 24 13:12:25 2009 -0700 Treat disabled CRTCs as "not covering" for scanline wait purposes
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.