LVDS display not returning from dpms off state on intel after a set time period.

Bug #390917 reported by Robert Hooker
44
This bug affects 8 people
Affects Status Importance Assigned to Milestone
xf86-video-intel
Fix Released
Critical
xserver-xorg-video-intel (Ubuntu)
Fix Released
Medium
Unassigned

Bug Description

Binary package hint: acpi-support

When using KMS on intel, the /usr/share/acpi-support/screenblank script is called on a lid closure event which unconditionally locks in KDE the screen via this -

elif [ `pidof dcopserver` ]; then
        dcop kdesktop KScreensaverIface lock
fi

This has a side effect of causing a unrecoverable hang approximately 1 minute after the lid is closed currently. If you open the lid before about 45 seconds or so in it will recover fine, but waiting longer will result in having to reboot. Removing this action from the script makes it work correctly.

Revision history for this message
In , Jithin Emmanuel (jithin1987) wrote :

Forgot to mention I use KMS.

Revision history for this message
In , Mike.lifeguard (mikelifeguard) wrote :

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.

Revision history for this message
In , Jesse Barnes (jbarnes-virtuousgeek) wrote :

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);

Revision history for this message
In , Jesse Barnes (jbarnes-virtuousgeek) wrote :

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);

Revision history for this message
In , Ben Gamari (bgamari) wrote :

It seems that #22283 is very similar to this and could be a dup. Thoughts?

Revision history for this message
In , Ben Gamari (bgamari) wrote :

*** Bug 22283 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Hezekiah Carty (hez) wrote :

*** Bug 22241 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Hezekiah Carty (hez) wrote :

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.

Revision history for this message
In , Zorael (zorael) wrote :
Revision history for this message
In , Jithin Emmanuel (jithin1987) wrote :

@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.

Revision history for this message
In , Jithin Emmanuel (jithin1987) wrote :

One more thing sudo xset dpms force off && sleep 5 && sudo xset dpms force on
freezes me instantly with nothing on Xorg log

Revision history for this message
In , Ed-yen (ed-yen) wrote :

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.

Revision history for this message
Robert Hooker (sarvatt) wrote : screenblank script unconditionally forces screen lock in KDE which causes crashing upon lid close under KMS.

Binary package hint: acpi-support

When using KMS on intel, the /usr/share/acpi-support/screenblank script is called on a lid closure event which unconditionally locks in KDE the screen via this -

elif [ `pidof dcopserver` ]; then
        dcop kdesktop KScreensaverIface lock
fi

This has a side effect of causing a unrecoverable hang approximately 1 minute after the lid is closed currently. If you open the lid before about 45 seconds or so in it will recover fine, but waiting longer will result in having to reboot. Removing this action from the script makes it work correctly.

Revision history for this message
Robert Hooker (sarvatt) wrote :
Revision history for this message
Robert Hooker (sarvatt) wrote :
Revision history for this message
In , Ben Gamari (bgamari) wrote :

(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.

Revision history for this message
Robert Hooker (sarvatt) wrote : Re: screenblank script unconditionally forces screen lock in KDE which causes crashing upon lid close under KMS.

Well, I guess it is a little more complicated than that, but I was helping troubleshoot KMS dpms hangs from intel bug reports with some people on IRC and felt it should probably be brought up here because removing it did in fact fix their problem. I noticed debian carries a patch in acpi-support that would probably be much more correct than completely removing the dcop screen locking from it entirely. I'm surprised this script gets used though, perhaps its related them being on jaunty.

http://git.debian.org/?p=pkg-acpi/acpi-support.git;a=blob;f=debian/patches/screenblank.diff;h=883efd569f5d56a32c1b5bfd45fd051635c892c2;hb=HEAD

    6 elif [ `pidof dcopserver` ]; then
    7 - dcop kdesktop KScreensaverIface lock
    8 + if [ x$LOCK_SCREEN = xtrue ]; then
    9 + avail_sessions=`dcop --all-users --list-sessions | grep '.DCOP.*__0'`
  10 + # send the lock command to all sessions
  11 + for session in $avail_sessions; do
  12 + # /dev/null because dcop warns if it can't connect to X (this is normal!)
  13 + dcop --session "$session" --all-users kdesktop KScreensaverIface lock > /dev/null 2>&1
  14 + done
  15 + fi
  16 fi
  17
  18 xset dpms force off

Revision history for this message
In , Jesse Barnes (jbarnes-virtuousgeek) wrote :

Created an attachment (id=27053)
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?

Revision history for this message
In , Jithin Emmanuel (jithin1987) wrote :

@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.

Revision history for this message
In , Fdo (fdo) wrote :

(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'.

Revision history for this message
In , Fdo (fdo) wrote :

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 :)

Revision history for this message
In , Jithin Emmanuel (jithin1987) wrote :

(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.

Revision history for this message
In , Jithin Emmanuel (jithin1987) wrote :

sudo xset dpms force off && sleep 5 && sudo xset dpms force on

still freezes my system with latest patch.

Revision history for this message
Robert Hooker (sarvatt) wrote : Re: screenblank script unconditionally forces screen lock in KDE which causes crashing upon lid close under KMS.

Perhaps this should be marked invalid, more testing has shown that its a deeper rooted problem and workarounds that might only be needed temporarily aren't ideal. Not to mention, the fix I attached earlier ended up only working because of a mistake I made in it as I'll describe later..

The problem is --

1) The user using has KDE or Gnome set to "Blank Screen" on lid close with intel graphics.
2) They close the lid, approximately 1 minute later the system will not restore the screen. If they open the lid before then it restores fine.
3) Alternatively, it can also happen when the display is put to sleep via the display idle timeout settings.

