I've bisected this down with relative confidence (had to mark commits from 4.3 as artificially good as the system was not usable with this older version of the kernel):

921ec285a6589cf3beb7f56a70744f75b09349f8 is the first bad commit
commit 921ec285a6589cf3beb7f56a70744f75b09349f8
Author: Rodrigo Vivi <rodrigo.vivi@intel.com>
Date:   Wed Nov 18 11:21:12 2015 -0800


Here is the full bisect log:

git bisect start '--' 'drivers/gpu/drm/i915' 'include/drm/' 'include/uapi/drm/'
# bad: [359d2243117a79599435141fda0047d01ef324e8] drm/i915: Update DRIVER_DATE to 20160314
git bisect bad 359d2243117a79599435141fda0047d01ef324e8
# good: [1cb8570bf04ab12a03c31c397a4d158f24895d9c] Linux 4.4.2
git bisect good 1cb8570bf04ab12a03c31c397a4d158f24895d9c
# good: [afd2ff9b7e1b367172f18ba7f693dfb62bdcb2dc] Linux 4.4
git bisect good afd2ff9b7e1b367172f18ba7f693dfb62bdcb2dc
# bad: [2a33d93486f247924e46b5402b8ffb43d1b9b38c] drm/i915/bios: add support for MIPI sequence block v3
git bisect bad 2a33d93486f247924e46b5402b8ffb43d1b9b38c
# bad: [013d37520af735fd55f78e33edf55cc6fb3858eb] drm/i915: Introduce bdw_{update,enable,disable}_pipe_irq()
git bisect bad 013d37520af735fd55f78e33edf55cc6fb3858eb
# good: [b1a14c6e40413f833dadc1d23b43c530f4b8e381] drm/i915: refactor stepping info retrieval
git bisect good b1a14c6e40413f833dadc1d23b43c530f4b8e381
# good: [78e0d2e3477aa3e8bdac70698ddd2aad020016d1] drm/i915: Store DVO SRCDIM register offset under intel_dvo_device
git bisect good 78e0d2e3477aa3e8bdac70698ddd2aad020016d1
# good: [a6d09186fa27dea720ddd668a814cb6e4f78d53b] drm/i915: Stuff rotation params into view union
git bisect good a6d09186fa27dea720ddd668a814cb6e4f78d53b
# good: [ca1a95334ddaf624c1b0424113fe9b8100da1614] drm/i915: Remove duplicated dpcd write on hsw_psr_enable_sink.
git bisect good ca1a95334ddaf624c1b0424113fe9b8100da1614
# bad: [9bbc8258ae5914af1986561767d971417cee7a28] drm/i915: Check for underruns after crtc disable
git bisect bad 9bbc8258ae5914af1986561767d971417cee7a28
# bad: [05eec3c2709d8966cbfcc7cd395f37889c492678] drm/i915: Remove PSR Perf Counter for SKL+
git bisect bad 05eec3c2709d8966cbfcc7cd395f37889c492678
# bad: [bb929cbc1f58c72eaf7981281dbb024ad92ef24d] drm/i915: PSR: Mask LPSP hw tracking back again.
git bisect bad bb929cbc1f58c72eaf7981281dbb024ad92ef24d
# bad: [921ec285a6589cf3beb7f56a70744f75b09349f8] drm/i915: PSR: Let's rely more on frontbuffer tracking.
git bisect bad 921ec285a6589cf3beb7f56a70744f75b09349f8
# first bad commit: [921ec285a6589cf3beb7f56a70744f75b09349f8] drm/i915: PSR: Let's rely more on frontbuffer tracking.

Could someone at Intel please assign this to offending commit committer Rodrigo Vivi (or request he assign himself)?

Unfortunately, bugzilla won't allow one to either assign him or CC as per error message:
Assignee:
rodrigo.vivi AT intel DOT com did not match anything 

Also, this seems strange one cannot assign him given Intel's documentation states to report here as per https://01.org/linuxgraphics/documentation/how-report-bugs , but yet bugzilla cannot reach the appropriate developer?

Despite this, increasing importance, given it's bisected, reproducible for a few folks as reported downstream, and reproducible in latest drm-intel-nightly.

