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
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
Thanks for the directions. I haven't been able to reproduce the issue yet.
Haven't been able to reproduce.
Created attachment 141454 [details]
dmesg logs during issue with debug=0x1e
This just happened today.
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.
(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?
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.
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).
Priority is set based on the no:of occurrences.
Also, dmesg from latest drmtip will always speed up the investigation.
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.