Bug 95176

Created attachment 123311 [details]
kernel-drm-debug-log

Here's a log with drm.debug=0xe

During this log, i set drm.debug to 0xe, then set i915.enable_psr to -1 (was 0). I then use the screen locker in GNOME to blank the screen; this causes the display to turn off, and when I turn the display back on psr is enabled (I checked i915_edp_psr_status before and after to verify this). The display then blinks several times, while the log prints repeated lines like

[20345.092329] sasami kernel: [drm:drm_mode_addfb2] [FB:59]
[20345.203191] sasami kernel: [drm:drm_mode_addfb2] [FB:61]

From watching the log live, I believe the blinks occurred between the line that said '59' and the line that said '61', but it's hard to tell due to possible buffering in systemd-journald.

Afterwards, I reset i915.enable_psr to 0 and set drm.debug back to 0.

If you want a complete log from boot with drm.debug enabled, let me know.

(In reply to Calvin Walton from comment #1)
> If you want a complete log from boot with drm.debug enabled, let me know.

Yes, please.

Created attachment 123324 [details]
kernel-drm-debug-log-full-boot

Here's the full boot log with drm.debug=0xe set and enable_psr unset (using default).

I boot the system, it starts gdm (wayland), I log in to gnome (wayland), then I wait for the display to blink several times.

I'm having exactly the same issue on the same hardware (Thinkpad T440p) using X11.

Possible dupe bug 95124.

This can be related to the second bug https://bugs.freedesktop.org/show_bug.cgi?id=94985 with external monitor, which is also triggered by PSR and have explicit "fifo_underrun" error messages.

does anything special triggers the flickering? suspend resume? or after dpms off when display goes off after a while and after comming back? or immediately after booting?

>So, regarding the occasional flicker, could you please check
i915.enable_psr=2 and also another boot with i915.enable_psr=3?
Occasional flickering of remains under all PSR settings, but looks like happens more often under enable_psr=2.

>does anything special triggers the flickering?
Flickering starts immediately after booting.
First flickering occurs in the same moment, when lightdm is showing up, but I think it is another bug: https://bugs.freedesktop.org/show_bug.cgi?id=95214
I just noticed following regularities (I did these tests with enable_psr=2 because flickering occurs more often with this setting and it was easier to check guesses under it):
1. During complete idling (just watching desktop with no intensive applications running in the background) flickering does not occurs for me.
2. Stable and reproducible way to see flickering for me is to run htop (in the background or not). I did following observations during running htop.
3. When glxgears runs in the background no flickering occurs.
4. During playing video (maybe in background, but necessarily unminimized) no flickering occurs.
5. Just doing CPU demanding task as calculating md5 of large files is not enough to stop flickering.

I convinced my friend with a ThinkPad X250 (Broadwell processor) to try out a 4.6-rc kernel, and he's seeing the same issue - screen occasionally flickering black - as well. I didn't have a chance to pull any debug logs on that machine.

My experience is basically the same as dnord - the screen flickering happens most often when the screen is being intermittently updated. It never happens if there's a continuous animation like a spinner or a video playing. It seems like it's most likely to happen shortly after something stops moving/changing onscreen - perhaps it's flickering when psr is activating?

I confirmed earlier that it happened with both the enable_psr=2 and enable_psr=3 modes (I tried both with a clean boot), but I had to wait longer to see a flicker happen when using the '3' mode.

Same issue on my t440p with X11

I have the same issue on the released 4.6.0, on a Dell latitude e7240.

00:02.0 VGA compatible controller: Intel Corporation Haswell-ULT Integrated Graphics Controller (rev 0b)

Here's how it looks like (see around 0:26):

https://goo.gl/photos/WQjk9nerdDiy5ckJ7

I noticed it happens on a regular basis, about once every 90-95 seconds.

Kernel 4.6.0 on device 
XPS 13 9343

/proc/cmdline:
BOOT_IMAGE=/boot/vmlinuz-linux root=UUID=... nmi_watchdog=0 net.ifnames=0 i915.enable_fbc=1 i915.enable_rc6=7 i915.enable_psr=1

Weither enable_psr is set to 1, 2 or 3 there is still flicker occasionally. How can I help to pinpoint the bug?

Created attachment 123968 [details] [review]
Patch by danvet to fix the issue

My Thinkpad T440s also was affected. The attached patch fixes the issue.

I'd like to leave it a while longer to make sure, but it looks like Daniel Vetter's patch has fixed this issue on my T440p as well.

I see it's got a CC:stable, so hopefully it'll make it into the 4.6.1 stable release…

I'm no longer having this problem with inter-drm-nightly kernel and i915.enable_psr=1 (as it includes mentioned patch "drm/i915/psr: Try to program link training times correctly"). However I'm still having frequent flickering with i915.enable_psr=2. The problem is I actually need to use i915.enable_psr=2, because it is workaround for another bug, which happening with i915.enable_psr=1 but not with i915.enable_psr=2: https://bugs.freedesktop.org/show_bug.cgi?id=94985

Hello everyone,

on my Lenovo Thinkpad X250 (i5-5200U, Broadwell-U, HD 5500), i was affected by the flickering, just as the Bug describes. This has been fixed with the patch by danvet in attachment 123968 [details] [review].

I do hope that this patch gets included in 4.6.1.

Thank you for your work, have a nice day,
Michael

Oh, no. Jubilation was premature! Screen is still flickering on Thinkpad T440p, but very-very rarely (like once in a hour or ten minutes) with i915.enable_psr=1. And rather frequently with i915.enable_psr=2, which indicates that problem was not eradicated completely. I'm currently testing with second VGA monitor attached, if it matters.

@dnord, i915.enable_psr=2 is not expected to work for HSW/BDW at this point. We still have to figure out why your VGA monitor flickers with i915.enable_psr=1. It does seem like a different issue.

>Screen is still flickering on Thinkpad T440p, but very-very rarely
Disregard that, I think it is another problem introduced by unstable changes in intel-drm-nightly build I use, blinking is now happens non-regularly and prints stack traces about drm_atomic when occurs.

I can confirm that danvet's patch fixes PSR on my Broadwell laptop (Dell XPS 13 [9343], i5-5200U, HD 5500 Graphics). 

With an unpatched 4.6.0 kernel, the built-in display would flicker every few minutes, sometimes more often. With danvet's patch, it hasn't flickered once. 

I don't use an external monitor so I can't speak to those issues.

dell xps 13 9343, kernel 4.6 patched, enable_psr=1, no flicker.

I noticed a glitch that happens after the display switched off by DPMS (display power management signaling). The device was not suspended (s1) and is still on (s0). After the display is awaken by pressing a key/touching touchpad the old content of the frame buffer is used until the device is put into S1 after that it behaves normally again. Until then the display only updates its contents once after each tap on the touchpad. This glitch does not happen with enable_psr=0.

It still flickers incidentally on my Broadwell-U, HD 5500 with kernel 4.6.1 and https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/patch/?id=03b7b5f983091bca17e9c163832fcde56971d7d1 patch although more rarely like with enable_psr=3 before (or maybe even less but still)

Additional info: Kde, kwin_x11, modesetting driver
cat /sys/kernel/debug/dri/0/i915_edp_psr_status
ink_Support: yes
Source_OK: yes
Enabled: yes
Active: yes
Busy frontbuffer bits: 0x000
Re-enable work scheduled: no
Main link in standby mode: no
HW Enabled & Active bit: yes
Performance_Counter: 1603397

The flickering appears random, sometimes there are none in a long period of time, sometimes twice in a couple of seconds.

Jason Mamoa: Аre you getting additional error messages in dmesg? I had irregular flickering with some of intel-drm-nightly kernels, which had patch included, but it was a new issue. Check if it is still psr-related.

As described above I'm using stable kernel 4.6.1 + patch, not drm-nightly. After disabling psr flickering is gone.

I noticed following lines in dmesg which I think correlates with flickers:

[drm:intel_dp_set_drrs_state] eDP Refresh Rate set to : 40Hz
[drm:intel_dp_set_drrs_state] eDP Refresh Rate set to : 60Hz

I was having the same flicker issue with 4.6.0 on i7-4600U (Haswell). Now I'm running 4.7-rc1 and have not noticed it anymore.

# cat /sys/kernel/debug/dri/0/i915_edp_psr_status 
Sink_Support: yes
Source_OK: yes
Enabled: yes
Active: no
Busy frontbuffer bits: 0x000
Re-enable work scheduled: yes
Main link in standby mode: no
HW Enabled & Active bit: no
Performance_Counter: 15336055

Yes, 4.7-rc1 kernel apparently fixes it indeed. So it's something more than just one patch then.

For me, 4.6.2 fixed this issue on the Thinkpad x250 i am using. If someone can confirm that this is also fixed with 4.6.2, we can close this bug :)

