Bug 97264 - [BDW] Screen blanking (DP link reset?) when working in terminals
Summary: [BDW] Screen blanking (DP link reset?) when working in terminals
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: DRI git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Intel GFX Bugs mailing list
QA Contact: Intel GFX Bugs mailing list
Depends on:
Reported: 2016-08-09 18:44 UTC by Stefano Rivera
Modified: 2018-02-13 16:30 UTC (History)
4 users (show)

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

Full dmesg, including multiple monitor blanks (86.26 KB, application/x-xz)
2016-08-09 18:44 UTC, Stefano Rivera
no flags Details
xrandr --verbose (23.79 KB, text/plain)
2016-08-09 18:45 UTC, Stefano Rivera
no flags Details

Description Stefano Rivera 2016-08-09 18:44:55 UTC
Created attachment 125648 [details]
Full dmesg, including multiple monitor blanks

Reported in Debian too: https://bugs.debian.org/833478

Hardware: Lenovo X250 (Intel Broadwell-U Integrated Graphics), with 2x Dell U2713HM connected via docking station's Display Ports.

Software: Debian amd64, with Debian Linux kernel 4.6.0-1 and with drm-intel-next-2016-08-08.

Since upgrading to the modesetting driver, the monitor I'm currently focussed on often goes blank for a second, while I'm working. The others are unaffected. I'm assuming that the Display Port connection is resetting, because if I have a monitor menu up, when triggering the bug, it gets closed, as the screen blanks. Nothing gets logged.

It seems to be usually caused by opening a terminal or pressing a key in a terminal just after switching focus, but I can't explain any of that :)

It seems to happen less often if I turn one of the 3 monitors off. And I've never seen it happen on the internal eDP panel, only on the DP Dell monitors.

Using the intel driver avoids the problem, but it seems to have picked up other odd rendering bugs around the same time. Windows flicker between previous and old contents.

With drm.debug=0x1e on drm-intel-next-2016-08-08 I see these events appear when a monitor blanks:

[   68.609827] [drm:drm_atomic_state_init] Allocated atomic state ffff8804244c5000
[   68.609843] [drm:drm_atomic_get_plane_state] Added [PLANE:29:cursor B] ffff8804246b5180 state to ffff8804244c5000
[   68.609848] [drm:drm_atomic_get_crtc_state] Added [CRTC:30:pipe B] ffff880410ee9000 state to ffff8804244c5000
[   68.609850] [drm:drm_atomic_set_crtc_for_plane] Link plane state ffff8804246b5180 to [NOCRTC]
[   68.609853] [drm:drm_atomic_set_fb_for_plane] Set [NOFB] for plane state ffff8804246b5180
[   68.609855] [drm:drm_atomic_check_only] checking ffff8804244c5000
[   68.609862] [drm:intel_plane_atomic_calc_changes] [CRTC:30:pipe B] has [PLANE:29:cursor B] with fb -1
[   68.609865] [drm:intel_plane_atomic_calc_changes] [PLANE:29:cursor B] visible 1 -> 0, off 1, on 0, ms 0
[   68.609871] [drm:drm_atomic_commit] commiting ffff8804244c5000
[   68.609904] [drm:drm_atomic_state_default_clear] Clearing atomic state ffff8804244c5000
[   68.609908] [drm:drm_atomic_state_free] Freeing atomic state ffff8804244c5000
Comment 1 Stefano Rivera 2016-08-09 18:45:25 UTC
Created attachment 125649 [details]
xrandr --verbose
Comment 2 Cedric M 2016-10-25 09:45:38 UTC
Hi there,

I'm having the exact same issue with a Dell XPS 13 (9343 // i7-5600U broadwell, 3200x1800 panel) laptop, directly attached to an external Dell P2715Q 4K (3840x2160 @60Hz) via DP.

The 4K external screen is flickering when doing light activity -- easily reproduced indeed when using an X terminal.

Steps to reproduce:
- open side by side Firefox (or Chrome) + a terminal and/or a gvim window on the external 4K screen
- do some light web browsing
- give focus to the X terminal or gvim
  // at this point, display is still perfectly steady
- press a key to enter a single character
  // as soon as the key is pressed, external screen goes black for a few seconds. Laptop screen is not affected.
- Wait for the screen to come back, then continue typing
  // screen generally stays ON, but sometimes continues to flicker a few times in next minute.

This happens almost every time I switch to the terminal window and start typing.

OS specs:
- Ubuntu 16.10 running Unity, modesetting Xorg driver
- kernel 4.8.0. Issue is still present with 4.9.0rc1.

Tried i915.enable_psr=0|2|3 and i915.enable_rc6=0, doesn't solve the issue.

