Screen flickering in Intel i915 driver

[Lorenzo Bettini]

There's an upstream bug reported here https://bugs.freedesktop.org/show_bug.cgi?id=91393 that causes screen flickering when using the Intel i915 builtin driver (at resolutions lower than the maximal one).

I think that it will be fixed in newer kernel versions, but for the time being, as reported here https://bugs.freedesktop.org/show_bug.cgi?id=91393#c25 (and as personally tested) reverting those two commits fixes the problem.

Would that be possible to release a fixed version for the 4.2.0 stream?

ProblemType: Bug
DistroRelease: Ubuntu 15.10
Package: linux-image-4.2.0-19-generic 4.2.0-19.23
ProcVersionSignature: Ubuntu 4.2.0-19.23-generic 4.2.6
Uname: Linux 4.2.0-19-generic x86_64
ApportVersion: 2.19.1-0ubuntu5
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: bettini 1378 F.... pulseaudio
 /dev/snd/controlC1: bettini 1378 F.... pulseaudio
CurrentDesktop: KDE
Date: Fri Dec 4 19:01:00 2015
HibernationDevice: RESUME=UUID=7ddbc972-3ad6-40de-9313-2bb9395145f9
InstallationDate: Installed on 2015-05-08 (210 days ago)
InstallationMedia: Kubuntu 15.04 "Vivid Vervet" - Release amd64 (20150422)
MachineType: Dell Inc. Dell Precision M3800
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.2.0-19-generic root=UUID=dd2c7064-53b9-4720-96ab-5e8a3f2db3ea ro noprompt quiet splash vt.handoff=7
RelatedPackageVersions:
 linux-restricted-modules-4.2.0-19-generic N/A
 linux-backports-modules-4.2.0-19-generic N/A
 linux-firmware 1.149.3
SourcePackage: linux
UdevLog: Error: [Errno 2] No such file or directory: '/var/log/udev'
UpgradeStatus: Upgraded to wily on 2015-11-07 (26 days ago)
dmi.bios.date: 08/17/2015
dmi.bios.vendor: Dell Inc.
dmi.bios.version: A10
dmi.board.name: Dell Precision M3800
dmi.board.vendor: Dell Inc.
dmi.board.version: A10
dmi.chassis.type: 8
dmi.chassis.vendor: Dell Inc.
dmi.chassis.version: Not Specified
dmi.modalias: dmi:bvnDellInc.:bvrA10:bd08/17/2015:svnDellInc.:pnDellPrecisionM3800:pvrA10:rvnDellInc.:rnDellPrecisionM3800:rvrA10:cvnDellInc.:ct8:cvrNotSpecified:
dmi.product.name: Dell Precision M3800
dmi.product.version: A10
dmi.sys.vendor: Dell Inc.

[Furniss-tom (furniss-tom)]

Created attachment 117243
dmesg

Consistently flickering screen when i915 driver is used with the N133HSE-EA3 screen of the Lafite 13.3 laptop. Video here: https://www.youtube.com/watch?v=0ISthkP7L3o

When i915 driver is disabled (i915.modeset=0), Linux falls back to the vesa driver and the laptop screen renders correctly.

When an external monitor is connected via HDMI, the i915 driver renders the external monitor correctly whilst the flickering remains on the laptop screen.

Earlier versions of this laptop model did not experience this problem, but the most recent version does (reported by one other user). I have no authoritative record of the hardware changes between model versions.

System information:
 - Architecture and kernel: 4.2.0-994-generic #201507142205 SMP Wed Jul 15 02:06:50 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
 - Distribution: Ubuntu 15.04
 - Laptop model: Lafite 13.3 from www.pcspecialist.co.uk
 - Laptop Screen: Chimei N133HSE-EA3
 - Display Conenctor: eDP

$ sudo get-edid | edid-decode
Extracted contents:
header: 00 ff ff ff ff ff ff 00
serial number: 0d ae 61 13 00 00 00 00 07 18
version: 01 04
basic params: a5 1d 11 78 02
chroma info: ce 85 a3 57 4e 9d 26 12 50 54
established: 00 00 00
standard: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
descriptor 1: 36 36 80 a0 70 38 20 40 2e 1e 24 00 25 a5 10 00 00 18
descriptor 2: 24 24 80 a0 70 38 20 40 2e 1e 24 00 25 a5 10 00 00 18
descriptor 3: 00 00 00 fe 00 43 4d 4e 0a 20 20 20 20 20 20 20 20 20
descriptor 4: 00 00 00 fe 00 4e 31 33 33 48 53 45 2d 45 41 33 0a 20
extensions: 00
checksum: a1