I am on 4.6.2 and I still have this issue. I have to boot with enable_psr=0 otherwise my screen turn off and on every few seconds.

00:02.0 VGA compatible controller: Intel Corporation 4th Gen Core Processor Integrated Graphics Controller (rev 06)

To follow up with my experiences:

I've tried Daniel Vetter's patch as attached to this issue, both standalone on top of 4.6.1 and as it was merged into 4.6.2.

This patch, by itself, significantly reduces but does not eliminate the occasional black 'flicker'. At this point, the rate is reduced sufficiently that the system's actually usable - I maybe see one or two flickers over about half an hour of typical usage, rather than several per minute. Using i915.enable_psr=0 still makes them go away completely.

Thanks for updating the results. Can you try these patches that are not present in 4.6.2- https://patchwork.freedesktop.org/series/8046/ ?

It looks like 4.6.2 + https://patchwork.freedesktop.org/series/8046/ works for me.

I don't see any flickering at all. Will confirm after a few days of testing.

Great! Can you also run "watch -n 0.1 cat /sys/kernel/debug/dri/0/i915_edp_psr_status" on a second display or ssh? I am curious if PSR is getting activated with these patches.

*** Bug 96277 has been marked as a duplicate of this bug. ***

It looks like something very strange happens. I'm not sure whether it's caused by patches or it's just mainline 4.6.2 behavior. 