(In reply to Christopher M. Penalver from comment #2)
> Could someone at Intel please assign this to offending commit committer
> Rodrigo Vivi (or request he assign himself)?
> 
> Unfortunately, bugzilla won't allow one to either assign him or CC as per
> error message:
> Assignee:
> rodrigo.vivi AT intel DOT com did not match anything 

Done now, it's just that he's registered here with another email address. Writing just parts of the name will show up alternatives.

Created attachment 122707 [details]
revert of bisected commit...

Hi there,

First of all please accept my apologies for using different emails here and in the commits. But besides the auto-complete with only my name as Jani suggested I'm always open for direct emails.

So, there are 2 separated tests that I'd like you to to perform:

1. Apply the attached patch and let me know if the issue goes away.

2. Without applying any patch boot with i915.enable_psr=2.

Thanks,
Rodrigo.

Rodrigo:
I have already tried reverting that commit (in ubuntu's mainline kernel, i.e. in their backported i915_bpo module) but the flickering still occurs.
I may have messed up my bisect: from memory, b1a14c6e40413f8 78e0d2e3477aa3e8bdac a6d09186fa27dea7 ca1a95334ddaf624c1b0424 may have been marked wrongly as "good" as at least the last two of them did not allow me boot up the computer.
I will try psr=2 and let you know.

enable_psr=2 still flickers with 4.4.0-16. unable to try latest 4.4.0-17 as X doesn't start with it.

dmesg|grep i915
[    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-4.4.0-16-generic i915.enable_psr=2 i915_bpo.enable_psr=2 root=UUID=432cb01b-c9c7-4cb0-8129-5c0abadbf9f8 ro quiet splash vt.handoff=7
[    0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.4.0-16-generic i915.enable_psr=2 i915_bpo.enable_psr=2 root=UUID=432cb01b-c9c7-4cb0-8129-5c0abadbf9f8 ro quiet splash vt.handoff=7
[    1.540320] [drm] Finished loading i915/skl_dmc_ver1.bin (v1.26)
[    1.566144] [drm] Initialized i915_bpo 1.6.0 20160214 for 0000:00:02.0 on minor 0
[    1.820091] i915_bpo 0000:00:02.0: fb0: inteldrmfb frame buffer device
[    3.962877] snd_hda_intel 0000:00:1f.3: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915_bpo])
[  191.798099] [drm:intel_cpu_fifo_underrun_irq_handler [i915_bpo]] *ERROR* CPU pipe A FIFO underrun

what about i915.enable_psr=0?

4.4.0-17 (which backports i915 from 4.6.0-rc1 IIUC) flickers with enable_psr = 0, 1 and 2.
My impression after a short test is that the flickering occurs more frequently when set to 0 than 1 or 2.

Given it happens even with i915.enable_psr=0 I'm sure the bisect was misslead at some point.

I'm starting to suspect on Watermark.

Could you please try to apply the following series to see if it helps:
https://patchwork.freedesktop.org/patch/76098/
https://patchwork.freedesktop.org/patch/76100/
https://patchwork.freedesktop.org/patch/76099/
https://patchwork.freedesktop.org/patch/76101/
https://patchwork.freedesktop.org/patch/76094/
https://patchwork.freedesktop.org/patch/76204/
https://patchwork.freedesktop.org/patch/76207/
https://patchwork.freedesktop.org/patch/76095/

Thanks,
Rodrigo.

On top of which SHA do you want me to apply these? Should I apply them all or test the one by one ?

All at once preferably on top of drm-intel-nightly.
In case you have conflicts just let me know that I try to prepare a repo for you.

could you quickly walk me through as to how to apply these please? I know nothing about patchwork.

OK, I'm applying them manually.
The 7th one is failing:

git apply -v /home/tbonfort-scratch/Downloads/7-8*
Checking patch drivers/gpu/drm/i915/i915_dma.c...
error: while searching for:
#include <linux/pm.h>
#include <linux/pm_runtime.h>
#include <linux/oom.h>


static int i915_getparam(struct drm_device *dev, void *data,

error: patch failed: drivers/gpu/drm/i915/i915_dma.c:49
error: drivers/gpu/drm/i915/i915_dma.c: patch does not apply
Checking patch drivers/gpu/drm/i915/i915_drv.h...
Hunk #1 succeeded at 1984 (offset -38 lines).

using 3-way:

/**
 * i915_driver_init_mmio - setup device MMIO
 * @dev_priv: device private
 *
 * Setup minimal device state necessary for MMIO accesses later in the
 * initialization sequence. The setup here should avoid any other device-wide
 * side effects or exposing the driver via kernel internal or user space
 * interfaces.
 */
static int i915_driver_init_mmio(struct drm_i915_private *dev_priv)
{
        struct drm_device *dev = dev_priv->dev;
        int ret;

<<<<<<< ours
        if (i915_inject_load_failure())
                return -ENODEV;
=======
        /* walk the dmi device table for getting platform memory information */
        dev_priv->dmi.valid = true;
        dmi_walk(dmi_decode_memory_info, dev_priv);
        if (!dev_priv->dmi.mem_speed)
                dev_priv->dmi.valid = false;

        /* Setup the write-once "constant" device info */
        device_info = (struct intel_device_info *)&dev_priv->info;
        memcpy(device_info, info, sizeof(dev_priv->info));
        device_info->device_id = dev->pdev->device;
>>>>>>> theirs

        if (i915_get_bridge_dev(dev))
                return -EIO;

        ret = i915_mmio_setup(dev);
        if (ret < 0)
                goto put_bridge;

        intel_uncore_init(dev);

        return 0;

put_bridge:
        pci_dev_put(dev_priv->bridge_dev);

        return ret;
}

hm, I had a different conflict on my patch 7 here, so not sure... Anyway I prepared a branch with these 8 patches on top of nightly:

https://cgit.freedesktop.org/~vivijim/drm-intel/log/?h=watermarks-wa

Rodrigo,
sorry for being a noob here...: what remote should I add to get to that branch?

there is nothing wrong that needs apologies here ;)

Thank you very much for your report and effort helping us here!

git remote add vivijim git://people.freedesktop.org/~vivijim/drm-intel
git fetch vivijim
git checkout vivijim/watermarks-wa -b vivijim-watermarks-wa

can you please advise as to the workflow I should be using to compile a meaningfull kernel to test this, starting from the config used by ubuntu?

this is what I'm inclined to do:

make mrproper
cp /boot/config-4.4.0-17-generic .config
make oldconfig
#reply to the questions to the best of my knowledge, set i915 debugging to true
#should there be some questions I should reply with something non-default?
make
make modules
sudo make modules_install
sudo make modules

better way is to just

make -j N deb-pkg INSTALL_MOD_STRIP=1

after copying the config there, and adjust N to match your cpu thread count

Flickering still present on watermarks-wa

cp /boot/config-4.4.0-17-generic .config
make -j 4 deb-pkg INSTALL_MOD_STRIP=1
#answer default on everything except i915 debugging

booted using no specific enable_psr flags

$ dmesg|grep i915
[    1.754871] [drm] Finished loading i915/skl_dmc_ver1.bin (v1.26)
[    2.280124] [drm] Initialized i915 1.6.0 20160330 for 0000:00:02.0 on minor 0
[    3.331669] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device
[    4.452639] snd_hda_intel 0000:00:1f.3: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915])
[  207.155111] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun

