Bug 22383

Summary: X server stuck in infinite loop on laptop lid close
Product: xorg Reporter: Jithin Emmanuel <jithin1987>
Component: Driver/intelAssignee: Jesse Barnes <jbarnes>
Status: RESOLVED FIXED QA Contact: Xorg Project Team <xorg-team>
Severity: critical    
Priority: high CC: bgamari, colin, ed, hez, mike.lifeguard, zorael
Version: gitKeywords: NEEDINFO, regression
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
xorg log file
none
don't count disabled CRTCs as covering
none
add kms support for covering crtc check none

Description Jithin Emmanuel 2009-06-20 03:00:36 UTC
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.
Comment 1 Jithin Emmanuel 2009-06-20 21:43:35 UTC
Forgot to mention I use KMS.
Comment 2 Mike.lifeguard 2009-06-21 11:13:15 UTC
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.
Comment 3 Jesse Barnes 2009-06-22 11:41:10 UTC
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);
Comment 4 Jesse Barnes 2009-06-22 13:12:40 UTC
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);
Comment 5 Ben Gamari 2009-06-22 13:54:24 UTC
It seems that #22283 is very similar to this and could be a dup. Thoughts?
Comment 6 Ben Gamari 2009-06-22 14:01:49 UTC
*** Bug 22283 has been marked as a duplicate of this bug. ***
Comment 7 Hezekiah M. Carty 2009-06-22 14:36:11 UTC
*** Bug 22241 has been marked as a duplicate of this bug. ***
Comment 8 Hezekiah M. Carty 2009-06-22 19:42:47 UTC
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.
Comment 9 JR 2009-06-22 19:50:54 UTC
The fix at http://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/390917 solved this for me.
Comment 10 Jithin Emmanuel 2009-06-22 20:52:30 UTC
@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.
Comment 11 Jithin Emmanuel 2009-06-22 21:00:37 UTC
One more thing sudo xset dpms force off && sleep 5 && sudo xset dpms force on
freezes me instantly with nothing on Xorg log
Comment 12 Łukasz Maśko 2009-06-22 23:41:19 UTC
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.
Comment 13 Ben Gamari 2009-06-23 06:52:46 UTC
(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.
Comment 14 Jesse Barnes 2009-06-23 09:38:37 UTC
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?
Comment 15 Jithin Emmanuel 2009-06-23 10:29:59 UTC
@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.
Comment 16 Colin Guthrie 2009-06-23 10:38:46 UTC
(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'.
Comment 17 Colin Guthrie 2009-06-23 11:15:29 UTC
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 :)
Comment 18 Jithin Emmanuel 2009-06-23 11:44:53 UTC
(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.
Comment 19 Jithin Emmanuel 2009-06-23 11:50:46 UTC
sudo xset dpms force off && sleep 5 && sudo xset dpms force on

still freezes my system with latest patch.
Comment 20 Jesse Barnes 2009-06-23 14:31:19 UTC
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).
Comment 21 Jithin Emmanuel 2009-06-23 18:40:58 UTC
@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
Comment 22 Hezekiah M. Carty 2009-06-23 21:02:26 UTC
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).
Comment 23 Jithin Emmanuel 2009-06-23 23:28:08 UTC
(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.
Comment 24 Hezekiah M. Carty 2009-06-24 07:20:47 UTC
(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.
Comment 25 Jesse Barnes 2009-06-24 09:51:53 UTC
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.
Comment 26 Hezekiah M. Carty 2009-06-24 10:15:04 UTC
It is quite possible that the output issue is a coincidence.  I can do some extra if it would be helpful.
Comment 27 roberth 2009-06-24 12:05:32 UTC
(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.
Comment 28 Jesse Barnes 2009-06-24 13:13:37 UTC
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.