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.

[Lorebett (lorebett)]

(In reply to Mika Kahola from comment #36)
> Created attachment 120109 [details] [review]
> 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.

To which kernel should this patch be applied?

[Mika-kahola (mika-kahola)]

(In reply to Lorenzo Bettini from comment #38)
> (In reply to Mika Kahola from comment #36)
> > Created attachment 120109 [details] [review] [review]
> > 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.
>
> To which kernel should this patch be applied?

This should apply to drm-intel-nightly. I received a feedback concerning this patch and I updated it. An updated version can be found

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

[Luke-hutchison (luke-hutchison)]

I see significant flickering for about 2-3 minutes every time I resume from RAM in Fedora 23 (kernel 4.2.6-300.fc23.x86_64). The problem was also present in Fedora 22.

- External monitor (Crossover brand), connected via DP
- Intel HD Graphics 4600

Strangely, sometimes opening a terminal window with black background (even in non-fullscreen mode) stops the flickering, but if I minimize the window again, the flickering resumes.

I don't see anything strange in the logs.

[Mika-kahola (mika-kahola)]

That is a bit strange. Could you provide a dmesg log with the option drm.debug=0xe?

[Furniss-tom (furniss-tom)]

(In reply to Mika Kahola from comment #36)
> Created attachment 120109 [details] [review]
> 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.

Hi Mika. Your second patch also fixes the problem for me. After removing your first patch and applying the second the flickering issue did not recur.

[Brad Figg (brad-figg)]

This change was made by a bot.

[flux242 (flux242)]

hi, I'm also experiencing bad flickering of my laptop screen.
I have installed xubuntu 15.10 on Acer C740:

a@chrome:~$ 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: 08
       width: 64 bits
       clock: 33MHz
       capabilities: msi pm vga_controller bus_master cap_list rom
       configuration: driver=i915 latency=0
       resources: irq:43 memory:e0000000-e0ffffff memory:d0000000-dfffffff ioport:1800(size=64)

a@chrome:~$ uname -a
Linux chrome 4.2.0-19-generic #23-Ubuntu SMP Wed Nov 11 11:39:30 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

But today display was blanked after 15 minutes of inactivity and when I woken it up I saw no more flickering and this kernel message:
Dec 5 10:16:48 chrome kernel: [ 3708.390613] [drm:intel_dp_start_link_train [i915]] *ERROR* failed to enable link training

please suggest a way (usingn a kernel parameter) to disable link training until a bugfix is backported

[flux242 (flux242)]

(In reply to flux242 from comment #43)
> hi, I'm also experiencing bad flickering of my laptop screen.
> I have installed xubuntu 15.10 on Acer C740:
>
> a@chrome:~$ 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: 08
> width: 64 bits
> clock: 33MHz
> capabilities: msi pm vga_controller bus_master cap_list rom
> configuration: driver=i915 latency=0
> resources: irq:43 memory:e0000000-e0ffffff memory:d0000000-dfffffff
> ioport:1800(size=64)
>
> a@chrome:~$ uname -a
> Linux chrome 4.2.0-19-generic #23-Ubuntu SMP Wed Nov 11 11:39:30 UTC 2015
> x86_64 x86_64 x86_64 GNU/Linux
>
> But today display was blanked after 15 minutes of inactivity and when I
> woken it up I saw no more flickering and this kernel message:
> Dec 5 10:16:48 chrome kernel: [ 3708.390613] [drm:intel_dp_start_link_train
> [i915]] *ERROR* failed to enable link training
>
> please suggest a way (usingn a kernel parameter) to disable link training
> until a bugfix is backported

I need to add some additional info. Ive managed to reproduce the case when after screen blanking there's no flickering anymore. I start the 'xset dpms force off' command to blank the screen and after a pause I press a button to wake it up. Below is a pastebin when flickering persist after waking up:
http://pastebin.com/fuY57tMH

And here is a pastebin when the flickering is gone after waking up:
http://pastebin.com/4gGMTycL

It was really difficult to reproduce the case when the flicker is gone

[Furniss-tom (furniss-tom)]

Just wanted to summarise the progress against the original problem, which may or may not be related to some of these other issues, and to add some test detail.

The original problem was a continually flickering screen, starting part-way through boot and prior to the login screen, and affected the extended display port of the laptop screen only, not external monitors.

Mika's original patch fixed this issue, removing the flicker, but during QA Mika was asked to modify it to remove kernel parameters. Mika's revised (second) patch also resolved the issue.

With both of Mika's patches there were still some graphics issues:
1) Initial blank screen on boot.
2) Occasional blinking of the graphics, ranging from every few seconds to every 2-3 minutes. The blink lasted only a fraction of a second, and whilst noticeable it wasn't a major concern.
3) The flickering returned when resuming from sleep.

Issue 1 was a relatively common brightness issue, and was resolved by using kernel parameter acpi_osi=linux, and running this command automatically on startup, "setpci -s 00:02.0 F4.B=00". This also resolved issue 2, removing the occasional blink.

Issue 3 remains.

[Oscar Morante (spacepluk)]

I applied the latest patch from Mika on top of drm-intel-nightly and it's been working great for the last couple of days. Suspending or changing resolution doesn't cause flicker anymore, and it also seems to have fixed the ocassional one frame blackout I had before (which still happens on windows btw).

I didn't need any extra configuration like Tom, it just worked out of the box. I'll let you know if something changes but it seems to be fixed on my system.

Thanks!

[Mika-kahola (mika-kahola)]

(In reply to Oscar Morante from comment #46)
> I applied the latest patch from Mika on top of drm-intel-nightly and it's
> been working great for the last couple of days. Suspending or changing
> resolution doesn't cause flicker anymore, and it also seems to have fixed
> the ocassional one frame blackout I had before (which still happens on
> windows btw).
>
> I didn't need any extra configuration like Tom, it just worked out of the
> box. I'll let you know if something changes but it seems to be fixed on my
> system.
>
> Thanks!

Great to hear that the patch worked out for you!

[Mika-kahola (mika-kahola)]

Created attachment 120389
Check if DP training set applied ok

Tom reported that flickering occurs when resuming back from the sleep. When resuming we are already trained the DP link and most probably reusing the DP link parameters when retraining the link. It may be possible that setting the DP training pattern fails yielding an error message of "*ERROR* failed to enable link training". This patch introduces a check to the routine that applies the DP training pattern. If this check fails, the link training is restarted by setting the parameters to zero.

The patch applies on top of the latest drm-intel-nightly and requires this https://patchwork.freedesktop.org/patch/66697/ patch to be applied

[Furniss-tom (furniss-tom)]

Created attachment 120480
Syslog for resume from sleep flickering

Sleep initiated at 13:03.

[Furniss-tom (furniss-tom)]

Created attachment 120481
dmesg for resume from sleep flickering

[Furniss-tom (furniss-tom)]

Mika - firstly thank you for fixing the original issue, it's great to be able to use the laptop.

I've applied your additional patch and the flickering on resume from sleep continues. I've uploaded the dmesg and syslog - there is a lot of drm debug in the syslog after the resume from sleep.

[B25ae2 (b25ae2)]

I've experienced exactly the same problem, as Tom Furniss described.
Kernel version: 4.2.6-301.fc23.x86_64
dmesg with drm.debug=14 attached.
I'm failed to apply patches, files structure in drivers/gpu/drm/i915/ is slightly different.
If there is any other options for me to fix issue?

[B25ae2 (b25ae2)]

Created attachment 120485
dmesg with drm.debug=14

[Mika-kahola (mika-kahola)]

(In reply to Andrew Merzlyakov from comment #52)
> I've experienced exactly the same problem, as Tom Furniss described.
> Kernel version: 4.2.6-301.fc23.x86_64
> dmesg with drm.debug=14 attached.
> I'm failed to apply patches, files structure in drivers/gpu/drm/i915/ is
> slightly different.
> If there is any other options for me to fix issue?

These patches apply to drm-intel-nightly kernel which is a development tree for i915 driver. You can clone the git repository from

https://01.org/linuxgraphics/documentation/development/source-code

and apply these patches on top of it. I'm afraid, this is the only option at the moment to get these issues fixed. Eventually, these patches will be upstreamed as fixes.

[Mika-kahola (mika-kahola)]

Created attachment 120493
Disable fast link training when resuming

Tom - thank you for you feedback and logs. I think I need to disable the fast link training feature when resuming from the suspend state. This patch does just that in case of DP or eDP connectors. Please, test this patch if this would provide a solution for this resuming issue.

[flux242 (flux242)]

(In reply to Mika Kahola from comment #54)
> These patches apply to drm-intel-nightly kernel which is a development tree
> for i915 driver. You can clone the git repository from
>
> https://01.org/linuxgraphics/documentation/development/source-code
>
> and apply these patches on top of it. I'm afraid, this is the only option at
> the moment to get these issues fixed. Eventually, these patches will be
> upstreamed as fixes.

well, eventually means it could take halve a year until we got those patches which makes our computers useless. I can also add that on my computer I cannot enable vesa mode and i915.modeset=0 option makes the screen black, i.e. bricks it. Reverting two patches for the ubuntu's 4.2.0.19 kernel like it was described above doesn't help either. I tried to figure out how to apply your patch onto 4.2.0.19 but it seems like training staff was moved out of the intel_dp.c and some files are missing completely, so no luck.

Cloning the 1Gigabyte git repo like you suggest would also mean that I'd need to compile drm driver code with the kernel version that in that repo too right? Or I can copy the gpu/drm/i915 over to my kernel version and it'll work?

[B25ae2 (b25ae2)]

> Cloning the 1Gigabyte git repo like you suggest would also mean that I'd
> need to compile drm driver code with the kernel version that in that repo
> too right? Or I can copy the gpu/drm/i915 over to my kernel version and
> it'll work?

Yes, you must rebuild kernel with updated drm driver and applied patches.

[Furniss-tom (furniss-tom)]

(In reply to Mika Kahola from comment #55)
> Created attachment 120493 [details] [review]
> Disable fast link training when resuming
>
> Tom - thank you for you feedback and logs. I think I need to disable the
> fast link training feature when resuming from the suspend state. This patch
> does just that in case of DP or eDP connectors. Please, test this patch if
> this would provide a solution for this resuming issue.

Hi Mika

Just a quick update as I'm away from my test laptop until the end of the week. The patch did not resolve the issue, though interestingly the flickering appears from the time the suspend sequence starts rather than on resume (the screen starts flickering before it turns off).

I'll test more thoroughly and post logs at the weekend.

[flux242 (flux242)]

patch https://patchwork.freedesktop.org/patch/66697/ DOESN'T solve the flickering problem on my computer.

What I did:
1. installed generic kernel and headers from http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-nightly/2015-12-24-wily/
2. get the sources from the git://anongit.freedesktop.org/drm-intel branch drm-intel-nightly (commit number: ec0382c73cb1adc972bebdd94afad3f0ea117114)
3. applied the patch https://patchwork.freedesktop.org/patch/66697/
4. compiled the i915 driver and installed it:

mykern=${1:-$(uname -r)}
cp /usr/src/linux-headers-$mykern/Module.symvers .

# Prep tree
cp /boot/config-$mykern ./.config
make oldconfig
make prepare
make modules_prepare

# Build only the needed directories
make SUBDIRS=drivers/gpu/drm/i915 modules
[ -s /lib/modules/$mykern/kernel/drivers/gpu/drm/i915/i915.ko.orig ] || sudo cp /lib/modules/$mykern/kernel/drivers/gpu/drm/i915/i915.ko{,.orig}
sudo cp drivers/gpu/drm/i915/i915.ko /lib/modules/$mykern/kernel/drivers/gpu/drm/i915/
5. reboot

But. Now with the kernel 4.4.xx if I run 'xset dpms force off' just after the boot then the flicker is gone.

grep of the last boot syslog:
$ grep drm /tmp/syslog
Dec 24 11:29:49 chrome kernel: [ 2.028119] [drm] Initialized drm 1.1.0 20060810
Dec 24 11:29:49 chrome kernel: [ 2.066980] [drm] Memory usable by graphics device = 4096M
Dec 24 11:29:49 chrome kernel: [ 2.066985] [drm] Replacing VGA console driver
Dec 24 11:29:49 chrome kernel: [ 2.067495] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
Dec 24 11:29:49 chrome kernel: [ 2.067498] [drm] Driver supports precise vblank timestamp query.
Dec 24 11:29:49 chrome kernel: [ 2.067501] [drm] failed to find VBIOS tables
Dec 24 11:29:49 chrome kernel: [ 2.210886] [drm] Initialized i915 1.6.0 20151218 for 0000:00:02.0 on minor 0
Dec 24 11:29:49 chrome kernel: [ 2.211478] fbcon: inteldrmfb (fb0) is primary device
Dec 24 11:29:49 chrome kernel: [ 3.021978] [drm:intel_dp_link_training_clock_recovery [i915]] *ERROR* failed to enable link training
Dec 24 11:29:49 chrome kernel: [ 3.025516] [drm:intel_dp_start_link_train [i915]] *ERROR* failed to start channel equalization
Dec 24 11:29:49 chrome kernel: [ 3.206466] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device
Dec 24 11:30:13 chrome kernel: [ 29.162270] [drm:intel_dp_link_training_clock_recovery [i915]] *ERROR* failed to enable link training

[Furniss-tom (furniss-tom)]

Created attachment 120678
syslog for sleep/resume flickering issue

Mika - this is the syslog for the flickering on resume from sleep, after applying your latest patch (https://bugs.freedesktop.org/attachment.cgi?id=120493)

I do fairly consistently see a single flicker after requesting sleep, and before the laptop sleeps. This may or may not be the flickering issue, so I can't be certain whether the problem starts on requesting sleep mode, or on resuming from sleep.

[Mika-kahola (mika-kahola)]

Thank you Tom for the syslog. From the log the DP link training is completed but for some reason the DP channel equalization fails. At this point we request to do link training once again and now first we try first the drive current and pre-emphasis levels from the previous link training. Instead of reusing these values, we should restart the link training with zero drive current and pre-emphasis levels. This is fixed at the 3rd patch of this series.

Please, try out this series of patches on top of the drm-intel-nighly and report back.

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

flux242 seems to have a clock recovery issue. This fix may provide a solution for that as well.

[Furniss-tom (furniss-tom)]

Created attachment 120818
syslog after three patches and returned flicker

Hi Mika.

I seem to have regressed, and the flicker has returned. I took a new branch of intel-drm-nightly, and applied the three patches in the sequence you provided, but the flickering has returned and is consistent on every boot.

Previously I had applied patches from this defect against a version of intel-drm-next from late November.

The attached files are the syslog and dmesg.

[Furniss-tom (furniss-tom)]

Created attachment 120819
dmesg after three patches and returned flicker

[flux242 (flux242)]

> https://patchwork.freedesktop.org/patch/69394/
> https://patchwork.freedesktop.org/patch/69395/
> https://patchwork.freedesktop.org/patch/69396/
>
> flux242 seems to have a clock recovery issue. This fix may provide a
> solution for that as well.

three patches above (without the https://patchwork.freedesktop.org/patch/66697/) do not help

[Rodrigo-vivi (rodrigo-vivi)]

Seeing the video again and based on recent issues I faced I believe this could be watermark related...
So, could you please apply http://patchwork.freedesktop.org/patch/69417/
and boot with i915.enable_watermark=0 and let us know what happens?

[Furniss-tom (furniss-tom)]

(In reply to Rodrigo Vivi from comment #65)
> Seeing the video again and based on recent issues I faced I believe this
> could be watermark related...
> So, could you please apply http://patchwork.freedesktop.org/patch/69417/
> and boot with i915.enable_watermark=0 and let us know what happens?

The watermark patch did not affect the symptoms of this problem, Rodrigo. I think Mika is on the right track, having solved the initial problem (persistent flickering) by modifying the eDP link training. The remaining problem is that the flickering recurs when the display resumes from sleep.

[flux242 (flux242)]

> think Mika is on the right track, having solved the initial problem
> (persistent flickering) by modifying the eDP link training. The remaining
> problem is that the flickering recurs when the display resumes from sleep.

in my case flickering occur just after reboot (and this is not the same flickerin art like in the video). Then I need to run 'xset dpms force off' command in the terminal at least once or many times until flickering is gone. Afterwards I see no flickering any longer even if it resumes from sleep. I can add that on the same hardware chromiumos works flawlessly.

[Mika-kahola (mika-kahola)]

Created attachment 120893
DP debugging

Tom, I would bother you again to provide some debugging info. From the dmesg you sent it seems that you are experiencing a lot of hpd interrupts. When that happens the driver checks if the DP channel equalization is still ok. On your case, channel equalization is not ok yielding DP link to be retrained. Of course, this causes flickering as the DP link is broken for some time. The patch I'm proposing for debugging purposes applies on top of the latest -nightly and on top of these previous patches

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

The patch adds more verbose debug information on channel equalization and limits the DP link retraining to 5. After 5 attempts to retrain the link you probably end up having a non-flickering display or a black screen. Please, report back with dmesg.

[Furniss-tom (furniss-tom)]

Created attachment 120919
syslog for 3 patches with increased debug

Hi Mika

No problem. I applied the following patches to the latest drm-intel-nightly:
https://patchwork.freedesktop.org/patch/69394/
https://patchwork.freedesktop.org/patch/69395/
https://patchwork.freedesktop.org/patch/69396/
https://bugs.freedesktop.org/attachment.cgi?id=120893

As expected, flickering is still present. syslog attached.

The last patch that fixed the issue was this:
https://patchwork.freedesktop.org/patch/66697/
Is there a reason we're not using it now?

[Furniss-tom (furniss-tom)]

Created attachment 120920
dmesg for 3 patches with increased debug

[Mika-kahola (mika-kahola)]

(In reply to Tom Furniss from comment #69)
> Created attachment 120919 [details]
> syslog for 3 patches with increased debug
>
> Hi Mika
>
> No problem. I applied the following patches to the latest drm-intel-nightly:
> https://patchwork.freedesktop.org/patch/69394/
> https://patchwork.freedesktop.org/patch/69395/
> https://patchwork.freedesktop.org/patch/69396/
> https://bugs.freedesktop.org/attachment.cgi?id=120893
>

Thank you Tom for providing a log. The issue still persists and you keep receiving a lot of short hotplug detection pulses.

> As expected, flickering is still present. syslog attached.
>
> The last patch that fixed the issue was this:
> https://patchwork.freedesktop.org/patch/66697/
> Is there a reason we're not using it now?
During the patch review I received comments that I should move the idea of tracking the config changes to its current location in patch https://patchwork.freedesktop.org/patch/69394/

If you have time, it would be interesting to know if you apply this patch https://patchwork.freedesktop.org/patch/66697/
on top of current -nightly and check if it still fixes the flickering.

[Furniss-tom (furniss-tom)]

Hi Mika

Yes, applying patch 66697 against the latest intel-drm-nightly does still resolve the issue.

[Alberto Salvia Novella (es20490446e)]

Also reported in (https://bugs.launchpad.net/ubuntu/+source/libdrm/+bug/1522922).

[Furniss-tom (furniss-tom)]

(In reply to Tom Furniss from comment #72)
> Hi Mika
>
> Yes, applying patch 66697 against the latest intel-drm-nightly does still
> resolve the issue.

Actually, within 10 seconds of posting that message the flickering started again, and has continued through multiple reboots. So I think I can safely say that the last version of the kernel patched with 66697 that resolved the issue was 4.3.0 rc3.

[Mika-kahola (mika-kahola)]

It seems that we have something else causing a regression than this link training optimization feature. Any chance to do bisecting with patch 66697 applied?

[Yulian (yu-kalev)]

Finally got the dump just as the monitor started to flicker.

[Yulian (yu-kalev)]

Created attachment 121148
In my case it crashes the PC. Got a kdump.

see also https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1535048

[Jose Luis Rivitti (jlrivitti)]

I have a similar problem since 2014.

https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1271704

Toshiba Satellite S75-A7334, i7-4700MQ.

*-display
     descrição: VGA compatible controller
     produto: 4th Gen Core Processor Integrated Graphics Controller
     fabricante: Intel Corporation
     ID físico: 2
     informações do barramento: pci@0000:00:02.0
     versão: 06
     largura: 64 bits
     clock: 33MHz
     capacidades: msi pm vga_controller bus_master cap_list rom
     configuração: driver=i915 latency=0
     recursos: irq:45 memória:b2000000-b23fffff memória:a0000000-afffffff porta de E/S:6000(tamanho=64)

Ubuntu 15.10.
Linux 3.13.0-37-generic #64-Ubuntu
intel-linux-graphics-installer_1.2.1-0intel2_amd64.deb

filename: /lib/modules/3.13.0-37-generic/kernel/drivers/gpu/drm/i915/i915.ko
license: GPL and additional rights
description: Intel Graphics
author: Tungsten Graphics, Inc.
license: GPL and additional rights
srcversion: 594AF6054E9069A37423B0F
vermagic: 3.13.0-37-generic SMP mod_unload modversions
signer: Magrathea: Glacier signing key
sig_key: 2C:B1:13:3B:35:F9:5A:9E:24:DE:AB:EE:B1:2B:A4:49:BC:BA:BB:C9

Almost of time the screen turns grey colors and stops flickering. Then, I have to try change screen resolution many times until colors are back, and the flickering.

I have tried several screen resolutions and frequencies, including the configuration that works fine with graphic Gallium 0.4 on llvmpipe (LLVM 3.6, 256 bits), that I got when I boot in recovery mode, choose failsafeX and I stop the process with CTRL+C just after the X error.

[Perec Fix (perecfx)]

This bugs affects my m3800 on Ubuntu 15.10 with Unity desktop. Flickering seen with linux kernel 4.2, 4.3 and 4.4.
No flickering only when I run kernel 3.19

[Lorenzo Bettini (bettini)]

In http://www.lorenzobettini.it/2015/12/flickering-for-intel-graphic-card-in-linux-4-2/ I described the steps to revert the two commits that seem to have introduced the flickering. This requires downloading the kernel sources, revert the two commits, compile the kernel and install the locally built packages.

This bug is particularly annoying, and each time a new upgrade on the kernel is released the above procedure has to be performed again.

Not to mention that this bug makes the system unusable (if the above procedure is not performed).

I think that the "importance" should be brought back to "Critical" (assuming that "Critical" is higher than "High").

[Jose Luis Rivitti (jlrivitti)]

I reinstalled Ubuntu 15.10 from a DVD iso. Problem fixed.
Linux toshibaS75 4.2.0-27-generic #32-Ubuntu SMP Fri Jan 22 04:49:08 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

[Lorebett (lorebett)]

(In reply to jlrivitti from comment #78)
> I reinstalled Ubuntu 15.10 from a DVD iso. Problem fixed.
> Linux toshibaS75 4.2.0-27-generic #32-Ubuntu SMP Fri Jan 22 04:49:08 UTC
> 2016 x86_64 x86_64 x86_64 GNU/Linux

I've just tried 4.2.0-27-generic and the flickering is still there

[Lorebett (lorebett)]

I tested ubuntu Xenial beta, which has the following kernel

Linux ubuntu 4.4.0-9-generic #24-Ubuntu SMP Mon Feb 29 19:33:19 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

The bug is still there...

it happens not only if you decrease the resolution, but also with the higher resolution after resuming from screen saver.

[nwt (nwt)]

Started a few weeks ago to get this with my HSW 4200U laptop. Dunno the exact date, but I've been using drm-intel-nightly all the time, so presumably since PSR was default enabled.

/sys/kernel/debug/dri/0/i915_edp_psr_status
Sink_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: 50578

/sys/kernel/debug/dri/0/i915_fbc_status
FBC disabled: FBC enabled (active or scheduled)
Compressing: yes

/sys/kernel/debug/dri/0/i915_ips_status
Enabled by kernel parameter: yes
Currently: enabled

I've tried with the v6 "Disable fast link training if DP config changes" patchset applied, no apparent change.

[Twisted-fall (twisted-fall)]

Created attachment 122338
no-flicker-after-dpms-4.5.patch

Kernel 4.5.0 still has this bug for me. I managed to narrow down the patch to remedy the flickering to just one hunk though.

[Mika-kahola (mika-kahola)]

(In reply to Pavel Procopiuc from comment #82)
> Created attachment 122338 [details] [review]
> no-flicker-after-dpms-4.5.patch
>
> Kernel 4.5.0 still has this bug for me. I managed to narrow down the patch
> to remedy the flickering to just one hunk though.

Did you try these patches?
https://patchwork.freedesktop.org/patch/69394/
https://patchwork.freedesktop.org/patch/69395/
https://patchwork.freedesktop.org/patch/69396/

In addition, if you could provide your dmesg log as well. I would be interested to know if we fail on clock recovery or not.

[Twisted-fall (twisted-fall)]

I tried them way back in January with no visible difference, flickering still appears after laptop panel turns off and back on.

Regarding dmesg, can you please tell me for which kernel you want to see it (intel-drm-next/vanilla), with those patches or without and which additional kernel debugging options should be enabled?

[Mika-kahola (mika-kahola)]

(In reply to Pavel Procopiuc from comment #84)
> I tried them way back in January with no visible difference, flickering
> still appears after laptop panel turns off and back on.
>
> Regarding dmesg, can you please tell me for which kernel you want to see it
> (intel-drm-next/vanilla), with those patches or without and which additional
> kernel debugging options should be enabled?

If you can run dmesg with drm-intel-nightly kernel and if you could apply those patches too, so we could get more debug info as well.

[Twisted-fall (twisted-fall)]

Created attachment 122363
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?

[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.