Bug 94014 - Failure to wake monitor after sleep on Haswell graphics driver under 4.4.1
Summary: Failure to wake monitor after sleep on Haswell graphics driver under 4.4.1
Status: CLOSED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: XOrg git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Intel GFX Bugs mailing list
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-02-05 21:45 UTC by John
Modified: 2017-07-24 22:43 UTC (History)
7 users (show)

See Also:
i915 platform: HSW
i915 features: power/suspend-resume


Attachments
Xorg.0.log after the monitor will now wake up (26.98 KB, text/plain)
2016-02-05 21:45 UTC, John
no flags Details
dmesg with debug flag enabled (1002.90 KB, text/plain)
2016-02-05 21:46 UTC, John
no flags Details
fresh boot, monitor off after several min will not wake up (27.74 KB, application/x-gzip)
2016-03-09 20:21 UTC, John
no flags Details
possible fix (2.09 KB, patch)
2016-05-07 16:36 UTC, Luke
no flags Details | Splinter Review
hdmi status logging (1.57 KB, text/plain)
2016-05-07 16:37 UTC, Luke
no flags Details
Updated fix - force live status to TRUE for generation 7 (1.19 KB, patch)
2016-05-23 21:57 UTC, Luke
no flags Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description John 2016-02-05 21:45:48 UTC
Created attachment 121542 [details]
Xorg.0.log after the monitor will now wake up

I am running 4.4.1 on Arch x86_64 and have noticed that this update (coming from 3.4.5) causes the monitor to not wake up from sleep state. I have to `systemctl restart display-manager` in order to revive the Xorg display.

Exact symptoms:
1) Leave monitor on and wait for power savings to kick it/LED on monitor is blue.
2) Power savings kick it and LED goes amber and screen goes to sleep.
3) Hit any key to wake up the monitor.  LED goes blue, but "no signal" is displayed on the screen.
4) LED goes amber again.

This is 100% reproducible (I have confirmed 4 times in a row).

This machine is an Intel i7-4790K (Haswell) using the onboard graphics chip connected to the monitor via HDMI.  The motherboard is an MSI Z97 Mpower Max AC using the latest BIOS.  I am using the distro provided drivers (xf86-video-intel 1:2.99.917+519+g8229390).  I am glad to provide additional debug info upon request.

The attached dmesg includes the 'log_buf_len=1M' kernel parameter which seems to have eclipsed the initial lines of my dmesg output.  I attached my full /var/log/Xorg.log as well.

Note that I have tried letting xscreensaver control the power state of the monitor or letting xfce4 power manager do it and I am left with the same result described above.  Downgrading to kernel 4.3.5 with no other changes solves the problem.
Comment 1 John 2016-02-05 21:46:14 UTC
Created attachment 121543 [details]
dmesg with debug flag enabled
Comment 2 John 2016-02-05 22:09:18 UTC
I neglected to mention that if I ssh into the box after the bug occurs, /sys/class/drm/card0/error returns no errors.

# cat /sys/class/drm/card0/error
no error state collected
Comment 3 John 2016-02-28 23:36:39 UTC
I am still experiencing this under 4.4.3.  Is the lack of attention to the report due to incomplete data on my part?  Is there something else I need to include to get this into the hands of the right people?  Thanks!
Comment 4 Jani Nikula 2016-03-08 11:15:07 UTC
Please attach dmesg again all the way from boot, with drm.debug=14 module parameter set.
Comment 5 John 2016-03-09 20:21:45 UTC
Created attachment 122185 [details]
fresh boot, monitor off after several min will not wake up
Comment 6 John 2016-03-09 20:22:43 UTC
Attached.  Thank you!  Note - Bug is present in 4.4.4 and under 4.5-rc7.
Comment 7 John 2016-03-09 23:35:31 UTC
@Jani - Is this related to the bug#94024?  Your comment there[1] is echoed in the recent dmesg I posted.