I've docked my t440p laptop to dock with external monitor connected and configured internal eDP as secondary.

And got followed: https://youtu.be/kfiqEOpQ1do

So I'm getting flickering on external monitor. But when I'm displaying watch -n 0.1 cat /sys/kernel/debug/dri/0/i915_edp_psr_status everything seems to be ok.

Also when I'm typing something flickering stops for a while.

dmesg contains followed:
[23279.278108] [drm:intel_set_cpu_fifo_underrun_reporting [i915]] *ERROR* uncleared fifo underrun on pipe B
[23279.278119] [drm:ironlake_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun
[23393.451412] [drm:intel_set_cpu_fifo_underrun_reporting [i915]] *ERROR* uncleared fifo underrun on pipe B
[23393.451422] [drm:ironlake_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun

I've confirmed (with watch cat /sys/kernel/debug/dri/0/i915_edp_psr_status) that PSR is still being activated on my T440p with https://patchwork.freedesktop.org/series/8046/ applied.

I'd like to give it another day or so of testing to make sure, but it seems like the flicker on the internal screen is gone.

I'm presently using this system docked ("Ultra" dock with internal DP hub) with multiple external DP & HDMI monitors, and the internal screen disabled, and I'm not seeing any issues on the external screens like Dmitry has. I'll give it a try with the internal display enabled to see if I hit the same thing. I would imagine the corrupted display on external monitor is probably unrelated to this eDP PSR issue, though.

With internal screen disabled everything seems to be OK with docked monitors (both with or without patches).

When I re-enable the internal display on my T440p I have the following display configuration:

- eDP internal display (1920x1080)
- Thinkpad Ultra dock
 |- DP monitor (2560x1440)
 \- HDMI monitor (1920x1080)

Immediately after enabling this configuration, the kernel log printed:
[17481.417387] [drm:intel_set_cpu_fifo_underrun_reporting] *ERROR* uncleared fifo underrun on pipe B
[17481.417392] [drm:intel_cpu_fifo_underrun_irq_handler] *ERROR* CPU pipe B FIFO underrun

(I don't presently have any debug logging enabled, will retest with that later)

and the external DP monitor started blanking out for longish periods of time, up to several seconds (moving the mouse would usually cause the picture to re-appear.

The external HDMI monitor didn't blank completely, but did appear to lose sync or display corrupted picture - e.g. horizontal offset, shaking picture.

Disabling psr (with the option i915.enable_psr=0 option) fixes this completely.

Blinking of external monitor due to psr looks similar to https://bugs.freedesktop.org/show_bug.cgi?id=94985. Check if it is gone with enable_psr=2 as in that bug.

Does http://patchwork.freedesktop.org/patch/msgid/1466162081-12042-1-git-send-email-mika.kahola@intel.com make a difference?

Mika's patch at https://patchwork.freedesktop.org/patch/93927/ doesn't appear to apply on top of 4.6.2 with or without the series https://patchwork.freedesktop.org/series/8046/ applied; is there a different base kernel or branch I should be using?

Just try reverting these, it's the same thing:

5fa836a9d859 ("drm/i915: DP link training optimization")
4e96c97742f4 ("drm/i915: eDP link training optimization")

I have a new-ish MSI laptop. With no kernel option set (I'm using a gentoo 4.6.3 kernel atm), the screen flickers rapidly, unless the mouse is moving (in which case the screen is steady). If I set i915.enable_psr=0 in the kernel options at boot, the screen does not flicker, but it also does not update *at all* unless I move the mouse. That is:

1) type some commands and hit enter → nothing changes on screen
2) move the mouse → the screen updates, showing that the commands have run and showing output.

Both of these states (ie, flickers, or no flicker but also no refresh, unless the mouse is moving) render my laptop more or less unusable. What are the other possible ways to fix this? Does danvert's patch resolve the issue?

(In reply to ExecutorElassus from comment #44)
> I have a new-ish MSI laptop. With no kernel option set (I'm using a gentoo
> 4.6.3 kernel atm), the screen flickers rapidly, unless the mouse is moving
> (in which case the screen is steady). If I set i915.enable_psr=0 in the
> kernel options at boot, the screen does not flicker, but it also does not
> update *at all* unless I move the mouse. That is:
> 
> 1) type some commands and hit enter → nothing changes on screen
> 2) move the mouse → the screen updates, showing that the commands have run
> and showing output.
> 
> Both of these states (ie, flickers, or no flicker but also no refresh,
> unless the mouse is moving) render my laptop more or less unusable. What are
> the other possible ways to fix this? Does danvert's patch resolve the issue?

dell xps 13 2015. Arch Linux, latest X11 server with xf86-video-intel, default options except dri3.

When enable_psr=1 is set: Similar problem as Executor has with screen not refreshing unless mouse moved BUT this is only happening AFTER first/second return from dpms screen blanking. 

In this state the device might also freeze when trying to manually activate suspend to ram (automatic suspend to ram works when timeout reached). 

This state returns to normal after resuming (returning from suspend to ram).

This state does not appear with enable_psr=0.

I just updated to 4.7 on Arch, and the issue is still present. The screen keeps flickering unless I set enable_psr to 0.

(In reply to ExecutorElassus from comment #44)
> I have a new-ish MSI laptop. With no kernel option set (I'm using a gentoo
> 4.6.3 kernel atm), the screen flickers rapidly, unless the mouse is moving
> (in which case the screen is steady). If I set i915.enable_psr=0 in the
> kernel options at boot, the screen does not flicker, but it also does not
> update *at all* unless I move the mouse. That is:
> 
> 1) type some commands and hit enter → nothing changes on screen
> 2) move the mouse → the screen updates, showing that the commands have run
> and showing output.
> 
> Both of these states (ie, flickers, or no flicker but also no refresh,
> unless the mouse is moving) render my laptop more or less unusable. What are
> the other possible ways to fix this? Does danvert's patch resolve the issue?

Danvet's patch won't help if PSR is not enabled.

Can you do a `cat /sys/kernel/debug/dri/0/i915_edp_psr_status` to confirm PSR is not enabled?

(In reply to AnAkkk from comment #46)
> I just updated to 4.7 on Arch, and the issue is still present. The screen
> keeps flickering unless I set enable_psr to 0.

Please post the output of `lspci  -vs 00:02.0` and full dmesg with drm.debug=0x14.

Output of lspci:

00:02.0 VGA compatible controller: Intel Corporation 4th Gen Core Processor Integrated Graphics Controller (rev 06) (prog-if 00 [VGA controller])
	Subsystem: Acer Incorporated [ALI] Device 0781
	Flags: bus master, fast devsel, latency 0, IRQ 33
	Memory at d3000000 (64-bit, non-prefetchable) [size=4M]
	Memory at c0000000 (64-bit, prefetchable) [size=256M]
	I/O ports at 5000 [size=64]
	[virtual] Expansion ROM at 000c0000 [disabled] [size=128K]
	Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
	Capabilities: [d0] Power Management version 2
	Capabilities: [a4] PCI Advanced Features
	Kernel driver in use: i915
	Kernel modules: i915


I can email you the dmesg?

On my i7-4510U with kernels 4.6 and 4.7 system always hangs after boot (as soon as gdm appears), and only i915.enable_psr=0 solves the problem. Kernel 4.5 worked flawlessly. This is my lscpi output:

00:02.0 VGA compatible controller: Intel Corporation Haswell-ULT Integrated Graphics Controller (rev 0b) (prog-if 00 [VGA controller])
	Subsystem: Toshiba America Info Systems Device 0005
	Flags: bus master, fast devsel, latency 0, IRQ 46
	Memory at f0000000 (64-bit, non-prefetchable) [size=4M]
	Memory at e0000000 (64-bit, prefetchable) [size=256M]
	I/O ports at 3000 [size=64]
	[virtual] Expansion ROM at 000c0000 [disabled] [size=128K]
	Capabilities: <access denied>
	Kernel driver in use: i915
	Kernel modules: i915

This is the missing Capabilities section in my previous comment:

	Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
	Capabilities: [d0] Power Management version 2
	Capabilities: [a4] PCI Advanced Features

I have a Toshiba Portege Z30A-15M with i7-4500U which hangs during boot a few seconds after the window to enter the root partition encryption key is shown.

4.5 works fine, and I found this change by bisecting. (03b7b5f983091bca1, drm/i915/psr: Try to program link training times correctly)

00:02.0 VGA compatible controller: Intel Corporation Haswell-ULT Integrated Graphics Controller (rev 09) (prog-if 00 [VGA controller])
        Subsystem: Toshiba America Info Systems Device 0005
        Flags: bus master, fast devsel, latency 0, IRQ 44
        Memory at f0000000 (64-bit, non-prefetchable) [size=4M]
        Memory at e0000000 (64-bit, prefetchable) [size=256M]
        I/O ports at 3000 [size=64]
        Expansion ROM at <unassigned> [disabled]
        Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
        Capabilities: [d0] Power Management version 2
        Capabilities: [a4] PCI Advanced Features
        Kernel driver in use: i915
        Kernel modules: i915

Using the enable_psr=0 argument makes my machine boot normally with later kernels.

*** Bug 95124 has been marked as a duplicate of this bug. ***

I am experiencing the same problems on a thinkpad e540p (similar hardware) on arch linux with kernel 4.7.6-1. I beleive this was introduced in kernel 4.6.x. Kernel 4.5.x works fine, later kernels require booting with i915.enable_psr=0 to resolve the issue.

I would love to provide more information if needed - I'm not exactly sure what information is relevant as this is the first time I'm getting involved in this sort of thing.

I am experiencing the same issues on my Lenovo Thinkdad L540 on Manjaro (Arch-Linux) with kernel 4.8.1-1-Manjaro. These problems were introduced in kernel 4.6.x, which require booting with i915.enable_psr=0 to resolve the issue.

Following submitted patch https://patchwork.freedesktop.org/patch/127188/ is going to set psr by default because it's known to cause bugs -until we get proper fix. As a general rule, we really don't recommend setting any i915 options to enable or disable features.

We just merged a patch to disable PSR by default:

commit 2ee7dc497e348eecbb82adbb1ea9e9a7e29fe921
    drm/i915: disable PSR by default on HSW/BDW

This commit is marked for inclusion in the stable Kernels, so it should reach your Linux distribution at some point soon.

Thank you for your bug report. In case you think the problem still happens, please feel free to reopen the bug.

FWIW, my X240 hasn't had PSR problems in a long time; it was fixed pretty early on in this bug. So it's not all doom and gloom :-)

Same here--no issue on X250 (Broadwell) with kernel 4.6.

(In reply to Steinar H. Gunderson from comment #58)
> FWIW, my X240 hasn't had PSR problems in a long time; it was fixed pretty
> early on in this bug. So it's not all doom and gloom :-)

(In reply to Andreas Kloeckner from comment #59)
> Same here--no issue on X250 (Broadwell) with kernel 4.6.

Unfortunately it's known to cause bugs on at least some panels, so we'll keep it disabled by default until that's solved. Feel free to continue with the i915.enable_psr=1 parameter if you want. But if you plan on reporting further bugs, please make sure to always go back to the default parameters before reproducing the bugs and getting the log files.

Dell XPS 13 9380 running 5.0.7. Still affected.

Hi Peter

Could you open a new issue and add logs?
https://01.org/linuxgraphics/documentation/how-report-bugs
If possible, could add logs your current kernel and drm-tip? So we can backport fixes for the stable kernel.