| Summary: | Monitor does not wake from sleep with Haswell/DisplayPort | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | DRI | Reporter: | Mark <tokamark> | ||||||
| Component: | DRM/Intel | Assignee: | Intel GFX Bugs mailing list <intel-gfx-bugs> | ||||||
| Status: | RESOLVED MOVED | QA Contact: | Intel GFX Bugs mailing list <intel-gfx-bugs> | ||||||
| Severity: | major | ||||||||
| Priority: | high | CC: | imre.deak, intel-gfx-bugs | ||||||
| Version: | unspecified | ||||||||
| Hardware: | x86-64 (AMD64) | ||||||||
| OS: | Linux (All) | ||||||||
| Whiteboard: | Triaged, ReadyForDev | ||||||||
| i915 platform: | HSW | i915 features: | power/suspend-resume | ||||||
| Attachments: |
|
||||||||
|
Description
Mark
2019-09-16 01:20:31 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. 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.
(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? 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.
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. (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? -- 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.