Manufacturer: CMN Model 1361 Serial Number 0
Made week 7 of 2014
EDID version: 1.4
Digital display
8 bits per primary color channel
DisplayPort interface
Maximum image size: 29 cm x 17 cm
Gamma: 2.20
Supported color formats: RGB 4:4:4
First detailed timing is preferred timing
Established timings supported:
Standard timings supported:
Detailed mode: Clock 138.780 MHz, 293 mm x 165 mm
               1920 1966 1996 2080 hborder 0
               1080 1082 1086 1112 vborder 0
               -hsync -vsync
Detailed mode: Clock 92.520 MHz, 293 mm x 165 mm
               1920 1966 1996 2080 hborder 0
               1080 1082 1086 1112 vborder 0
               -hsync -vsync
ASCII string: CMN
         ASCII string: N133HSE-EA3
 Checksum: 0xa1
EDID block does NOT conform to EDID 1.3!
 Missing name descriptor
 Missing monitor ranges

$ sudo lshw -c video
  *-display
       description: VGA compatible controller
       product: Broadwell-U Integrated Graphics
       vendor: Intel Corporation
       physical id: 2
       bus info: pci@0000:00:02.0
       version: 09
       width: 64 bits
       clock: 33MHz
       capabilities: msi pm vga_controller bus_master cap_list rom
       configuration: driver=i915 latency=0
       resources: irq:50 memory:b1000000-b1ffffff memory:c0000000-cfffffff ioport:4000(size=64)

$ glxinfo | grep -i vendor
server glx vendor string: SGI
client glx vendor string: Mesa Project and SGI
OpenGL vendor string: Intel Open Source Technology Center

$ glxinfo | grep -i render
direct rendering: Yes
    GLX_MESA_...

[Furniss-tom (furniss-tom)]

Created attachment 117244
intel-reg-dumper

[Furniss-tom (furniss-tom)]

Created attachment 117245
edid file

[Furniss-tom (furniss-tom)]

Created attachment 117246
xrandr --verbose

[Furniss-tom (furniss-tom)]

Created attachment 117247
xorg log

[Jesse Barnes (jbarnes-virtuousgeek)]

Does i915.enable_ips=0 help at all?

[Furniss-tom (furniss-tom)]