the first flickering occurs at the time the underrun message appears in the logs (after a minute or so of usage)

booting with enable_psr=1 leads to same results:

$ dmesg|grep i915
[    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-4.6.0-rc2+ i915.enable_psr=1 root=UUID=432cb01b-c9c7-4cb0-8129-5c0abadbf9f8 ro quiet splash vt.handoff=7
[    0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.6.0-rc2+ i915.enable_psr=1 root=UUID=432cb01b-c9c7-4cb0-8129-5c0abadbf9f8 ro quiet splash vt.handoff=7
[    1.743617] [drm] Finished loading i915/skl_dmc_ver1.bin (v1.26)
[    1.774134] [drm] Initialized i915 1.6.0 20160330 for 0000:00:02.0 on minor 0
[    3.376327] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device
[    4.397625] snd_hda_intel 0000:00:1f.3: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915])
[  185.017240] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun

The bug's status is NEEDINFO. Is there anything more you need from me?

Another bisect attempt would be ideal.

Since it happens with i915.enable_psr=0 it is not PSR related.

But anyway, could you please provide more info about your system:
- full dmesg after booting with drm.debug=0xe
- /var/log/Xorg.0.log
- what graphical environment you use
- do you have an external monitor attached?
- Is there anything special that triggers the flickering? something like: "it starts flickering when having more than one monitor I try to move the cursor to the external one"
- Could you please try i915.enable_dc=0 i915.disable_power_well=0