% grep Live dmesg_with_debug_flags                                                                 :(
[    0.582711] [drm:intel_hdmi_detect] Live status not up!
[    0.752726] [drm:intel_hdmi_detect] Live status not up!
[    5.739370] [drm:intel_hdmi_detect] Live status not up!
[  303.456558] [drm:intel_hdmi_detect] Live status not up!
[  303.563225] [drm:intel_hdmi_detect] Live status not up!
[  316.623147] [drm:intel_hdmi_detect] Live status not up!
[  317.973124] [drm:intel_hdmi_detect] Live status not up!
[  318.093122] [drm:intel_hdmi_detect] Live status not up!
[  318.199787] [drm:intel_hdmi_detect] Live status not up!
[  318.383118] [drm:intel_hdmi_detect] Live status not up!


1. https://bugs.freedesktop.org/show_bug.cgi?id=94024#c6
Comment 8 John 2016-03-15 11:58:22 UTC
I started to do a git bisect on this.  I post the log here.  Note that commit 8b417c266b715b3797cd3e65342149372b9ac0c8 does wake up as expected but it also wakes-up spontaneously and I think my choice of "good" for it was probably bad in retrospect.  I hope this helps narrow it down.


% git bisect log
git bisect start
# good: [6a13feb9c82803e2b815eca72fa7a9f5561d7861] Linux 4.3
git bisect good 6a13feb9c82803e2b815eca72fa7a9f5561d7861
# bad: [afd2ff9b7e1b367172f18ba7f693dfb62bdcb2dc] Linux 4.4
git bisect bad afd2ff9b7e1b367172f18ba7f693dfb62bdcb2dc
# good: [f66477a0aeb77f97a7de5f791700dadc42f3f792] Merge tag 'clk-for-linus-20151104' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux
git bisect good f66477a0aeb77f97a7de5f791700dadc42f3f792
# bad: [56e0464980febfa50432a070261579415c72664e] Merge tag 'armsoc-soc' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
git bisect bad 56e0464980febfa50432a070261579415c72664e
# good: [22402cd0af685c1a5d067c87db3051db7fff7709] Merge tag 'trace-v4.4' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace
git bisect good 22402cd0af685c1a5d067c87db3051db7fff7709
# bad: [816d2206f0f9953ca854e4ff1a2749a5cbd62715] Merge tag 'drm-intel-next-fixes-2015-11-06' of git://anongit.freedesktop.org/drm-intel into drm-next
git bisect bad 816d2206f0f9953ca854e4ff1a2749a5cbd62715
# bad: [26148bd3c0f1fbd8f2b0dae994f3195316f677db] drm/i915/bxt: Set time interval unit to 0.833us
git bisect bad 26148bd3c0f1fbd8f2b0dae994f3195316f677db
# bad: [7b24c9a696c1c68eaa471a27bf467e97a9986fa9] drm/i915: don't enable FBC when pixel rate exceeds 95% on HSW/BDW
git bisect bad 7b24c9a696c1c68eaa471a27bf467e97a9986fa9
# bad: [85a62bf9d8ef8d533635270ae985281c58e8c974] drm/i915: Also record time difference if vblank evasion fails, v2.
git bisect bad 85a62bf9d8ef8d533635270ae985281c58e8c974
# bad: [901c2daf05c8ae6c3f85370fc96b9b6892f5da2d] drm/i915: Put back lane_count into intel_dp and add link_rate too
git bisect bad 901c2daf05c8ae6c3f85370fc96b9b6892f5da2d
# good: [cf1d58833f07afbb4534b15caa3fd48baa313b2c] drm/i915/bxt: WA for swapped HPD pins in A stepping
git bisect good cf1d58833f07afbb4534b15caa3fd48baa313b2c
# good: [919f1f55d90b5487a9f38e94842e486509474f09] drm/i915: Expose one LRC function for GuC submission mode
git bisect good 919f1f55d90b5487a9f38e94842e486509474f09
# good: [8b417c266b715b3797cd3e65342149372b9ac0c8] drm/i915: Debugfs interface for GuC submission statistics
git bisect good 8b417c266b715b3797cd3e65342149372b9ac0c8
# good: [f1afe24f0e736b9d7f2275e2b1504af3fe612f2a] drm/i915: Change SRM, LRM instructions to use correct length
git bisect good f1afe24f0e736b9d7f2275e2b1504af3fe612f2a
Comment 9 John 2016-03-15 12:25:39 UTC
OK... I went back flagged cf1d58833f07afbb4534b15caa3fd48baa313b2c bad since the monitor would wake up on its own... ie without keyboard or mouse input.  I am continuing to bisect and will only flag good if the monitor sleeps and wakes as expected, not just wakes as expected.  Please disregard my comment #8.  I will update accordingly shortly.
Comment 10 John 2016-03-15 13:40:36 UTC
OK... I finished the bisect:

09120d4e88b13967d44d46280fb74d3ac4ac2f73 is the first bad commit
commit 09120d4e88b13967d44d46280fb74d3ac4ac2f73
Author: Michel Thierry <michel.thierry@intel.com>
Date:   Wed Jul 29 17:23:45 2015 +0100

    drm/i915: Remove unnecessary gen8_clamp_pd
    
    gen8_clamp_pd clamps to the next page directory boundary, but the macro
    gen8_for_each_pde already has a check to stop at the page directory
    boundary.
    
    Furthermore, i915_pte_count also restricts to the next page table
    boundary.
    
    v2: Rebase after Mika's ppgtt cleanup / scratch merge patch series.
    
    Suggested-by: Akash Goel <akash.goel@intel.com>
    Signed-off-by: Michel Thierry <michel.thierry@intel.com>
    Reviewed-by: "Akash Goel" <akash.goel@intel.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

:040000 040000 d5ad200fb348cab8518d6f7efdf9a15dcde161b8 0f9248add7ae0d95a7e17fd1a0c975b577245fd0 M	drivers


% git bisect log
git bisect start
# good: [6a13feb9c82803e2b815eca72fa7a9f5561d7861] Linux 4.3
git bisect good 6a13feb9c82803e2b815eca72fa7a9f5561d7861
# bad: [afd2ff9b7e1b367172f18ba7f693dfb62bdcb2dc] Linux 4.4
git bisect bad afd2ff9b7e1b367172f18ba7f693dfb62bdcb2dc
# good: [f66477a0aeb77f97a7de5f791700dadc42f3f792] Merge tag 'clk-for-linus-20151104' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux
git bisect good f66477a0aeb77f97a7de5f791700dadc42f3f792
# bad: [56e0464980febfa50432a070261579415c72664e] Merge tag 'armsoc-soc' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
git bisect bad 56e0464980febfa50432a070261579415c72664e
# good: [22402cd0af685c1a5d067c87db3051db7fff7709] Merge tag 'trace-v4.4' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace
git bisect good 22402cd0af685c1a5d067c87db3051db7fff7709
# bad: [816d2206f0f9953ca854e4ff1a2749a5cbd62715] Merge tag 'drm-intel-next-fixes-2015-11-06' of git://anongit.freedesktop.org/drm-intel into drm-next
git bisect bad 816d2206f0f9953ca854e4ff1a2749a5cbd62715
# bad: [26148bd3c0f1fbd8f2b0dae994f3195316f677db] drm/i915/bxt: Set time interval unit to 0.833us
git bisect bad 26148bd3c0f1fbd8f2b0dae994f3195316f677db
# bad: [7b24c9a696c1c68eaa471a27bf467e97a9986fa9] drm/i915: don't enable FBC when pixel rate exceeds 95% on HSW/BDW
git bisect bad 7b24c9a696c1c68eaa471a27bf467e97a9986fa9
# bad: [85a62bf9d8ef8d533635270ae985281c58e8c974] drm/i915: Also record time difference if vblank evasion fails, v2.
git bisect bad 85a62bf9d8ef8d533635270ae985281c58e8c974
# bad: [901c2daf05c8ae6c3f85370fc96b9b6892f5da2d] drm/i915: Put back lane_count into intel_dp and add link_rate too
git bisect bad 901c2daf05c8ae6c3f85370fc96b9b6892f5da2d
# bad: [cf1d58833f07afbb4534b15caa3fd48baa313b2c] drm/i915/bxt: WA for swapped HPD pins in A stepping
git bisect bad cf1d58833f07afbb4534b15caa3fd48baa313b2c
# bad: [e1f123257a1f7d3af36a31a0fb2d4c6f40039fed] drm/i915: Expand error state's address width to 64b
git bisect bad e1f123257a1f7d3af36a31a0fb2d4c6f40039fed
# bad: [81ba8aefd03803a8aec3395d18f7b1dda5942105] drm/i915/gen8: Add PML4 structure
git bisect bad 81ba8aefd03803a8aec3395d18f7b1dda5942105
# bad: [d4ec9da0e17cb6a86c0b76c5b254981601d25031] drm/i915/gen8: Abstract PDP usage
git bisect bad d4ec9da0e17cb6a86c0b76c5b254981601d25031
# bad: [6ac1850220732f47bc6ae767fa41542009674ad7] drm/i915/gen8: Make pdp allocation more dynamic
git bisect bad 6ac1850220732f47bc6ae767fa41542009674ad7
# bad: [09120d4e88b13967d44d46280fb74d3ac4ac2f73] drm/i915: Remove unnecessary gen8_clamp_pd
git bisect bad 09120d4e88b13967d44d46280fb74d3ac4ac2f73
# first bad commit: [09120d4e88b13967d44d46280fb74d3ac4ac2f73] drm/i915: Remove unnecessary gen8_clamp_pd
Comment 11 John 2016-03-16 20:16:41 UTC
I am issuing the following command to force the monitor to go into sleep mode: xset dpms force suspend


I am repeating the bisect and am now on commit 85a62bf...

Booted into the this kernel, the monitor did not go to sleep 2 out of 5 times but it did wake up correctly 3 of 3 times.  Should that be considered a "good" or a "bad" commit?
Comment 12 Brownout 2016-03-16 20:45:34 UTC
I'm getting the same behavior on Fedora 23 (4.4.4-301.fc23.x86_64, but these issues started with a previous 4.4 kernel), Ivy Bridge with integrated Intel HD Graphics 2500, monitor on HDMI, xorg-x11-drv-intel-2.99.917-19.20151206 from Fedora.

Xorg.0.log shows this line while switching from a text VTY to display :0
(EE) intel(0): sna_mode_shutdown_crtc: invalid state found on pipe 0, disabling CRTC:21

I've already tried to wake up the monitor via xset dpms to no avail.
I noticed that if the monitor is already powered up while resuming from suspend to memory it will exit from standby mode, otherwise it'll stay "no signal/power save" until X is killed.
Comment 13 John 2016-03-17 19:14:16 UTC
Brownout - I do not get the same error message you are seeing so your bug might not be exactly the same as this one.  Which DE are you using?
Comment 14 Brownout 2016-03-17 19:39:00 UTC
John, I'm using XFCE4, I landed here from the bug request you opened on the kernel and Arch:
https://bugs.archlinux.org/task/47997
https://bugzilla.kernel.org/show_bug.cgi?id=111831

both are mentioning the same error message.
Comment 15 John 2016-03-17 19:46:33 UTC
OK.  Seems like it is the kernel + xfce4.  When I tried under gnome and it works as expected.
Comment 16 John 2016-03-19 21:18:34 UTC
The best I can do to describe this bug is that something in the kernel (?) has changed between 4.3.6 and 4.4 where once the monitor goes to sleep, and it is awakened by a key press or mouse movement, it wakes-up but doesn't find any active video signal, so the monitor happily goes back to sleep.  What do people feel about my bisect in comment #10?  Does this help to pin-point anything?
Comment 17 Brownout 2016-04-25 11:43:14 UTC
I can confirm that downgrading to kernel 4.3 solves the issue.
I must also add that even turning off the display triggers the problem, as it remains in sleep mode after turning it back on, killing X brings it back to life.
Comment 18 Luke 2016-05-06 21:37:12 UTC
I'm getting something very similar.

Older 4.2 kernels are fine, but with 4.3 onwards, once the monitor has been turned off by the screensaver (under xfce4), it can't ever be woken up again.

Switching to a VT partially fixes it (I can see the VT) but the only way to get X working again is /etc/init.d/xdm restart.

This is on Gentoo, with:

00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller (rev 06)

And an Acer G246HYL 1080p HDMI monitor.

Doing some bisecting, I came up with this change:

   237ed86 drm/i915: Check live status before reading edid

That change modifies the way that intel_hdmi_detect() waits for HDMI hotplug to complete. Before this change I think it just kind of ignored the HPD but now it seems to care whether it came up or not.

That change was itself in turn later on fixed up in:

   f8d03ea drm/i915: increase the tries for HDMI hotplug live status checking

But I wonder if perhaps my monitor is just being too slow even for that. I tried playing around with the timeout and seemed to improve things, but not actually fixed them (it now works about 50% of the time vs. previously none of the time).
Comment 19 Luke 2016-05-07 16:36:32 UTC
Created attachment 123537 [details] [review]
possible fix
Comment 20 Luke 2016-05-07 16:37:12 UTC
Created attachment 123538 [details]
hdmi status logging
Comment 21 Luke 2016-05-07 16:38:58 UTC
Attachment 123537 [details] fixes the problem for me. It's a patch against 4.6rc4 and I've been using it today without seeing the usual black screen problem.

I put some tracing in an earlier version of the result of trying to get the HPD status. It shows that it either succeeds immediately, or times out after 90ms. I find that a bit bizarre; I think I don't really understand what the calling code is doing with this function.
Comment 22 yann 2016-05-11 10:27:24 UTC
John, can you re-test using Luke's fix and confirm that you are not reproducing the issue?
Comment 23 Luke 2016-05-16 06:47:54 UTC
I think there may be a couple of problems here.

What I'm seeing is that before my fix, once the display went off, it would never come back on.

With the fix it will now come on if I haven't left it too long but if I leave it overnight then it will always be dead. The screensaver is set to switch off after an hour (but I've had it as low as 1 minute, and it still fails overnight.

Last night I tried with the drm-intel-next branch. Kernel is checked out at:

  e3d5457 drm/i915: Ignore stale wm register values on resume on ilk-bdw (v2)

Still fails to work.
Comment 24 Luke 2016-05-20 22:28:07 UTC
I think it may be just enough to ensure live_status is always set to True.

The latest version of this function does that for generations < 7; my chipset seems to be generation 7 so I guess that one has broken HDMI HPD as well.

i.e.

-              if (INTEL_INFO(dev_priv)->gen < 7 || IS_IVYBRIDGE(dev_priv))
+              if (INTEL_INFO(dev_priv)->gen < 8 || IS_IVYBRIDGE(dev_priv))
Comment 25 Luke 2016-05-23 21:57:26 UTC
Created attachment 124010 [details] [review]
Updated fix - force live status to TRUE for generation 7

This updated patch forces live_status to TRUE for generation 7, as well as earlier generations, which was done in 4f4a818, "drm/i915: Fake HDMI live status".

This seems to completely fix the problem for me.
Comment 26 Luke 2016-05-25 21:53:37 UTC
It looks like this bug has been around for a while:

https://lists.freedesktop.org/archives/intel-gfx/2016-February/088400.html

> After a kernel bisect, it was found that reverting the following commit resolved this bug:
>
> commit 237ed86c693d8a8e4db476976aeb30df4deac74b
> Author: Sonika Jindal <sonika.jindal at intel.com>
> Date:   Tue Sep 15 09:44:20 2015 +0530
>
>     drm/i915: Check live status before reading edid
Comment 27 Luke 2016-05-25 21:55:21 UTC
Adding Sonika to comment on what should happen next with this.
Comment 28 Sonika 2016-05-26 05:18:20 UTC
Adding Shashank.

Earlier it was observed that live status was not reliable on older platforms and other issue was with the single link dvi to hdmi cable in certain cases.
Is this also with a single link cable?
If not then it is worrying that live status is not reliable even on gen7.
With gen7 VLV, we had done enough testing and found this solution pretty reliable.
Comment 29 Luke 2016-05-26 05:42:03 UTC
I'm using an HDMI/HDMI cable.

Just to confirm the generation:

It's got one of these:

> Intel(R) Core(TM) i5-4690 CPU @ 3.50GHz

lspci says:

> 00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller (rev 06)

Xorg says:

> Integrated Graphics Chipset: Intel(R) HD Graphics 4600

I put in a printk in the live_status code, which thought that it was generation 7.
Comment 30 Sonika 2016-05-26 06:20:47 UTC
(In reply to Luke from comment #29)
> I'm using an HDMI/HDMI cable.
> 
> Just to confirm the generation:
> 
> It's got one of these:
> 
> > Intel(R) Core(TM) i5-4690 CPU @ 3.50GHz
> 
> lspci says:
> 
> > 00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller (rev 06)
> 
> Xorg says:
> 
> > Integrated Graphics Chipset: Intel(R) HD Graphics 4600
> 
> I put in a printk in the live_status code, which thought that it was
> generation 7.

Can you please give the output of:
cat /sys/devices/pci0000\:00/0000\:00\:02.0/device
Comment 31 Luke 2016-05-27 06:56:25 UTC
$ cat /sys/devices/pci0000\:00/0000\:00\:02.0/device
0x0412
Comment 32 Sonika 2016-05-29 08:55:39 UTC
So the panel is taking more time to light up the live status after suspend resume.
We can bypass this check for other generations as well.
Shashank, what do u suggest?
Comment 33 shashank.sharma@intel.com 2016-05-30 05:37:34 UTC
I remember, having a flag called 'is_suspending' or 'is_resuming' from the I915 PM side, which used to indicate that system is resuming, and live_status can be slow. I would suggest to try something like that, instead of removing one more gen from live_status optimization.
Comment 34 Luke 2016-05-30 08:00:28 UTC
This problem report isn't about coming out of s2ram or s2disk. It's just about the monitor having been put into sleep, and then coming out of that.

(At least, that's my reading of the original report, and it's what's happening for me).
Comment 35 shashank.sharma@intel.com 2016-05-30 08:20:37 UTC
I am curious, Luke.
I guess the monitor can go to suspend state only when the source goes to suspend state first, or can a monitor go to sleep when there are still flips coming out of source side ? 

Shashank
Comment 36 Luke 2016-05-30 12:38:02 UTC
> I guess the monitor can go to suspend state only when the source goes to suspend state first, or 
> can a monitor go to sleep when there are still flips coming out of source side ? 

Good question. The monitor is being switched off by xscreensaver, which as far as I can tell uses DPMS, using functions called DPMSEnable() and DPMSDisable(). I don't know if those switch off the pixels or not.
Comment 37 shashank.sharma@intel.com 2016-05-31 04:07:28 UTC
Agree.
So this DPMS-off first disables display, and similarly DPMS-on enables display. We have seen similar issue where live_status register takes time to set, which sometimes block detection path. 

So if we add a flag (crtc->is_resuming) on the resume path, this might help to handle this.

Shashank
Comment 38 Luke 2016-05-31 08:25:08 UTC
Worth a try. I did try a fix where the timeout was turned up to 90ms, which worked better, but still was not completely reliable.
Comment 39 Luke 2016-07-22 18:50:59 UTC
What happens next?

Currently it's working perfectly for me with my fix, but I would kind of like it upstreamed so I don't have to keep applying it.
Comment 40 Mike 2016-07-31 08:32:06 UTC
This is happening on Intel's generation 9 as well.

cpu: i3-6100
lspci: 00:02.0 VGA compatible controller: Intel Corporation Sky Lake Integrated Graphics (rev 06)

As Luke has done, I've just done the following change to intel_hdmi.c

-		if (INTEL_INFO(dev_priv)->gen < 7 || IS_IVYBRIDGE(dev_priv))
+		if (INTEL_INFO(dev_priv)->gen < 10 || IS_IVYBRIDGE(dev_priv))

This will hopefully fix the problem for me as well but as Luke says, it would be nice if this got added upstream. 

I should know by tomorrow if this change has fixed it. The behaviour has been like this for me:
-monitor wakes up if it's been less than 1 or 2 hours
-monitor doesn't wake up the next morning, hence after a period of 8hours+ inactivity

I need to go back to a console and restart xdm in order to get the monitor to wake up in X. (using xfce as DM)

I'm running on a 4.7 kernel which is the most recent, while the live_status fix is still only valid for generations < 7.

Would have saved me some headaches if this had been fixed but ok :)
At least I'm glad this is a known issue.
Comment 41 Mike 2016-08-02 16:52:54 UTC
Update: it's been working perfectly for 2 days now, after applying the change in my previous post.
Comment 42 Luke 2016-09-06 21:07:02 UTC
Bump.
Comment 43 Jani Nikula 2016-09-07 11:57:58 UTC
Fixed by

commit 23f889bdf6ee5cfff012d8b09f6bec920c691696
Author: David Weinehall <david.weinehall@linux.intel.com>
Date:   Wed Aug 17 15:47:48 2016 +0300

    Revert "drm/i915: Check live status before reading edid"

in drm-intel-nightly. Please reopen if the problem persists with that commit.


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.