(In reply to Jesse Barnes from comment #5)
> Does i915.enable_ips=0 help at all?

Same symptoms were observed with i915.enable_ips=0. Kernel is drm-intel-nightly 4.2.0-994.201508010158

[Rodrigo-vivi (rodrigo-vivi)]

Hi Tom,
Please let me know the status of few feature while you get this:

sudo cat /sys/kernel/debug/dri/0/i915_edp_psr_status

sudo cat /sys/kernel/debug/dri/0/i915_fbc_status

sudo cat /sys/kernel/debug/dri/0/i915_ips_status

Thanks,
Rodrigo.

[Furniss-tom (furniss-tom)]

(In reply to Rodrigo Vivi from comment #7)
> Hi Tom,
> Please let me know the status of few feature while you get this:
>
> sudo cat /sys/kernel/debug/dri/0/i915_edp_psr_status
>
> sudo cat /sys/kernel/debug/dri/0/i915_fbc_status
>
> sudo cat /sys/kernel/debug/dri/0/i915_ips_status
>
> Thanks,
> Rodrigo.

Hi Rodrigo - those directories (beyond /sys/kernel) don't exist on my system. Do I need to enable some kind of additional logging?

Thanks

[Oscar Morante (spacepluk)]

Hi,
I think I'm running into the same problem on my machine. But in my case it only happens after the screen goes to sleep (locking in gnome) and sometimes it stays completely black instead of flickering. You can also see that it renders some garbage from time to time.

https://www.youtube.com/watch?v=YL_9IRsx8Lo

I'm using the kernel packages from Arch Linux's repositories and it only started happening with version 4.2 (which is on Arch's testing repo right now). It works fine with 4.1.6 (in the core repo) except for occasional 1 frame blackouts.

System information:
 - Architecture and kernel: 4.2.0-3-ARCH #1 SMP PREEMPT Fri Sep 4 20:59:11 UTC 2015 x86_64 GNU/Linux
 - Distribution: Arch Linux
 - Laptop model: Razer Blade 14" (2015)
 - Laptop Screen: (I don't know how to check this :?)
 - Display Conenctor: eDP

I don't see any errors in any of my logs when this happens. Is there any debug setting I can use that can help you get more information?

[Jani-nikula (jani-nikula)]

I'd like to get an intel_reg dump output ('intel_reg dump' replaces intel_reg_dumper in recent http://cgit.freedesktop.org/xorg/app/intel-gpu-tools/) for both before and after loading i915. Alternatively, with i915.modeset=0 and i915.modeset=1. It should be interesting to see the difference in register values for both cases.

[Furniss-tom (furniss-tom)]

(In reply to Jani Nikula from comment #10)
> I'd like to get an intel_reg dump output ('intel_reg dump' replaces
> intel_reg_dumper in recent
> http://cgit.freedesktop.org/xorg/app/intel-gpu-tools/) for both before and
> after loading i915. Alternatively, with i915.modeset=0 and i915.modeset=1.
> It should be interesting to see the difference in register values for both
> cases.

Hi Jani, I am away from the laptop right now but should be able to provide the additional information in a few days.

[Oscar Morante (spacepluk)]

Is there any guide I can follow to dump the registers before the module is loaded? I did a quick test passing `break=postmount` to the kernel and chrooting into the rootfs but I couldn't manage to get intel_reg to work like this.

[Mm-v (mm-v)]

Same problem here on the Pentium brodwell GT1 model (TopStar U731).

Does it affect any kernel ?

[Furniss-tom (furniss-tom)]

(In reply to Jani Nikula from comment #10)
> I'd like to get an intel_reg dump output ('intel_reg dump' replaces
> intel_reg_dumper in recent
> http://cgit.freedesktop.org/xorg/app/intel-gpu-tools/) for both before and
> after loading i915. Alternatively, with i915.modeset=0 and i915.modeset=1.
> It should be interesting to see the difference in register values for both
> cases.

I've uploaded two files:
 - i915.modeset0.txt
 - i915.modeset1.txt

Both contain the output of the command "intel_reg dump", one with i915.modeset=0, one with i915.modeset=1.

intel-gpu-tools is version 1.11. Kernel is drm-intel-next, 4.2.0-997-generic #201509120200 SMP Sat Sep 12 02:02:06 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux.

[Furniss-tom (furniss-tom)]

Created attachment 118383
intel_reg dump with i915.modeset=0

[Furniss-tom (furniss-tom)]

Created attachment 118384
intel_reg dump with i915.modeset=1

[Oscar Morante (spacepluk)]

If it helps, this is the output of intel_reg dump before and after it happens for me. This is the sequence:

1) Boot into a gnome 3 desktop (everything works fine)
2) intel_reg dump > intel_reg-dump-ok
3) Lock the screen with gnome (turns off the display)
4) Unlock the screen (here I start getting the flickering)
5) intel_reg dump > intel_reg-dump-flickering

[Oscar Morante (spacepluk)]

Created attachment 118538
intel_reg dump before the flicker happens

[Oscar Morante (spacepluk)]

Created attachment 118539
intel_reg dump while the flicker is happening

[Jani-nikula (jani-nikula)]

(In reply to Oscar Morante from comment #17)
> If it helps, this is the output of intel_reg dump before and after it
> happens for me. This is the sequence:
>
> 1) Boot into a gnome 3 desktop (everything works fine)
> 2) intel_reg dump > intel_reg-dump-ok
> 3) Lock the screen with gnome (turns off the display)
> 4) Unlock the screen (here I start getting the flickering)
> 5) intel_reg dump > intel_reg-dump-flickering

Oscar, please add drm.debug=14 module parameter, and attach dmesg all the way from boot to repeating the above (no need to redo the dumps, just 1,3,4). Make sure you capture the dmesg for a sequence that reproduces the issue. Thanks.

[Oscar Morante (spacepluk)]

Created attachment 118563
dmesg with drm.debug=14 (boot -> gnome -> lock -> unlock -> flicker)

There you go.

[Oscar Morante (spacepluk)]

Created attachment 118564
dmesg with drm.debug=14 (boot -> gnome -> lock -> unlock -> flicker)

Oops! I mixed up the files. This is the good one.

[Oscar Morante (spacepluk)]

I received an update from Arch Linux and now instead of flickering it stays completely black (but it turns on).

[2015-10-08 08:53] [ALPM] upgraded xf86-video-intel (1:2.99.917+472+gf0fd4d5-1 -> 1:2.99.917+476+g4e668dd-1)

The Arch package doesn't apply any patches and it get's the source straight from git, notice the git SHA's between the "+g" and "-1". I'll upload more debug logs later.

