Bug 107103 - External monitor flickering after screen turns on after inactivity
Summary: External monitor flickering after screen turns on after inactivity
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Intel GFX Bugs mailing list
QA Contact: Intel GFX Bugs mailing list
Whiteboard: Triaged, ReadyForDev
Depends on:
Reported: 2018-07-03 16:56 UTC by Jethro Beekman
Modified: 2019-11-29 17:48 UTC (History)
1 user (show)

See Also:
i915 platform: SKL
i915 features: display/atomic

dmesg logs during issue with debug=0x1e (2.15 MB, text/plain)
2018-09-05 05:05 UTC, Jethro Beekman
no flags Details

Description Jethro Beekman 2018-07-03 16:56:31 UTC
When I "wiggle the mouse" after all screens have gone off from inactivity, my external monitor sometimes starts flickering. It will show my desktop for about a second, then go black, and after a couple of seconds it will come back, and this repeats indefinitely until I restart X. Resetting the monitor (by removing and re-inserting the power cable) doesn't help. Turn off the monitor using xrandr and bringing it back on doesn't help. While the flickering is happening, the monitor shows up as connected in xrandr with the correct resolution. My laptop screen and my other external monitor are not affected. This only started happening after a recent software update.

I suspect this is a software issue as everything was working fine until I upgraded the following packages:

mesa (17.3.6-1 -> 18.1.3-1)
linux (4.15.10-1 -> 4.17.3-1)
xorg-server (1.19.6+13+gd0d1a694f-1 -> 1.20.0-9)
xf86-video-intel (1:2.99.917+812+g75795523-1 -> 1:2.99.917+831+ge7bfc906-1)

There is nothing being logged in Xorg.0.log or dmesg. Please let me know if there are any debugging steps I can perform the next time this is happening.

Hardware: Dell Latitude E7470
CPU: Intel(R) Core(TM) i7-6650U CPU @ 2.20GHz
GPU: Intel Corporation Iris Graphics 540

Laptop monitor connected on eDP1
Acer monitor connectied on DP1-1 (DVI via docking station)
Samsung TV connected on HDMI1

Distro: Arch Linux

~ $uname -a
Linux jethro 4.17.3-1-ARCH #1 SMP PREEMPT Tue Jun 26 04:42:36 UTC 2018 x86_64 GNU/Linux

~ $sudo cat /sys/class/drm/card0/error
No error state collected
Comment 1 Francesco Balestrieri 2018-07-04 10:41:42 UTC
A few things that would help the investigation:

- are you able to isolate which one of the package upgrades introduces the error, or do they all need to be updated together because of dependencies?
- can you try to reproduce with debug logs enabled (kernel options drm.debug=0x1e log_buf_len=4M?) and attach the full dmesg from boot?
- can you try to reproduce with the latest drm-tip (https://cgit.freedesktop.org/drm-tip) - assuming of course that the problem is in the kernel driver - and attach the logs as above
Comment 2 Francesco Balestrieri 2018-07-08 07:16:37 UTC
Ping reporter
Comment 3 Jethro Beekman 2018-07-08 17:27:51 UTC
Thanks for the directions. I haven't been able to reproduce the issue yet.
Comment 4 Jethro Beekman 2018-07-25 06:44:50 UTC
Haven't been able to reproduce.
Comment 5 Jethro Beekman 2018-09-05 05:05:11 UTC
Created attachment 141454 [details]
dmesg logs during issue with debug=0x1e

This just happened today.

Same hardware.

mesa 18.1.7-1
linux 4.18.5.arch1-1
xorg-server 1.20.1-1
xf86-video-intel 1:2.99.917+831+ge7bfc906-1

I didn't have the debugging active during boot, but I was able to turn it on in /sys/module/drm/parameters when it started happening. Logs attached. The first message at 21:55:21 seems to be about when I first "wiggled the mouse" to unlock my desktop. After that it took me a few minutes to find this bug with the debugging instructions.
Comment 6 Lakshmi 2018-09-05 06:37:57 UTC
(In reply to Jethro Beekman from comment #5)
> Created attachment 141454 [details]
> dmesg logs during issue with debug=0x1e
> This just happened today.
You had latest drm-tip when this happened?
Comment 7 Jethro Beekman 2018-09-06 05:27:37 UTC
Comment 8 Lakshmi 2018-09-07 12:52:35 UTC
Can you try to reproduce the error using drm-tip (https://cgit.freedesktop.org/drm-tip) and kernel parameters drm.debug=0x1e log_buf_len=4M. 
If the problem persists attach the full dmesg from boot.
Comment 9 Jethro Beekman 2018-09-09 20:02:47 UTC
If I knew how to reproduce the issue, I would definitely do that. However, this issue happenned only twice over a period of more than 2 months. I have not been able to find a specific trigger for this bug (other than that it happens after the screen turns off after inactivity). As this is my primary workstation, it's not practical for me to run with the suggested configuration indefinitely. I think that the most effective way to debug this is something I can do while the issue is occuring (which means no restarting X/rebooting).
Comment 10 Lakshmi 2018-09-17 14:33:32 UTC
Priority is set based on the no:of occurrences.
Also, dmesg from latest drmtip will always speed up the investigation.
Comment 11 Lakshmi 2019-07-15 06:27:42 UTC
Reporter, do you have the issue with drmtip (https://cgit.freedesktop.org/drm-tip)? If so, can you please attach the dmesg from boot with kernel parameters drm.debug=0x1e log_buf_len=4M.
Comment 12 Martin Peres 2019-11-29 17:48:28 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/126.

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.