Bug 111690 - Monitor does not wake from sleep with Haswell/DisplayPort
Summary: Monitor does not wake from sleep with Haswell/DisplayPort
Status: RESOLVED MOVED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: high major
Assignee: Intel GFX Bugs mailing list
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard: Triaged, ReadyForDev
Keywords:
Depends on:
Blocks:
 
Reported: 2019-09-16 01:20 UTC by Mark
Modified: 2019-11-29 19:28 UTC (History)
2 users (show)

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


Attachments
dmesg output (125.66 KB, text/plain)
2019-09-16 21:50 UTC, Mark
no flags Details
dmesg output from boot (470.28 KB, text/plain)
2019-09-18 00:03 UTC, Mark
no flags Details

Description Mark 2019-09-16 01:20:31 UTC
Reproduction:
1. Start X-Windows with "startx".
2. Allow computer to idle until it enters sleep mode, or put computer to sleep with "systemctl suspend"
3. Monitor displays "no signal" and goes to sleep after a few seconds
4. Press any key to wake up the computer
5. Computer wakes up, but monitor remains in sleep mode

My CPU is an i7-4770 and I'm using the integrated graphics.
My monitor is an Acer B276HUL.

I only observe the problem when connected with DisplayPort. DVI-D works fine. Those are the only two connectors available on my monitor. I have no other DisplayPort monitors to test.

Recovery from sleep works when running Linux 3-series kernels (latest tried was 3.16). I have other issues with those kernels so I would like to upgrade.
I've tried kernel versions 4.0-4.8 and 5.2 and they all exhibit this problem.

Switching to virtual terminal #1 (a non-X console display) usually wakes up the monitor. I can then switch back to my X terminal. Switching back to the terminal X sometimes causes X to crash, so this is not a good work around.

If I wake up the computer very shortly after it goes to sleep (before the monitor itself enters sleep mode), the display works fine.

If I manually wake up the monitor before waking up the computer by activating the monitor's on-screen settings display, then the display works correctly. Manually waking up the monitor after the computer wakes up is no good.
Comment 1 Lakshmi 2019-09-16 14:53:51 UTC
(In reply to Mark from comment #0)
> Reproduction:
> 1. Start X-Windows with "startx".
> 2. Allow computer to idle until it enters sleep mode, or put computer to
> sleep with "systemctl suspend"
> 3. Monitor displays "no signal" and goes to sleep after a few seconds
> 4. Press any key to wake up the computer
> 5. Computer wakes up, but monitor remains in sleep mode
> 
> My CPU is an i7-4770 and I'm using the integrated graphics.
> My monitor is an Acer B276HUL.
> 
> I only observe the problem when connected with DisplayPort. DVI-D works
> fine. Those are the only two connectors available on my monitor. I have no
> other DisplayPort monitors to test.
> 
> Recovery from sleep works when running Linux 3-series kernels (latest tried
> was 3.16). I have other issues with those kernels so I would like to upgrade.
> I've tried kernel versions 4.0-4.8 and 5.2 and they all exhibit this problem.
> 
Is is 100% reproducible?

Can you verify the issue with drmtip with kernel parameters drm.debug=0x1e log_buf_len=4M. (https://cgit.freedesktop.org/drm-tip).

If the issue persists please attach dmesg from boot.
Comment 2 Mark 2019-09-16 21:50:34 UTC
Created attachment 145384 [details]
dmesg output

Steps to produce this log:
1. Reboot
2. startx
3. systemctl suspend
4. wait for monitor to sleep
5. pressed key on keyboard to wake computer (monitor stays asleep)
6. switch to VT1 (monitor wakes up)
7. capture dmesg output

Sometimes switching to VT1 does not wake the monitor. In that case switching back to the terminal running X will wake the monitor, but crashes X.

This problem is always reproducible.
Comment 3 Lakshmi 2019-09-17 07:55:04 UTC
(In reply to Mark from comment #2)
> Created attachment 145384 [details]
> dmesg output
> 
> Steps to produce this log:
> 1. Reboot
> 2. startx
> 3. systemctl suspend
> 4. wait for monitor to sleep
> 5. pressed key on keyboard to wake computer (monitor stays asleep)
> 6. switch to VT1 (monitor wakes up)
> 7. capture dmesg output
> 
> Sometimes switching to VT1 does not wake the monitor. In that case switching
> back to the terminal running X will wake the monitor, but crashes X.
> 
> This problem is always reproducible.

Is the attached dmesg id from drmtip? Can you please atttach the dmesg from boot?
Comment 4 Mark 2019-09-18 00:03:12 UTC
Created attachment 145410 [details]
dmesg output from boot

The posted logs are from drmtip.

The first was supposed to be the logs from boot, but it appears to be truncated. I must have mistyped the kernel parameter. This new file looks better.
Comment 5 Mark 2019-09-21 00:06:11 UTC
One other piece of information:

The monitor recovers from sleep correctly when the active virtual terminal is a console and not an X-windows session.
Comment 6 Lakshmi 2019-09-24 06:56:43 UTC
(In reply to Mark from comment #2)
> Created attachment 145384 [details]
> dmesg output
> 
> Steps to produce this log:
> 1. Reboot
> 2. startx
> 3. systemctl suspend
> 4. wait for monitor to sleep
> 5. pressed key on keyboard to wake computer (monitor stays asleep)
> 6. switch to VT1 (monitor wakes up)
> 7. capture dmesg output
> 
> Sometimes switching to VT1 does not wake the monitor. In that case switching
> back to the terminal running X will wake the monitor, but crashes X.
> 
> This problem is always reproducible.

Imre, Any suggestions here?
Comment 7 Martin Peres 2019-11-29 19:28:37 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/intel/issues/420.


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.