[Oscar Morante (spacepluk)]

Nevermind, I went to capture the logs and now I get the flicker every time... I guess it was just coincidence.

[Oscar Morante (spacepluk)]

Reverting these commits "fixes" the problem on my machine :)

  - https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/patch/?id=4e96c97742f4201edf1b0f8e1b1b6b2ac6ff33e7
  - https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/patch/?id=5fa836a9d85975c5f0f1219669523c1f0ac64349

[Mm-v (mm-v)]

Great news Oscar Morante !

[Oscar Morante (spacepluk)]

Yes, I hope it help to find a proper fix :)

[Jani-nikula (jani-nikula)]

(In reply to Oscar Morante from comment #25)
> Reverting these commits "fixes" the problem on my machine :)
>
> -
> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/patch/
> ?id=4e96c97742f4201edf1b0f8e1b1b6b2ac6ff33e7
> -
> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/patch/
> ?id=5fa836a9d85975c5f0f1219669523c1f0ac64349

commit 4e96c97742f4201edf1b0f8e1b1b6b2ac6ff33e7
Author: Mika Kahola <email address hidden>
Date: Wed Apr 29 09:17:39 2015 +0300

    drm/i915: eDP link training optimization

commit 5fa836a9d85975c5f0f1219669523c1f0ac64349
Author: Mika Kahola <email address hidden>
Date: Wed Apr 29 09:17:40 2015 +0300

    drm/i915: DP link training optimization

Cc: Mika.

[Jani-nikula (jani-nikula)]

Please try this patch:

http://patchwork.freedesktop<email address hidden>

[Twisted-fall (twisted-fall)]

I'm having the same problem on 4.2.x and 4.3 and patch suggested by Jani Nikula doesn't help. Reverting the patches mentioned by Oscar Morante fixes the problem for both 4.2.x and 4.3

[Mika-kahola (mika-kahola)]

Created attachment 119983
Make DP fast link training option as module parameter

I wasn't able to replicate this issue of flickering screen with the HW that I had available. However, that doesn't rule out the fact that there truly is a problem. It seems that there are panels out there that simply doesn't like to start DP link training with non-zero values.

The patch here makes this fast link training feature as one module parameter (/sys/module/i915/parameters/enable_dp_flt) so you can enable or disable the feature depending on panel support. By default this feature is disabled. The patch applies to drm-intel-nightly.

Please, give this patch a try and report back with dmesg log if the problem still exists.

[Lorebett (lorebett)]

I was experiencing the same problem after upgrading to Kubuntu 15.10, kernel 4.2.0-18-generic (Dell m3800); the flickering happens if I switch from a lower resolution than the maximal one, 3200x1800, e.g., 1920x1080).

I tried to apply the latest patch, but it does not apply since I guess it's too new for the sources of 4.2.0-18-generic.

However, reverting the two commits as mentioned in https://bugs.freedesktop.org/show_bug.cgi?id=91393#c25 fixes the problem for me as well!

[Furniss-tom (furniss-tom)]

I applied the patch and it resolved my flickering problem.

[Kimmo Nikkanen (knikkane)]

Assigning to our QA for verification

[Mika-kahola (mika-kahola)]