Zorael and I have done some experimenting with different combinations of settings to see if we could figure out what was happening in his case (jaunty, KDE) What we tried:

1) Desktop power settings "Do Nothing"/stock screenblank script/lid close: verified screenblank script is being run, unrecoverable crash ~1 minute after screen blanks but restores fine if opened sooner. no KDE lid close event noise.
2) Desktop power settings "Do Nothing"/screenblank script that does not call xset dpms force off/lid close: no KDE lid close event noise, this works perfectly.
3) Desktop power settings "Blank Screen"/any acpi-support/lid close: Immediate unrecoverable crash after lid close, KDE lid close event noise.

In my patch above you can see I commented out one too many lines, the final fi that was commented ended up making the script a noop when xscreensaver isn't running which led us to find that it was the actual xset dpms force off call that was causing the hangs and not the lock part.

In all cases manually doing a "sudo xset dpms force off" instead of doing an actual lid close had the same results as the lid close incase its relevant. Interestingly, his results were identical in all cases both with and without KMS. Perhaps someone more knowledgeable about how it all works could extrapolate something out of all of that and I'm sorry for the noise. :)

Robert Hooker (sarvatt)
summary: - screenblank script unconditionally forces screen lock in KDE which
- causes crashing upon lid close under KMS.
+ LVDS display not returning from dpms off state on intel after a set time
+ period.
Revision history for this message
In , Jesse Barnes (jbarnes-virtuousgeek) wrote :

Created an attachment (id=27063)
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).

Revision history for this message
In , Jithin Emmanuel (jithin1987) wrote :

@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

Revision history for this message
Ben Gamari (bgamari) wrote :

This is a recently introduced but known bug in the intel driver. It is being tracked at https://bugs.freedesktop.org/show_bug.cgi?id=22383.

Steve Langasek (vorlon)
affects: acpi-support (Ubuntu) → xserver-xorg-video-intel (Ubuntu)
Revision history for this message
In , Hezekiah Carty (hez) wrote :

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).

Revision history for this message
In , Jithin Emmanuel (jithin1987) wrote :