Thanks,
Rodrigo.

Created attachment 122843 [details]
dmesg with drm.debug on 4.4.0-18 up until first flicker

Created attachment 122844 [details]
Xorg.0.log

>what graphical environment you use
KDE plasma
>do you have an external monitor attached?
No
>Is there anything special that triggers the flickering? something like: "it starts flickering when having more than one monitor I try to move the cursor to the external one"
No special trigger. First happens between 30secs and 5 minutes after boot, then by salves of ~3-10 flickers separated by a few seconds, followed by a few minutes with no flickering. Flickers seem to happen essentially when the machine is more or less idling.

Created attachment 122845 [details]
dmesg with enable_dc=0 disable_power_well=0 , up to first flicker

(In reply to thomas bonfort from comment #27)
> Created attachment 122845 [details]
> dmesg with enable_dc=0 disable_power_well=0 , up to first flicker

Ive been following this bug for a while.

It seems to me that the bug does not occur while fullscreen video playback, which includes fullscreen chrome youtube and netflix, as well als fullscreen vlc playback. Can someone confirm? Hope this helps.

Is another bisect still needed? I might be able to do that.

(In reply to thomas bonfort from comment #26)
> >what graphical environment you use
> KDE plasma
> >do you have an external monitor attached?
> No
> >Is there anything special that triggers the flickering? something like: "it starts flickering when having more than one monitor I try to move the cursor to the external one"
> No special trigger. First happens between 30secs and 5 minutes after boot,
> then by salves of ~3-10 flickers separated by a few seconds, followed by a
> few minutes with no flickering. Flickers seem to happen essentially when the
> machine is more or less idling.

I believe I am having the same problem. I am on XPS 13 9350 too, and now on 4.6-rc3 kernel. And yes the flickers do tend to occur when the machine is kind of idling.

My suspicion is that it has something to do with RC6. When I change the  i915.enable_rc6 parameter from 7 to 0, the flickering seems to go away. The problem is, of course, disabling RC6 will drain battery a lot faster.

PS. I notice that even with i915.enable_rc6=7, the GPU never goes to RC6p and RC6pp. Is that not supported on Skylake yet?

RC6p/RC6pp split got deprecated few generations ago. So on Skylake RC6 is the deepest already.

Thomas, do you confirm disabling RC6 the flickerings goes away for you as well?

nhellwege another bisect would be awesome for sure. Thanks

Uhm interesting that even with i915.enable_dc=0 you Thomas are getting
[   17.788425] [drm:gen9_set_dc_state] Setting DC state from 00 to 02

What firmware version do you have loaded?
cat /sys/kernel/debug/dri/0/i915_dmc_info

Here's the dmesg FYI:

$ dmesg|grep i915
[    0.000000] Command line: BOOT_IMAGE=/vmlinuz-linux-mainline root=UUID=0e20ff18-cf60-41db-b0ec-d752d5df0844 rw cryptdevice=/dev/disk/by-uuid/12f4a4fd-0a88-4327-b272-f3ca8fd5d82d:lvm:allow-discards quiet resume=/dev/disk/by-uuid/886bcda0-2e8a-4068-aba2-664991526834 pcie_aspm=force i915.enable_execlists=0 i915.enable_psr=1
[    0.000000] Kernel command line: BOOT_IMAGE=/vmlinuz-linux-mainline root=UUID=0e20ff18-cf60-41db-b0ec-d752d5df0844 rw cryptdevice=/dev/disk/by-uuid/12f4a4fd-0a88-4327-b272-f3ca8fd5d82d:lvm:allow-discards quiet resume=/dev/disk/by-uuid/886bcda0-2e8a-4068-aba2-664991526834 pcie_aspm=force i915.enable_execlists=0 i915.enable_psr=1
[    0.897902] [drm] Finished loading i915/skl_dmc_ver1.bin (v1.23)
[    0.917624] [drm] Initialized i915 1.6.0 20160229 for 0000:00:02.0 on minor 0
[    2.644829] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device
[    9.329977] snd_hda_intel 0000:00:1f.3: bound 0000:00:02.0 (ops i915_exit [i915])
[   24.371605] WARNING: CPU: 0 PID: 884 at drivers/gpu/drm/i915/intel_uncore.c:649 __unclaimed_reg_debug+0x80/0x90 [i915]
[   24.371669]  af_alg dm_crypt dm_mod sd_mod rtsx_pci_sdmmc mmc_core atkbd libps2 crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd ahci libahci xhci_pci libata xhci_hcd rtsx_pci scsi_mod usbcore usb_common i8042 serio i915 video button i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm intel_agp intel_gtt
[   24.371722]  [<ffffffffa013f0e0>] __unclaimed_reg_debug+0x80/0x90 [i915]
[   24.371731]  [<ffffffffa013fb8e>] gen9_read32+0x33e/0x3b0 [i915]
[   24.371742]  [<ffffffffa0149b49>] i915_audio_component_codec_wake_override+0x39/0xb0 [i915]
[  342.932696] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun

I am currently bisecting the kernel again and one thing I realize is that I can detect an error through dmesg and then set the commit to bad, but after reviewing some kernels which I have marked as good, it turns out these were bad too. This messed up my bisect and I have to start over again.

Does anyone know how to specifically excite the error? So far I mostly open chrome and open netflix and youtube, since browsing through the galleries sometimes helps to see the bug, but unfortunately not always. Any method is welcomed and could speed up my bisect a lot :)

(In reply to Rodrigo Vivi from comment #30)
> RC6p/RC6pp split got deprecated few generations ago. So on Skylake RC6 is
> the deepest already.
> 
> Thomas, do you confirm disabling RC6 the flickerings goes away for you as
> well?

with i915.enable_rc6=0 the flickering is gone. Maybe unrelated, but after waking up from suspend I am now getting a new message:

i915_bpo 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment

(In reply to Rodrigo Vivi from comment #32)
> Uhm interesting that even with i915.enable_dc=0 you Thomas are getting
> [   17.788425] [drm:gen9_set_dc_state] Setting DC state from 00 to 02
> 
> What firmware version do you have loaded?
> cat /sys/kernel/debug/dri/0/i915_dmc_info

 
fw loaded: yes
path: i915/skl_dmc_ver1.bin
version: 1.26
DC3 -> DC5 count: 0
DC5 -> DC6 count: 0
program base: 0x09004040
ssp base: 0x00002fc0
htp: 0x00b40068

(In reply to thomas bonfort from comment #35)
> (In reply to Rodrigo Vivi from comment #30)
> > RC6p/RC6pp split got deprecated few generations ago. So on Skylake RC6 is
> > the deepest already.
> > 
> > Thomas, do you confirm disabling RC6 the flickerings goes away for you as
> > well?
> 
> with i915.enable_rc6=0 the flickering is gone. Maybe unrelated, but after
> waking up from suspend I am now getting a new message:
> 
> i915_bpo 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment

I thought I had waited long enough before reporting, but apparently not so :)
I just had a salve of flickers even with rc6=0. dmesg shows the usual:

[17243.901481] [drm:intel_cpu_fifo_underrun_irq_handler [i915_bpo]] *ERROR* CPU pipe A FIFO underrun

looks like a power management issues dating 8 months back, Also happened on the broadwell systems https://bugs.freedesktop.org/show_bug.cgi?id=91393.
This makes any linux system a pain to work because of this integrated gpu driver . Skylake has been out for 7 months and we still have problems

I'm not sure if this is kind of expected for this particular bug, but it seems that the problem doesn't happen when the laptop is plugged into the power.

sounds like a dupe of 
https://bugs.freedesktop.org/show_bug.cgi?id=91393

(In reply to Peter Y. Chuang from comment #39)
> I'm not sure if this is kind of expected for this particular bug, but it
> seems that the problem doesn't happen when the laptop is plugged into the
> power.

Flickering happens with AC plugged here

(In reply to thomas bonfort from comment #41)
> (In reply to Peter Y. Chuang from comment #39)
> > I'm not sure if this is kind of expected for this particular bug, but it
> > seems that the problem doesn't happen when the laptop is plugged into the
> > power.
> 
> Flickering happens with AC plugged here

Which kernel are you using at the moment?

(In reply to tranceash from comment #38)
> looks like a power management issues dating 8 months back, Also happened on
> the broadwell systems https://bugs.freedesktop.org/show_bug.cgi?id=91393.
> This makes any linux system a pain to work because of this integrated gpu
> driver . Skylake has been out for 7 months and we still have problems

I am starting to believe that the common error 

 [drm:intel_cpu_fifo_underrun_irq_handler [i915_bpo]] *ERROR* CPU pipe A FIFO underrun

is not actually responsible for the flicker. To be more precise, the FIFO underrun may result in conjunction with a flicker, but is not a unique indication. I am currently bisecting the kernel and right now I am on commit 5ffd4da+. This commit does show the FIFO underun but not at the same time the screen turns completely black for a split second. 

I assume the flicker (screen completely black for a split second) is not directly mapped by the FIFO underrun. 

Reading https://bugs.freedesktop.org/show_bug.cgi?id=91393, I think our bug is at least related, if not identical.

(In reply to nhellwege from comment #43)
> (In reply to tranceash from comment #38)
> > looks like a power management issues dating 8 months back, Also happened on
> > the broadwell systems https://bugs.freedesktop.org/show_bug.cgi?id=91393.
> > This makes any linux system a pain to work because of this integrated gpu
> > driver . Skylake has been out for 7 months and we still have problems
> 
> I am starting to believe that the common error 
> 
>  [drm:intel_cpu_fifo_underrun_irq_handler [i915_bpo]] *ERROR* CPU pipe A
> FIFO underrun
> 
> is not actually responsible for the flicker. To be more precise, the FIFO
> underrun may result in conjunction with a flicker, but is not a unique
> indication. I am currently bisecting the kernel and right now I am on commit
> 5ffd4da+. This commit does show the FIFO underun but not at the same time
> the screen turns completely black for a split second. 
> 
> I assume the flicker (screen completely black for a split second) is not
> directly mapped by the FIFO underrun. 
> 
> Reading https://bugs.freedesktop.org/show_bug.cgi?id=91393, I think our bug
> is at least related, if not identical.

I tend to agree with you that the error 

[drm:intel_cpu_fifo_underrun_irq_handler [i915_bpo]] *ERROR* CPU pipe A FIFO underrun

may not be specific to the problem we are talking about here.

Regarding my previous comment on whether the laptop is plugged into AC, Thomas is right: if I wait long enough, the flicker does occur even when plugged in, although much less frequent on my machine. 

Interestingly, now that I am plugged into AC, the CPU pipe A FIFO underrun thing is no longer the error I see. Instead, this is the error I saw on dmesg:

[ 2045.481992] [drm:intel_pipe_update_end [i915]] *ERROR* Atomic update failure on pipe A (start=84070 end=84071) time 9 us, min 1073, max 1079, scanline start 1087, end 1079

This is the first time I see this error since I started looking for the solution for this problem.

Hope this might give you some clues.

Created attachment 123104 [details]
bisect log for underrun FIFO Error

Bisect log for the i915 Underrun FIFO ERROR. Since no clear method is known on how to excite the error, the bisect might be unfinished. All bad commits did show the FIFO error AND also the Flicker. All good ones did not within a reasonable time (I testet each good Kernal at least 30 minutes). There are some (many) skippes commits, which I was not able to build. The Faulty commit must be somewhere in these skipped commits.

(In reply to tranceash from comment #38)
> looks like a power management issues dating 8 months back, Also happened on
> the broadwell systems https://bugs.freedesktop.org/show_bug.cgi?id=91393.
> This makes any linux system a pain to work because of this integrated gpu
> driver . Skylake has been out for 7 months and we still have problems

Ok, I looked into that bug and it seems its not the same. It specifically mentions external monitors and also not black screen flickering, but more a graphical flickering, without the completely black frames in between.

Nevertheless, I tried the proposes patches from https://bugs.freedesktop.org/show_bug.cgi?id=91393#c102 on intel-drm-nightly and I still got the FIFO underrun ERROR and also the black screen flickering. So thats not a solution.

Also, it seems that the FIFO error does appear for the first flicker, but not for any ones after the first, so in my opinion, it can be used as an error criteria.

I could bisect the kernel further, but as seen in https://bugs.freedesktop.org/attachment.cgi?id=123104 there are so many commits, which I cannot build. Maybe someone can help me to compile one of these? I can then do the remaining (since they are all in order, it seems like the reason they dont compile might be the same).

Probably a bisect on drm-intel-nightly is less painful.
But it seems that we are indeed now duplicating the discussion and there is more information on the other bug. Please reopen if you believe this one here is a different case.

*** This bug has been marked as a duplicate of bug 91393 ***

If the underlying issue is the same then fine. I can confirm that the resulting appearance of this current bug is very different than what the video shows in 91393

As another user confirms on https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1554613 , the flickering has disappeared on the latest drm-intel-next

On my end, the issue looks like a random "blanking" of the screen for 1/4 of a second, two or three times or so in a row. It can happen several times in a few minutes, but I've also seen it last 20 minutes between occurrences. On my end it looks nothing like in that video.

(In reply to thomas bonfort from comment #49)
> As another user confirms on
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1554613 , the
> flickering has disappeared on the latest drm-intel-next

I can confirm that the blank screen flickering is gone with 4.6.0-997-generic intel-drm-next. 

Just a follow up question: I am not that familiar with Kernel releases, but as I understand, the 4.4. has long term support, whereas the 4.6. doesnt. Will the driver from the 4.6. eventually be backported to 4.4.?

Thanks for all the effort which has gone into this bug.

(In reply to jay from comment #50)
> On my end, the issue looks like a random "blanking" of the screen for 1/4 of
> a second, two or three times or so in a row. It can happen several times in
> a few minutes, but I've also seen it last 20 minutes between occurrences. On
> my end it looks nothing like in that video.

Yes, that is the same with me. I dont know if the underlying issues are identical, but the blanking of the screen is totally different from the graphical flickering in #91393.

(In reply to nhellwege from comment #51)
> (In reply to thomas bonfort from comment #49)
> > As another user confirms on
> > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1554613 , the
> > flickering has disappeared on the latest drm-intel-next
> 
> I can confirm that the blank screen flickering is gone with
> 4.6.0-997-generic intel-drm-next. 
> 
> Just a follow up question: I am not that familiar with Kernel releases, but
> as I understand, the 4.4. has long term support, whereas the 4.6. doesnt.
> Will the driver from the 4.6. eventually be backported to 4.4.?
> 
> Thanks for all the effort which has gone into this bug.

I can confirm that the flickering is gone with the latest drm-intel-next kernel too.

Thanks everyone.

Thanks, closing. Please reopen or file new bugs if the problems persist. (Please be careful about not reopening this one if you have bug 91393)

Is this really resolved? The problem is gone, but I don't think anyone identified what is really causing the problem to occur. Also, we need to identify which patch fixed the issue so that it can be back-ported. Both 4.5 and 4.6 kernels have this problem.

I could try to bisect https://git.launchpad.net/~ubuntu-kernel-test/ubuntu/+source/linux/+git/mainline-crack ,which is the base for the 4.6.0-997-generic intel-drm-next. A quick search suggests a list of 4-5 possible commits. 

Should this be done? Bisecting is very tedious.

(In reply to Pranith Kumar from comment #55)
> Is this really resolved? The problem is gone, but I don't think anyone
> identified what is really causing the problem to occur.

In a perfect world we'd get to the roots of every problem, but in reality we don't have the time to keep debugging issues that seem to be gone. Especially in areas where we've done a lot of fixing upstream.

> Also, we need to
> identify which patch fixed the issue so that it can be back-ported. Both 4.5
> and 4.6 kernels have this problem.

If the v4.6-rc kernels still have the issue, but drm-intel-nightly works, it should be a pretty straightforward reverse bisect to find the commit that fixed the bug. If you provide that, it may be possible to do the backport.