(In reply to Tom Furniss from comment #33)
> I applied the patch and it resolved my flickering problem.

Thank you for testing! Unfortunately, it turned out we cannot upstream that patch as we do not want to add additional module parameters. Instead, we need to come up with another kind of solution.

[Mika-kahola (mika-kahola)]

Created attachment 120109
DP configuration check

This patch adds additional test and disables fast link training feature if DP link parameters such as link bandwidth, rate selection, lane count, port clock and bpp. If one of these parameter change the fast link training is disabled and link is retrained with the link training parameters starting from zero values. Please, give this patch a go and report back with dmesg if flickering still exists.

[Kimmo Nikkanen (knikkane)]

Lowering the priority.
This is not blocking our work and we haven't been able to reproduce the problem on our side.

[Brad Figg (brad-figg)]

This change was made by a bot.

[Mika-kahola (mika-kahola)]

(In reply to Pavel Procopiuc from comment #86)
> Created attachment 122363 [details]
> dmesg-intel-nightly-patches
>
> Here it is, it's from drm-intel kernel on commit 9f8709f + 3 patches you
> provided. I took a dmesg right after boot (while there was no flickering)
> and then did "xset dpms force off", panel turned off, I waited for a couple
> of seconds, did some input activity, panel turned on and flicker appeared, I
> waited for about 30 seconds and took another dmesg, but there were no
> changes between them. Plus I don't see too much debug information in the
> dmesg. Am I missing some kernel parameter?

Sorry, I forgot to mention that you need to include the following kernel parameters in order to enable debugging info. So, can you rerun the test with these parameters in place, please

drm.debug=0x1e log_buf_len=1M

[Twisted-fall (twisted-fall)]

Created attachment 122405
dmesg-before-flicker

[Twisted-fall (twisted-fall)]

Created attachment 122406
dmesg-after-flicker

Here are the two dmesg dumps, same kernel, same patches, but with the options you mentioned. They are different this time.

One thing I also noticed is that there is not only flicker, but sometimes old screen content is used for a moment. Like in virtual console cursor suddenly jumps back where it was moments ago and then back to its current location. These jumps only happen during flicker.

[Mika-kahola (mika-kahola)]

Created attachment 122497
Cache DP signal levels

In your case, when DP link is retrained with the settings from previous link training the clock recovery fails. This leads into a situation where link training is started from scratch. However, now the clock recovery seems to be happy with the lower voltage swing and pre-emphasis settings than with the first iteration round. You may experience flickering due to this as the physical link may require higher voltage swing or pre-emphasis than provided.

We could try the following trick here. Let's cache the signal levels and in case of link retraining we retrain the link until we have reached the previously trained signal levels and clock recovery is reached.

Please, give this a go on top of the latest drm-intel-nightly with these 3 patches applied. Dmesg logs are appreciated too ;)

[Twisted-fall (twisted-fall)]

Created attachment 122517
dmesg after 0004-drm-i915-Cache-DisplayPort-link-signal-levels.patch

It works, I'm not seeing any flicker or repainting issues anymore. Thank you! I'm still attaching the dmesg. This one covers messages from the boot until about 30 seconds after DPMS.

[Twisted-fall (twisted-fall)]

I was applying patches against 6f78897 of drm-intel. All 4 patches also apply against vanilla 4.5.0 also fixing the issue.

[Mika-kahola (mika-kahola)]

Great that the patches worked out for you. I guess its time to upstream these patches.

[Lorebett (lorebett)]

(In reply to Mika Kahola from comment #93)
> Great that the patches worked out for you. I guess its time to upstream
> these patches.

It would be great if you could upstream it before Ubuntu Xenial is released.

[thomas955 (thoehlig)]

Are these patches in latest-drm-nightly already?

[Mika-kahola (mika-kahola)]

(In reply to thoehlig from comment #95)
> Are these patches in latest-drm-nightly already?

Not yet. These patches needs to be reviewed first.

[nwt (nwt)]

Still having the issue of flickering on my HSW eDP with drm-intel-nightly + v6 patchset + Cache DP signal levels.

Then again my flickering is different and likely a different issue. It's black flashes of the entire screen, for about the same duration yet at seemingly random intervals (incl. when idling) and much less frequent.

[Dave Roberts (vpasvid)]

That sounds much more like the issue I'm seeing, which I raised against Ubuntu Mate (1558736) as it seems to only affect that DE with the 16.04 Beta builds. Both Alphas were fine and other DEs with the same nightlies were fine. However, that bug was marked as a duplicate of this one, though I'm not yet convinced.

I found that the screen wouldn't blank out when I was charging the battery - it only happens when running on battery power. It's a Dell XPS13 9350, with Intel Skylake integrated graphics - more info in https://bugs.launchpad.net/bugs/1558736.

[Alex Forencich (1-alex-c)]

So, eight months since this has been reported and you guys can't even be bothered to at least revert the changes that caused this originally? The normal kernel is completely unusable on my machine due to this issue (Dell XPS 15 (9530)) so I have been forced to run the LTS kernel for the past several months.

[Timo Aaltonen (tjaalton)]

Has the latest patch even been sent to the list? At least I can't find it.

[Mika-kahola (mika-kahola)]

(In reply to Timo Aaltonen from comment #99)
> Has the latest patch even been sent to the list? At least I can't find it.

Indeed, the patch wasn't on the list. Now you can review it from

https://patchwork.freedesktop.org/patch/82206/

However, it seems that there are HW's out there that still have flickering issues.

[Nhellwege (nhellwege)]

I am on a Dell XPS 13 9350 FullHD and I do have the Flicker under Kernel 4.4.0-18 on Ubuntu 16.04 LTS.

I am a bit lost in all these comments, could someone tell me what patch I can try to see if one of your patches has affect on my setup?

There is also a Bug report related to this one over here:

https://bugs.freedesktop.org/show_bug.cgi?id=94593

[Twisted-fall (twisted-fall)]

(In reply to nhellwege from comment #101)
> I am a bit lost in all these comments, could someone tell me what patch I
> can try to see if one of your patches has affect on my setup?

These 4:
https://patchwork.freedesktop.org/patch/69394/
https://patchwork.freedesktop.org/patch/69395/
https://patchwork.freedesktop.org/patch/69396/
https://patchwork.freedesktop.org/patch/82206/

[Nhellwege (nhellwege)]

(In reply to Pavel Procopiuc from comment #102)
> (In reply to nhellwege from comment #101)
> > I am a bit lost in all these comments, could someone tell me what patch I
> > can try to see if one of your patches has affect on my setup?
>
> These 4:
> https://patchwork.freedesktop.org/patch/69394/
> https://patchwork.freedesktop.org/patch/69395/
> https://patchwork.freedesktop.org/patch/69396/
> https://patchwork.freedesktop.org/patch/82206/

On top of drm-intel-nightly or Ubuntu-4.4.0-18?

Thanks!

[Mika-kahola (mika-kahola)]

(In reply to nhellwege from comment #103)
> (In reply to Pavel Procopiuc from comment #102)
> > (In reply to nhellwege from comment #101)
> > > I am a bit lost in all these comments, could someone tell me what patch I
> > > can try to see if one of your patches has affect on my setup?
> >
> > These 4:
> > https://patchwork.freedesktop.org/patch/69394/
> > https://patchwork.freedesktop.org/patch/69395/
> > https://patchwork.freedesktop.org/patch/69396/
> > https://patchwork.freedesktop.org/patch/82206/
>
> On top of drm-intel-nightly or Ubuntu-4.4.0-18?
>
> Thanks!

These applies to drm-intel-nightly.

[Twisted-fall (twisted-fall)]

(In reply to nhellwege from comment #103)
> On top of drm-intel-nightly or Ubuntu-4.4.0-18?

Can't really say anything about 4.4, I successfully applied them on top of 4.5, 4.6 and drm-nightly when I was checking them.

[thomas955 (thoehlig)]

(In reply to Mika Kahola from comment #100)
> (In reply to Timo Aaltonen from comment #99)
> > Has the latest patch even been sent to the list? At least I can't find it.
>
> Indeed, the patch wasn't on the list. Now you can review it from
>
> https://patchwork.freedesktop.org/patch/82206/
>
> However, it seems that there are HW's out there that still have flickering
> issues.

Hi,

today i tested kernel drm-intel-nightly (5f13745078ab86d9833a181980afc7888157a9a4) with patch 82206 applied and i still have the issue that sometimes my external screens turn to black and recover bit later. Sometimes one does not recover at all or is flickering afterwards.

The dmesg log still shows some "[drm:gen8_de_irq_handler] The master control interrupt lied (SDE)!" messages.

More sys infos here.
https://bugs.freedesktop.org/show_bug.cgi?id=94479

[Nhellwege (nhellwege)]

(In reply to Pavel Procopiuc from comment #105)
> (In reply to nhellwege from comment #103)
> > On top of drm-intel-nightly or Ubuntu-4.4.0-18?
>
> Can't really say anything about 4.4, I successfully applied them on top of
> 4.5, 4.6 and drm-nightly when I was checking them.

So I applied all patches to drm-intel-next-2016-03-30 (tag from drm-intel-nightly). I still do have my specific error (underrun FIFO), which apparently results into black screen flickering:

[ 1.307318] [drm] Finished loading i915/skl_dmc_ver1.bin (v1.26)
[ 1.332959] [drm] Initialized i915 1.6.0 20160330 for 0000:00:02.0 on minor 0
[ 2.711324] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device
[ 3.267095] snd_hda_intel 0000:00:1f.3: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915])
[ 50.860161] i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment
[ 55.077891] i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment
[ 55.333444] [drm:intel_dp_link_training_clock_recovery [i915]] *ERROR* too many voltage retries, give up
[ 728.412055] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun

Thanks anyways, it was worth a try.

btw: The bogus alignment and training clock error was after I recovered from suspend.

[Rodrigo-vivi (rodrigo-vivi)]

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

[Alex Forencich (1-alex-c)]

Dammit. Now this regression has made it into the LTS kernel. Are you guys kidding me? Is it not possible for the changes that caused this exceptionally annoying regression (as in my computer is now almost entirely unusable) to be removed from the current production kernel, pending a proper fix?????

[Jeremy LaCroix (j-jlacroix)]

I found something interesting that may or may not be valuable. From what I can gather so far, we're dealing with two flicker issues. One affects only Ubuntu MATE, the other affects regular Ubuntu as well. For me, I've been able to work around the problem in Ubuntu MATE by disabling tlp.service and rebooting. After I do this, I no longer deal with any flickering at all whatsoever. This work around won't work for everyone, but if you are hitting the bug in Ubuntu MATE (since Ubuntu MATE features tlp.service by default) this may work for you.

Even though disabling tlp.service fixes it for me, this is still a kernel bug, because I can also fix this issue by side-loading an unsupported kernel without disabling tlp.service and that fixes it too. For whatever reason, tlp.service is triggering something in the kernel causing a flicker.

[Mika-kahola (mika-kahola)]

(In reply to alex from comment #109)
> Dammit. Now this regression has made it into the LTS kernel. Are you guys
> kidding me? Is it not possible for the changes that caused this
> exceptionally annoying regression (as in my computer is now almost entirely
> unusable) to be removed from the current production kernel, pending a proper
> fix?????

My current understanding is that there are multiple causes for flickering. Reverting this patch may solve an issue with one platform. Could you share your dmesg log with drm.debug=0x1e for further analysis, please.

[Alex Forencich (1-alex-c)]

Created attachment 123264
systemd logs with drm.debug=0x1e for stock 4.5.1 kernel (arch) with flicker after standby

[Alex Forencich (1-alex-c)]

(In reply to Mika Kahola from comment #110)
> (In reply to alex from comment #109)
> > Dammit. Now this regression has made it into the LTS kernel. Are you guys
> > kidding me? Is it not possible for the changes that caused this
> > exceptionally annoying regression (as in my computer is now almost entirely
> > unusable) to be removed from the current production kernel, pending a proper
> > fix?????
>
> My current understanding is that there are multiple causes for flickering.
> Reverting this patch may solve an issue with one platform. Could you share
> your dmesg log with drm.debug=0x1e for further analysis, please.

Posted. I rebooted into the stock 4.5.1 kernel (direct from the Arch repository) with drm.debug=0x1e added to the kernel command line, logged in, suspended, resumed, and dumped the log with journalctl. I took a quick check through and didn't see any messages that indicated any sort of failure after the suspend operation. However there are a lot of messages in there, so I could have missed something. What I do know is that after the resume from suspend, I get something on the order of a 2 Hz flicker on the display that looks like the eDP link is flapping - i.e. there is tearing that affects the bottom portion of the display more than the top due to the link going down in the middle of a frame, portions of the display are briefly distorted or colored strangely, etc. None of this happens on 4.1.21, which is where I will stay until this gets a proper fix in the mainline.

[Mika-kahola (mika-kahola)]

(In reply to alex from comment #112)
> (In reply to Mika Kahola from comment #110)
> > (In reply to alex from comment #109)
> > > Dammit. Now this regression has made it into the LTS kernel. Are you guys
> > > kidding me? Is it not possible for the changes that caused this
> > > exceptionally annoying regression (as in my computer is now almost entirely
> > > unusable) to be removed from the current production kernel, pending a proper
> > > fix?????
> >
> > My current understanding is that there are multiple causes for flickering.
> > Reverting this patch may solve an issue with one platform. Could you share
> > your dmesg log with drm.debug=0x1e for further analysis, please.
>
> Posted. I rebooted into the stock 4.5.1 kernel (direct from the Arch
> repository) with drm.debug=0x1e added to the kernel command line, logged in,
> suspended, resumed, and dumped the log with journalctl. I took a quick
> check through and didn't see any messages that indicated any sort of failure
> after the suspend operation. However there are a lot of messages in there,
> so I could have missed something. What I do know is that after the resume
> from suspend, I get something on the order of a 2 Hz flicker on the display
> that looks like the eDP link is flapping - i.e. there is tearing that
> affects the bottom portion of the display more than the top due to the link
> going down in the middle of a frame, portions of the display are briefly
> distorted or colored strangely, etc. None of this happens on 4.1.21, which
> is where I will stay until this gets a proper fix in the mainline.

It seems that you have similar issue than we have seen before. During resume, the display driver tries to use the DP link parameters that was computed during the initial boot. However, the clock recovery is not obtained and hence the DP link is retrained. At this stage, the driver tries with 0 voltage swing and no pre-emphasis. For some reason the clock recovery is obtained and the DP link is set up with lower voltage swing and pre-emphasis settings than after the initial boot.

I suggest that you try all these 4 patches on top of the drm-intel-nightly and report back if this set provides a fix or not

https://patchwork.freedesktop.org/patch/69394/
https://patchwork.freedesktop.org/patch/69395/
https://patchwork.freedesktop.org/patch/69396/
https://patchwork.freedesktop.org/patch/82206/

[Jani-nikula (jani-nikula)]

Everyone hitting the issue, please attach /sys/kernel/debug/dri/0/i915_vbt (or if that doesn't exist, i915_opregion).

Mika, just an idea... please check the vswing/pre-emph values in VBT. I'm not sure if we parse them in either the driver or intel_bios_reader. Check the VBT spec. Perhaps the VBT values are what we should be using regardless of what the actual link training does.

[Epoirier-j (epoirier-j)]

Simple question for anyone.

What step would you have to do to apply these patch

https://patchwork.freedesktop.org/patch/69394/
https://patchwork.freedesktop.org/patch/69395/
https://patchwork.freedesktop.org/patch/69396/
https://patchwork.freedesktop.org/patch/82206/

[Lorebett (lorebett)]

There's one thing I still don't understand... the root of the problem was identified in https://bugs.freedesktop.org/show_bug.cgi?id=91393#c25

why hasn't an option to disable the introduced feature been introduced so far? Or even more, why not reverting completely? The introduced feature does not work for many of us, making the system unusable, which means that the feature does not work, period.

while on kernel 4.2 that's the only option for me: download the kernel sources in ubuntu and revert the two commits and recompile.

Would reverting the two commits still work on the new Ubuntu which comes with kernel 4.4?

[Boris Erdmann (boris-erdmann)]

I am affected by this bug on dell xps 13 9350 both on FHD and QHD. Running kernel 4.6rc5 from http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.6-rc5-wily/ helps as a work-around.

[Boris Erdmann (boris-erdmann)]

Update: Now this bug is fixed for me in http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.4.9-xenial/ as well.

[John Smith (atesting)]

I'm having this same issue on a Dell 7537 running Ubuntu 16.10 (kernel 4.8).

The flickering that occurs is a rapid change in the brightness of the screen, in a random, persistently manner (it never stops).
Not so often the screen goes all white and quickly returns to normal.

It's interesting to mention that on Ubuntu 16.04 (kernel 4.4) the bug appears to be fixed, as the flickering does not occur.

[kecsap (csaba-kertesz)]

@John Smith: I have two older laptops with Intel chips, one Westmere and one Ivy Bridge architecture. Only one solution fixed the screen flickers on both laptop, installing the drm-intel-nightly kernel:

http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-nightly/current/

I use this suggested config for Xorg, but I don't think it has any effect:

Section "Device"
   Identifier "Intel Graphics"
   Driver "intel"
   Option "AccelMethod" "sna"
   Option "TearFree" "true"
   Option "DRI" "3"
EndSection

I tried many kernels versions, tinkering with the Xorg configm, but the nightly kernel was the real cure to use the intel driver in Xorg on my laptops.

[Kevin (kevinhaefeli)]

I've a MacBook Pro, 4k Monitor from Samsung and the error / flickering occurs with the latest nightly build:

[ 4921.690599] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun

Linux kevin-MacBookPro 4.10.0-994-generic #201612282215 SMP Thu Dec 29 03:17:19 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

[JulienIsorce (julien-isorce)]

It happens for me with kernel 4.8.0-34-generic #36~16.04.1-Ubuntu .
with xorg.conf from comment #129.
The flashs start to appear once there is the message pointed in #130, i.e.:
[drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun .
The message appears only once for the first flash and then the flash appear more often but no more message in /var/log/kern.log. Adding drm.debug=14 does not enable more messages in that case.

[molecule-eye (niburu1)]

As comment #117 suggests, disabling tlp fixes it for my Broadwell Celeron laptop. However, another way to fix it (at least for some of us) is to set ALPM to a higher power state, which means you can keep tlp enabled. In the tlp config file /etc/default/tlp, set the line SATA_LINKPWR_ON_BAT=min_power to SATA_LINKPWR_ON_BAT=medium_power or to SATA_LINKPWR_ON_BAT=max_performance. If not running tlp, add the same line to /etc/pm/config.d/sata_alpm (and probably also for SATA_LINKPWR_ON_AC).

The problem with this solution is that on chips where the southbridge and cpu are packaged together (Broadwell, Haswell, etc.), the package won't go into lower power states, so battery suffers. For instance, I can't get it into anything lower than C2, as powertop indicates.