(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.

Revision history for this message
In , Hezekiah Carty (hez) wrote :

(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.

Revision history for this message
In , Jesse Barnes (jbarnes-virtuousgeek) wrote :

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.

Revision history for this message
In , Hezekiah Carty (hez) wrote :

It is quite possible that the output issue is a coincidence. I can do some extra if it would be helpful.

Revision history for this message
In , Robert Hooker (sarvatt) wrote :

(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.

Revision history for this message
In , Jesse Barnes (jbarnes-virtuousgeek) wrote :

Fix pushed, thanks everyone.

commit 5d80e24b5fc6d6028028da6ded35389c08bfce29
Author: Jesse Barnes <email address hidden>
Date: Wed Jun 24 13:12:25 2009 -0700

    Treat disabled CRTCs as "not covering" for scanline wait purposes

Changed in xserver-xorg-video-intel:
status: Unknown → Fix Released
Revision history for this message
Robert Hooker (sarvatt) wrote :

Drop in replacements for the intel driver in karmic that contain the fix are available in this PPA.

https://edge.launchpad.net/~ubuntu-x-swat/+archive/x-updates

Geir Ove Myhr (gomyhr)
Changed in xserver-xorg-video-intel (Ubuntu):
importance: Undecided → Medium
status: New → Triaged
Revision history for this message
Oded Arbel (oded-geek) wrote :

the package for xserver-xorg-video-intel version 2:2.7.99.901+git20090702.74227141-0ubuntu1 from the x-swat ppa above fixed the hanging problem for me, but introduced a serious screen corruption issue - should I report it here or open a new ticket for it?

Revision history for this message
Geir Ove Myhr (gomyhr) wrote :

Oded, please open a new bug report for the screen corruption issue.

Revision history for this message
Jithin Emmanuel (jithin1987) wrote :

I got a system freeze with the above package. Needed sysreq RSEIUB to get out.

Revision history for this message
Robert Hooker (sarvatt) wrote :

What were you doing at the time? Watching a video with Xv by any chance?

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package xserver-xorg-video-intel - 2:2.7.99.901+git20090702.74227141-0ubuntu1

---------------
xserver-xorg-video-intel (2:2.7.99.901+git20090702.74227141-0ubuntu1) karmic; urgency=low

  [Robert Hooker]
  * Update to git 20090702 (master branch) up to commit 74227141
   - Treat disabled CRTCs as "not covering" for scanline wait purposes.
     Fixes problems returning from a dpms off state.
     (LP: #390917, #383973, #390633, #385448, #388357)
   - Add an xorg.conf option to control swapbuffers behavior.
   - Set hot plug interrupt to detect HDMI output.
   - Add a pipe-a quirk for Dell mini
     (LP: #395306)
   - Add a pipe-a quirk for thinkpad x30
     (LP: #304614)
   - Reenable XvMC support in UXA. Now includes vld support.
   - Fix EDID for LVDS output device to add the default modes in UMS.
     (LP: #385832)
   - Export EDID when using KMS, so Display options shows info correctly
     (LP: #395140)
   - Fixes for SDVO LVDS mode detection.
   - Fix major performance regression of trapezoid rendering in UXA.
   - Fixes for hangs when GL compositing is used with multiple monitors
     with different refresh rates.
   - Support for new IGDNG devices.
   - Only get the VBIOS in non-KMS mode
   - Add a few error messages for DRM initialization
   - Don't try to pin buffers in KMS mode
   - Fix 945GM VT switch in UMS
   - Clear the bo on the rotate scratch pixmap (Fixes problems with rotation)
   - uxa: Fix segfault on source-only picture usage with FallbackDebug.
   - Various XvMC fixes.
  * Merge with Debian experimental. Remaining Ubuntu changes:
   - Add lpia architecture
  * Drop patches since they're already upstream:
    - 110_quirk_hp_mini.patch
    - 117_quirk_thinkpad_x30.patch
    - 118_pixmap_inline_funcs.patch
    - 119_fix_drawable_abuse.patch
    - 120_fix_dri2_vblank_syncing_segfault.patch
    - 121_dont_change_blank_sync_width.patch
    - 122_wait_for_vblank_to_sub_border_color.patch
    - 123_kms_export_edid.patch

 -- Bryce Harrington <email address hidden> Thu, 09 Jul 2009 14:02:45 -0700

Changed in xserver-xorg-video-intel (Ubuntu):
status: Triaged → Fix Released
Revision history for this message
Jithin Emmanuel (jithin1987) wrote : Re: [Bug 390917] Re: LVDS display not returning from dpms off state on intel after a set time period.

I was using quassel. And was clicking around the Buffers section.

On Fri, Jul 10, 2009 at 3:18 AM, Robert Hooker <email address hidden> wrote:

> What were you doing at the time? Watching a video with Xv by any chance?
>
> --
> LVDS display not returning from dpms off state on intel after a set time
> period.
> https://bugs.launchpad.net/bugs/390917
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

--
Thanks
Jithin Emmanuel

Clifford Stoll<http://www.brainyquote.com/quotes/authors/c/clifford_stoll.html>
- "The Internet is a telephone system that's gotten uppity."

Revision history for this message
Jithin Emmanuel (jithin1987) wrote :

Forgot to mention I was using an external monitor of 1920 * 1200 resolution
with my laptop at that time.

On Fri, Jul 10, 2009 at 6:25 AM, Jithin Emmanuel <email address hidden>wrote:

> I was using quassel. And was clicking around the Buffers section.
>
> On Fri, Jul 10, 2009 at 3:18 AM, Robert Hooker <email address hidden> wrote:
>
>> What were you doing at the time? Watching a video with Xv by any chance?
>>
>> --
>> LVDS display not returning from dpms off state on intel after a set time
>> period.
>> https://bugs.launchpad.net/bugs/390917
>> You received this bug notification because you are a direct subscriber
>> of a duplicate bug.
>>
>
>
>
> --
> Thanks
> Jithin Emmanuel
>
> Clifford Stoll<http://www.brainyquote.com/quotes/authors/c/clifford_stoll.html> - "The Internet is a telephone system that's gotten uppity."

--
Thanks
Jithin Emmanuel

Luis Bunuel <http://www.brainyquote.com/quotes/authors/l/luis_bunuel.html>
- "Age is something that doesn't matter, unless you are a cheese."

Changed in xserver-xorg-video-intel:
importance: Unknown → Critical
Changed in xserver-xorg-video-intel:
importance: Critical → Unknown
Changed in xserver-xorg-video-intel:
importance: Unknown → Critical
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.