dmesg output shows the following message right after boot:
[drm:gen8_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun
Comment 3 Jani Saarinen 2016-12-09 10:51:26 UTC
Is this issue still seen with latest kernel?
Comment 4 Cedric M 2016-12-09 14:11:02 UTC
Yes, issue is still seen on 4.9.0-rc8.
Comment 5 Cedric M 2016-12-13 09:15:55 UTC
One more thing: the issue happens on the 4K screen when running it at native resolution (3840x2160 @60Hz).

Just tried to switch it to lower 1920x1080 @60Hz resolution: issue doesn't seem to happen in that case.

3200x1800 laptop panel + 4K@60Hz external screen is a lot of pixels -- may be close to some GPU/driver limits?

However, no issue under Windows.
The Xorg intel driver doesn't show this issue either (but regularly freezes when dealing with large images though).
Comment 6 Cedric M 2017-01-10 15:12:57 UTC
Still seen with Ubuntu kernel 4.10.0-041000rc3-generic
Comment 7 Timo Kalliomäki 2017-02-14 10:51:21 UTC

I seem to be having the same problem with the i7-5600U Dell E7450 (BIOS A13, MST firmware 3.10.1) and Dell P2175Q rev. A03 display (MST off, DDC/CI off). For me, the reproduction steps are:

1. Output picture to both internal monitor and external DP-linked one (everything is OK if only the external or only the internal one is in use)
2. Set external monitor to a large resolution, eg. 3840x2160@60Hz, 3840x2160@30Hz, 2560x1440 (1920x1080 seems to not exhibit this behavior but I did not test for an extended period)
3. Bring mouse cursor to external screen and position it over a window (everything is OK as long as cursor is kept on internal monitor)
4. Give focus to the window from step 3 (this seems to vary by program; Firefox being the program getting focus does not cause problems, but eg. Konsole or Kate does)
5. Press a key on the keyboard (even Ctrl alone will do)
=> maybe half the time, the key press causes the external monitor losing signal for a second or so. Signal loss confirmed via observing the monitor OSD.

The problem was present both in the 4.8 kernels of Kubuntu 16.10, as well as 4.9.2 and 4.9.6 of Debian Stretch.

The drm_atomic messages always show up in dmesg on step 5, but they seem similar to me for both problematic and unproblematic cases.

No signal loss:
[  588.715676] [drm:drm_atomic_state_init [drm]] Allocated atomic state ffffa0692aab3800
[  588.715701] [drm:drm_atomic_get_plane_state [drm]] Added [PLANE:29:cursor B] ffffa06a09f02180 state to ffffa0692aab3800
[  588.715719] [drm:drm_atomic_get_crtc_state [drm]] Added [CRTC:30:pipe B] ffffa06a0bbae800 state to ffffa0692aab3800
[  588.715733] [drm:drm_atomic_set_crtc_for_plane [drm]] Link plane state ffffa06a09f02180 to [NOCRTC]
[  588.715744] [drm:__drm_atomic_helper_disable_plane [drm_kms_helper]] Set [NOFB] for plane state ffffa06a09f02180
[  588.715758] [drm:drm_atomic_check_only [drm]] checking ffffa0692aab3800
[  588.715801] [drm:intel_plane_atomic_calc_changes [i915]] [CRTC:30:pipe B] has [PLANE:29:cursor B] with fb -1
[  588.715832] [drm:intel_plane_atomic_calc_changes [i915]] [PLANE:29:cursor B] visible 1 -> 0, off 1, on 0, ms 0
[  588.715853] [drm:drm_atomic_commit [drm]] commiting ffffa0692aab3800
[  588.715896] [drm:drm_atomic_state_default_clear [drm]] Clearing atomic state ffffa0692aab3800
[  588.715915] [drm:drm_atomic_state_free [drm]] Freeing atomic state ffffa0692aab3800
[  588.723720] [drm:drm_mode_addfb2 [drm]] [FB:87]
[  588.747072] [drm:drm_mode_addfb2 [drm]] [FB:90]

Signal loss:
[  609.115830] [drm:drm_atomic_state_init [drm]] Allocated atomic state ffffa06a065a1000
[  609.115864] [drm:drm_atomic_get_plane_state [drm]] Added [PLANE:29:cursor B] ffffa069d18d9840 state to ffffa06a065a1000
[  609.115891] [drm:drm_atomic_get_crtc_state [drm]] Added [CRTC:30:pipe B] ffffa06a08582000 state to ffffa06a065a1000
[  609.115911] [drm:drm_atomic_set_crtc_for_plane [drm]] Link plane state ffffa069d18d9840 to [NOCRTC]
[  609.115928] [drm:__drm_atomic_helper_disable_plane [drm_kms_helper]] Set [NOFB] for plane state ffffa069d18d9840
[  609.115953] [drm:drm_atomic_check_only [drm]] checking ffffa06a065a1000
[  609.116016] [drm:intel_plane_atomic_calc_changes [i915]] [CRTC:30:pipe B] has [PLANE:29:cursor B] with fb -1
[  609.116062] [drm:intel_plane_atomic_calc_changes [i915]] [PLANE:29:cursor B] visible 1 -> 0, off 1, on 0, ms 0
[  609.116095] [drm:drm_atomic_commit [drm]] commiting ffffa06a065a1000
[  609.116154] [drm:drm_atomic_state_default_clear [drm]] Clearing atomic state ffffa06a065a1000
[  609.116177] [drm:drm_atomic_state_free [drm]] Freeing atomic state ffffa06a065a1000
[  609.124994] [drm:drm_mode_addfb2 [drm]] [FB:87]
[  609.148166] [drm:drm_mode_addfb2 [drm]] [FB:90]

Also, on boot I get the message
kernel: [drm:gen8_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun
Comment 8 Jani Saarinen 2017-03-08 07:47:17 UTC
With latest changes on atomic/watermark work can you test this with latest drm-tip if still valid?
Comment 9 Cedric M 2017-03-08 11:41:38 UTC

I have been playing with drm-tip for an hour: so far so good! :)

Comment 10 Jani Saarinen 2017-05-22 09:57:10 UTC
Just checking if issue still valid or can be closed?
Comment 11 Cedric M 2017-05-22 10:02:59 UTC

Issue is fixed for me in 4.11 drm-tip, thanks!

However it seems that it hasn't been merged into mainline kernel yet? (at least that wasn't the case in 4.12rc1 IIRC)
Comment 12 Jani Saarinen 2017-05-24 06:12:32 UTC
Thanks. Resolving. Jani / Daniel to comment when in 4.12 etc..
Comment 13 Elizabeth 2018-02-13 16:29:52 UTC
Closing old verified.

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.