I am using the latest i915 driver from git (drm-intel).

Created attachment 121352 [details]
video showing the screen flickering

It looks like either a missing write flag or invalid mocs used; either of those would be a userspace bug. A quick test would be to

diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 8fd00d279447..423e72830733 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1106,7 +1106,7 @@ i915_gem_execbuffer_move_to_active(struct list_head *vmas,
                u32 old_write = obj->base.write_domain;
 
                obj->dirty = 1; /* be paranoid  */
-               obj->base.write_domain = obj->base.pending_write_domain;
+               obj->base.write_domain = I915_GEM_DOMAIN_RENDER;
                if (obj->base.write_domain == 0)
                        obj->base.pending_read_domains |= obj->base.read_domains;
                obj->base.read_domains = obj->base.pending_read_domains;

I have a screen flickering problem too ever since I installed the newest kernel from OpenSuse Factory (4.4.0-2-default).

Since the symptoms are exactly as described here, I have a strong suspicion this is a regression:

http://cgit.freedesktop.org/drm-intel/commit/?id=54da691deb123c045259ebf4f5c67381244f58f1

Apart from that I am also getting lots of "drm:intel_cpu_fifo_underrun_irq_handler" in the kernel logs.

(In reply to Chris Wilson from comment #3)
> It looks like either a missing write flag or invalid mocs used; either of
> those would be a userspace bug. A quick test would be to
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> index 8fd00d279447..423e72830733 100644
> --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> @@ -1106,7 +1106,7 @@ i915_gem_execbuffer_move_to_active(struct list_head
> *vmas,
>                 u32 old_write = obj->base.write_domain;
>  
>                 obj->dirty = 1; /* be paranoid  */
> -               obj->base.write_domain = obj->base.pending_write_domain;
> +               obj->base.write_domain = I915_GEM_DOMAIN_RENDER;
>                 if (obj->base.write_domain == 0)
>                         obj->base.pending_read_domains |=
> obj->base.read_domains;
>                 obj->base.read_domains = obj->base.pending_read_domains;

Thanks for your reply. I applied the changes, but it did not fix the problem.

I believe it was this commit that introduced the flicker regression:

https://github.com/torvalds/linux/commit/43d59eda1f69631c267e06ab6b94ed3c14f1f6d1

(In reply to Manfred Kitzbichler from comment #6)
> I believe it was this commit that introduced the flicker regression:
> 
> https://github.com/torvalds/linux/commit/
> 43d59eda1f69631c267e06ab6b94ed3c14f1f6d1

commit 43d59eda1f69631c267e06ab6b94ed3c14f1f6d1
Author: Matt Roper <matthew.d.roper@intel.com>
Date:   Thu Sep 24 15:53:07 2015 -0700

    drm/i915: Eliminate usage of plane_wm_parameters from ILK-style WM code (v2)

(In reply to Manfred Kitzbichler from comment #6)
> I believe it was this commit that introduced the flicker regression:
> 
> https://github.com/torvalds/linux/commit/
> 43d59eda1f69631c267e06ab6b94ed3c14f1f6d1

It looks like when I dropped the level of indirection I also accidentally dropped a workaround of "pretend the cursor plane is always on" that was papering over the fact that our driver doesn't have proper two-stage watermark programming yet.

Technically the true root cause of this flickering was fixed when we merged the two-step watermarks at the end of that patch series.  However that final patch wound up causing a different regression for our CI system, so we reverted the final patch which brought this regression back instead. :-(

For the short term, just restoring the original workaround of pretending the cursor is always on, even when it isn't, should avoid the user-visible flickering while also keeping our CI system happy; I'll supply a patch for that shortly.

This new commit did not solve the problem either:

commit b2435692dbb709d4c8ff3b2f2815c9b8423b72bb
Author: Matt Roper <matthew.d.roper@intel.com>
Date:   Tue Feb 2 22:06:51 2016 -0800

    drm/i915: Pretend cursor is always on for ILK-style WM calculations (v2)

(In reply to Simon Stieger from comment #9)
> This new commit did not solve the problem either:
> 
> commit b2435692dbb709d4c8ff3b2f2815c9b8423b72bb
> Author: Matt Roper <matthew.d.roper@intel.com>
> Date:   Tue Feb 2 22:06:51 2016 -0800
> 
>     drm/i915: Pretend cursor is always on for ILK-style WM calculations (v2)

It looks like we have some major confusion going on in this bug report. You reported the original bug on SKL, and it looks like some sort of cache coherency issue. But what Manfred Kitzbichler reported seems to be a totally diffrent bug. That one should be filed as a new bug in case it wasn't fixed yet.

Also suffering flickering after a recent update to opensuse tumbleweed.

Hardware:
HP i5 laptop (limited edition star wars)
00:02.0 VGA compatible controller: Intel Corporation Sky Lake Integrated Graphics (rev 07)
Kernel:
Linux linux-f1uu 4.5.0-1-default #1 SMP PREEMPT Wed Mar 16 17:30:21 UTC 2016 (b2c9ae5) x86_64 x86_64 x86_64 GNU/Linux

Seems mainly happens on battery I think.  Flicker happens a few times a minute.  In dmesg i get 
[drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun
but not every time the flicker occurs, and maybe isnt related but seems like it might be.

Reported downstream at https://bugzilla.opensuse.org/show_bug.cgi?id=972206

4.4.3 seems ok, 4.5 flickers.  Got this

[   11.594521] ------------[ cut here ]------------
[   11.594553] WARNING: CPU: 0 PID: 1655 at ../drivers/gpu/drm/i915/intel_uncore.c:599 hsw_unclaimed_reg_debug+0x69/0x90 [i915]()
[   11.594555] Unclaimed register detected after reading register 0x65f10
[   11.594556] Modules linked in: af_packet vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) bnep nls_iso8859_1 nls_cp437 vfat fat snd_hda_codec_hdmi rndis_host cdc_ether usbnet uvcvideo btusb videobuf2_vmalloc videobuf2_memops btrtl btbcm videobuf2_v4l2 btintel videobuf2_core bluetooth videodev msr snd_hda_codec_realtek snd_hda_codec_generic arc4 intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel hp_wmi snd_hda_intel sparse_keymap snd_hda_codec snd_hda_core kvm snd_hwdep irqbypass snd_pcm crct10dif_pclmul crc32_pclmul crc32c_intel iwlmvm snd_timer mac80211 ghash_clmulni_intel aesni_intel aes_x86_64 lrw gf128mul snd glue_helper ablk_helper cryptd iwlwifi rtsx_pci_ms pcspkr joydev cfg80211 soundcore i2c_i801 rfkill r8169 memstick mii shpchp int3403_thermal hp_accel lis3lv02d input_polldev
[   11.594618]  fjes hp_wireless wmi battery thermal tpm_crb int3400_thermal acpi_thermal_rel mei_me mei acpi_pad processor_thermal_device int340x_thermal_zone intel_soc_dts_iosf tpm_tis ac tpm rtsx_pci_sdmmc mmc_core serio_raw rtsx_pci mfd_core i915 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm xhci_pci xhci_hcd usbcore usb_common video button sg efivarfs
[   11.594634] CPU: 0 PID: 1655 Comm: pulseaudio Tainted: G           O    4.5.0-1-default #1
[   11.594636] Hardware name: HP HP Pavilion Notebook/80A1, BIOS F.54 09/22/2015
[   11.594637]  0000000000000000 ffff880246abb7f8 ffffffff81395921 ffff880246abb840
[   11.594639]  ffffffffa027b790 ffff880246abb830 ffffffff8107d912 ffff8802682a0000
[   11.594640]  ffff8802682a0080 0000000000000000 0000000000000206 ffff8802682a0000
[   11.594642] Call Trace:
[   11.594650]  [<ffffffff8101b175>] try_stack_unwind+0x175/0x190
[   11.594655]  [<ffffffff8101a0c9>] dump_trace+0x69/0x3a0
[   11.594657]  [<ffffffff8101b1db>] show_trace_log_lvl+0x4b/0x60
[   11.594660]  [<ffffffff8101a50c>] show_stack_log_lvl+0x10c/0x180
[   11.594662]  [<ffffffff8101b275>] show_stack+0x25/0x50
[   11.594679]  [<ffffffff81395921>] dump_stack+0x63/0x82
[   11.594683]  [<ffffffff8107d912>] warn_slowpath_common+0x82/0xc0
[   11.594686]  [<ffffffff8107d99c>] warn_slowpath_fmt+0x4c/0x50
[   11.594703]  [<ffffffffa01f38e9>] hsw_unclaimed_reg_debug+0x69/0x90 [i915]
[   11.594726]  [<ffffffffa01fa9e9>] gen9_read32+0x119/0x340 [i915]
[   11.594752]  [<ffffffffa01ffccd>] i915_audio_component_codec_wake_override+0x7d/0xb0 [i915]
[   11.594762]  [<ffffffffa08506df>] snd_hdac_set_codec_wakeup+0x3f/0xa0 [snd_hda_core]
[   11.594773]  [<ffffffffa06e74d8>] azx_runtime_resume+0x1a8/0x1d0 [snd_hda_intel]
[   11.594780]  [<ffffffff813e052b>] pci_pm_runtime_resume+0x7b/0xa0
[   11.594785]  [<ffffffff814e7a42>] __rpm_callback+0x32/0x70
[   11.594789]  [<ffffffff814e7aa4>] rpm_callback+0x24/0x80
[   11.594792]  [<ffffffff814e83fb>] rpm_resume+0x47b/0x690
[   11.594796]  [<ffffffff814e82d8>] rpm_resume+0x358/0x690
[   11.594800]  [<ffffffff814e948f>] __pm_runtime_resume+0x3f/0x60
[   11.594805]  [<ffffffffa084be33>] snd_hdac_power_up+0x13/0x20 [snd_hda_core]
[   11.594815]  [<ffffffffa0873932>] azx_pcm_open+0x1d2/0x3e0 [snd_hda_codec]
[   11.594823]  [<ffffffffa06cca09>] snd_pcm_open_substream+0x59/0x110 [snd_pcm]
[   11.594829]  [<ffffffffa06ccb68>] snd_pcm_open+0xa8/0x220 [snd_pcm]
[   11.594835]  [<ffffffffa06ccd27>] snd_pcm_capture_open+0x47/0x70 [snd_pcm]
[   11.594842]  [<ffffffffa03b8481>] snd_open+0xb1/0x180 [snd]
[   11.594846]  [<ffffffff8120f30f>] chrdev_open+0x9f/0x1c0
[   11.594850]  [<ffffffff8120829f>] do_dentry_open+0x1ff/0x2f0
[   11.594867]  [<ffffffff81209546>] vfs_open+0x56/0x60
[   11.594870]  [<ffffffff81218371>] path_openat+0x1b1/0x13a0
[   11.594873]  [<ffffffff8121ae4e>] do_filp_open+0x7e/0xe0
[   11.594877]  [<ffffffff8120989b>] do_sys_open+0x11b/0x1f0
[   11.594880]  [<ffffffff8120998e>] SyS_open+0x1e/0x20
[   11.594884]  [<ffffffff816cbff2>] entry_SYSCALL_64_fastpath+0x16/0x71
[   11.597086] DWARF2 unwinder stuck at entry_SYSCALL_64_fastpath+0x16/0x71

[   11.597090] Leftover inexact backtrace:

[   11.597094] ---[ end trace ddb82be2781f3856 ]---
[   11.861249] Bluetooth: RFCOMM TTY layer initialized
[   11.861258] Bluetooth: RFCOMM socket layer initialized
[   11.861263] Bluetooth: RFCOMM ver 1.11
[   16.184084] show_signal_msg: 18 callbacks suppressed
[   16.184089] xembedsniproxy[1644]: segfault at 2 ip 000000000040c28f sp 00007fff0026ca80 error 4 in xembedsniproxy[400000+13000]
[   24.664379] wlo1: authenticate with f4:9f:f3:64:f3:f4
[   24.672668] wlo1: send auth to f4:9f:f3:64:f3:f4 (try 1/3)
[   24.673551] wlo1: authenticated
[   24.677496] wlo1: associate with f4:9f:f3:64:f3:f4 (try 1/3)
[   24.678745] wlo1: RX AssocResp from f4:9f:f3:64:f3:f4 (capab=0x11 status=0 aid=1)
[   24.680034] wlo1: associated
[   24.745537] wlo1: Limiting TX power to 23 (23 - 0) dBm as advertised by f4:9f:f3:64:f3:f4
[   71.795968] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun

Same problem on Lenovo Thinkpad T460s

I'm experiencing a similar problem on Thinkpad T440p (Haswell) - rare screen flickering only on notebook screen (not on external monitor). In my case bug is triggered by setting i915.enable_psr=1. Is this is a case of this bug?

(In reply to dnord from comment #14)
> I'm experiencing a similar problem on Thinkpad T440p (Haswell) - rare screen
> flickering only on notebook screen (not on external monitor). In my case bug
> is triggered by setting i915.enable_psr=1. Is this is a case of this bug?

dnord, don't do that then. Please try v4.6-rc1 or later where psr is enabled by default on Haswell.

>Please try v4.6-rc1 or later where psr is enabled by default on Haswell.
Yes, I'm aware of this. I tested and the latest drm-intel-nightly and 4.6-rc5 are also prone to this for the same reason. So this is a separate bug?

(In reply to dnord from comment #16)
> >Please try v4.6-rc1 or later where psr is enabled by default on Haswell.
> Yes, I'm aware of this. I tested and the latest drm-intel-nightly and
> 4.6-rc5 are also prone to this for the same reason. So this is a separate
> bug?

If your problem goes away with i915.enable_psr=0, then yes, you have a different problem - please file a new bug for that.

I have the same problem.

Thinkpad X1 Carbon 2016
i5-6200U
Linux Mint + Cinnamon 2.8.8
Kernel 4.4.0-22
(the bug is not present in kernel 4.2.0-36)

I was trying to make a video about it, but it seems that the flickering goes away during a screen cast that is created with ffmpeg. 

This bug is also discussed in this forum:
https://forums.linuxmint.com/viewtopic.php?t=213443

This issue was solved for me when upgrading to Mint 18 (with Cinnamon 3 and kernel 4.4).

(In reply to sep from comment #19)
> This issue was solved for me when upgrading to Mint 18 (with Cinnamon 3 and
> kernel 4.4).

Same here, really glad to see that it's finally gone.

This is not about backlight.

Is this valid still or can be closed?

(In reply to Jani Saarinen from comment #22)
> Is this valid still or can be closed?

Bug reporter mentioned in comment #20 that the problem is gone.

Closing bug. Thanks everybody for reporting and testing. If you think the problem still happens, please reopen the bug, test it against the newest development tree and attach the relevant logs.