Bug 91393 - [bdw edp] Screen Flickering
Summary: [bdw edp] Screen Flickering
Status: RESOLVED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: high normal
Assignee: Mika Kahola
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-07-19 11:17 UTC by Tom Furniss
Modified: 2016-06-29 09:46 UTC (History)
20 users (show)

See Also:
i915 platform: BDW
i915 features: display/eDP


Attachments
dmesg (442.02 KB, text/plain)
2015-07-19 11:17 UTC, Tom Furniss
no flags Details
intel-reg-dumper (9.26 KB, text/plain)
2015-07-19 11:18 UTC, Tom Furniss
no flags Details
edid file (128 bytes, text/plain)
2015-07-19 11:18 UTC, Tom Furniss
no flags Details
xrandr --verbose (5.11 KB, text/plain)
2015-07-19 11:19 UTC, Tom Furniss
no flags Details
xorg log (20.72 KB, text/plain)
2015-07-19 14:17 UTC, Tom Furniss
no flags Details
intel_reg dump with i915.modeset=0 (17.10 KB, text/plain)
2015-09-21 13:38 UTC, Tom Furniss
no flags Details
intel_reg dump with i915.modeset=1 (17.05 KB, text/plain)
2015-09-21 13:40 UTC, Tom Furniss
no flags Details
intel_reg dump before the flicker happens (17.65 KB, text/plain)
2015-09-30 13:35 UTC, Oscar Morante
no flags Details
intel_reg dump while the flicker is happening (17.65 KB, text/plain)
2015-09-30 13:36 UTC, Oscar Morante
no flags Details
dmesg with drm.debug=14 (boot -> gnome -> lock -> unlock -> flicker) (59.22 KB, text/plain)
2015-10-01 16:48 UTC, Oscar Morante
no flags Details
dmesg with drm.debug=14 (boot -> gnome -> lock -> unlock -> flicker) (123.42 KB, text/plain)
2015-10-01 16:50 UTC, Oscar Morante
no flags Details
Make DP fast link training option as module parameter (2.03 KB, patch)
2015-11-20 13:14 UTC, Mika Kahola
no flags Details | Splinter Review
DP configuration check (2.95 KB, patch)
2015-11-25 10:23 UTC, Mika Kahola
no flags Details | Splinter Review
Check if DP training set applied ok (1.15 KB, patch)
2015-12-07 15:00 UTC, Mika Kahola
no flags Details | Splinter Review
Syslog for resume from sleep flickering (2.48 MB, text/plain)
2015-12-12 13:25 UTC, Tom Furniss
no flags Details
dmesg for resume from sleep flickering (249.44 KB, text/plain)
2015-12-12 13:26 UTC, Tom Furniss
no flags Details
dmesg with drm.debug=14 (170.43 KB, text/plain)
2015-12-12 14:54 UTC, Andrew Merzlyakov
no flags Details
Disable fast link training when resuming (1.49 KB, patch)
2015-12-14 11:39 UTC, Mika Kahola
no flags Details | Splinter Review
syslog for sleep/resume flickering issue (1.47 MB, text/plain)
2015-12-24 13:01 UTC, Tom Furniss
no flags Details
syslog after three patches and returned flicker (3.60 MB, text/plain)
2016-01-05 17:04 UTC, Tom Furniss
no flags Details
dmesg after three patches and returned flicker (251.72 KB, text/plain)
2016-01-05 17:08 UTC, Tom Furniss
no flags Details
DP debugging (2.09 KB, patch)
2016-01-08 11:53 UTC, Mika Kahola
no flags Details | Splinter Review
syslog for 3 patches with increased debug (3.63 MB, text/plain)
2016-01-09 11:58 UTC, Tom Furniss
no flags Details
dmesg for 3 patches with increased debug (254.26 KB, text/plain)
2016-01-09 12:00 UTC, Tom Furniss
no flags Details
In my case it crashes the PC. Got a kdump. (107 bytes, text/plain)
2016-01-20 03:46 UTC, yulian kalev
no flags Details
no-flicker-after-dpms-4.5.patch (1.09 KB, patch)
2016-03-16 09:49 UTC, Pavel Procopiuc
no flags Details | Splinter Review
dmesg-intel-nightly-patches (55.36 KB, text/plain)
2016-03-17 08:11 UTC, Pavel Procopiuc
no flags Details
dmesg-before-flicker (195.98 KB, text/plain)
2016-03-18 08:07 UTC, Pavel Procopiuc
no flags Details
dmesg-after-flicker (241.06 KB, text/plain)
2016-03-18 08:10 UTC, Pavel Procopiuc
no flags Details
Cache DP signal levels (3.10 KB, patch)
2016-03-23 13:56 UTC, Mika Kahola
no flags Details | Splinter Review
dmesg after 0004-drm-i915-Cache-DisplayPort-link-signal-levels.patch (615.02 KB, text/plain)
2016-03-24 08:37 UTC, Pavel Procopiuc
no flags Details
systemd logs with drm.debug=0x1e for stock 4.5.1 kernel (arch) with flicker after standby (3.20 MB, text/plain)
2016-04-26 03:41 UTC, alex
no flags Details
Revert Fast Link Training (3.43 KB, patch)
2016-05-18 11:29 UTC, Mika Kahola
no flags Details | Splinter Review
/sys/kernel/debug/dri/0/i915_vbt dump (6.00 KB, application/octet-stream)
2016-05-21 08:30 UTC, Elric
no flags Details
VBT dump of affected computer (6.00 KB, application/octet-stream)
2016-06-11 22:46 UTC, alex
no flags Details
vbt dump after flicker -> panel shutting down -> suspending -> resuming (6.00 KB, application/octet-stream)
2016-06-27 21:06 UTC, Elric
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Tom Furniss 2015-07-19 11:17:16 UTC
Created attachment 117243 [details]
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_multithread_makecurrent, GLX_MESA_query_renderer, 
    GLX_MESA_multithread_makecurrent, GLX_MESA_query_renderer, 
OpenGL renderer string: Mesa DRI Intel(R) HD Graphics 5500 (Broadwell GT2) 
    GL_ARB_conditional_render_inverted, GL_ARB_conservative_depth, 
    GL_MESA_texture_signed_rgba, GL_NV_conditional_render, GL_NV_depth_clamp, 
    GL_ARB_conditional_render_inverted, GL_ARB_conservative_depth, 
    GL_NV_conditional_render, GL_NV_depth_clamp, GL_NV_light_max_exponent, 
    GL_OES_element_index_uint, GL_OES_fbo_render_mipmap,
Comment 1 Tom Furniss 2015-07-19 11:18:11 UTC
Created attachment 117244 [details]
intel-reg-dumper
Comment 2 Tom Furniss 2015-07-19 11:18:44 UTC
Created attachment 117245 [details]
edid file
Comment 3 Tom Furniss 2015-07-19 11:19:26 UTC
Created attachment 117246 [details]
xrandr --verbose
Comment 4 Tom Furniss 2015-07-19 14:17:03 UTC
Created attachment 117247 [details]
xorg log
Comment 5 Jesse Barnes 2015-08-03 21:25:20 UTC
Does i915.enable_ips=0 help at all?
Comment 6 Tom Furniss 2015-08-04 14:27:49 UTC
(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
Comment 7 Rodrigo Vivi 2015-08-17 21:26:30 UTC
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.
Comment 8 Tom Furniss 2015-08-20 13:52:47 UTC
(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
Comment 9 Oscar Morante 2015-09-10 09:40:43 UTC
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?
Comment 10 Jani Nikula 2015-09-10 12:49:45 UTC
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.
Comment 11 Tom Furniss 2015-09-10 14:32:53 UTC
(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.
Comment 12 Oscar Morante 2015-09-11 11:01:42 UTC
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.
Comment 13 Michel Memeteau - Ekimia 2015-09-16 14:31:05 UTC
Same problem here on the Pentium brodwell GT1 model (TopStar U731).

Does it affect any kernel ?
Comment 14 Tom Furniss 2015-09-21 13:37:23 UTC
(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.
Comment 15 Tom Furniss 2015-09-21 13:38:29 UTC
Created attachment 118383 [details]
intel_reg dump with i915.modeset=0
Comment 16 Tom Furniss 2015-09-21 13:40:51 UTC
Created attachment 118384 [details]
intel_reg dump with i915.modeset=1
Comment 17 Oscar Morante 2015-09-30 13:34:32 UTC
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
Comment 18 Oscar Morante 2015-09-30 13:35:27 UTC
Created attachment 118538 [details]
intel_reg dump before the flicker happens
Comment 19 Oscar Morante 2015-09-30 13:36:12 UTC
Created attachment 118539 [details]
intel_reg dump while the flicker is happening
Comment 20 Jani Nikula 2015-10-01 09:14:03 UTC
(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.
Comment 21 Oscar Morante 2015-10-01 16:48:36 UTC
Created attachment 118563 [details]
dmesg with drm.debug=14 (boot -> gnome -> lock -> unlock -> flicker)

There you go.
Comment 22 Oscar Morante 2015-10-01 16:50:13 UTC
Created attachment 118564 [details]
dmesg with drm.debug=14 (boot -> gnome -> lock -> unlock -> flicker)

Oops! I mixed up the files.  This is the good one.
Comment 23 Oscar Morante 2015-10-08 10:05:14 UTC
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.
Comment 24 Oscar Morante 2015-10-11 08:08:44 UTC
Nevermind, I went to capture the logs and now I get the flicker every time... I guess it was just coincidence.
Comment 26 Michel Memeteau - Ekimia 2015-10-23 14:37:41 UTC
Great news Oscar Morante !
Comment 27 Oscar Morante 2015-10-25 06:51:17 UTC
Yes, I hope it help to find a proper fix :)
Comment 28 Jani Nikula 2015-10-26 13:52:30 UTC
(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 <mika.kahola@intel.com>
Date:   Wed Apr 29 09:17:39 2015 +0300

    drm/i915: eDP link training optimization

commit 5fa836a9d85975c5f0f1219669523c1f0ac64349
Author: Mika Kahola <mika.kahola@intel.com>
Date:   Wed Apr 29 09:17:40 2015 +0300

    drm/i915: DP link training optimization

Cc: Mika.
Comment 30 Pavel Procopiuc 2015-11-02 08:40:21 UTC
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
Comment 31 Mika Kahola 2015-11-20 13:14:13 UTC
Created attachment 119983 [details] [review]
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.
Comment 32 Lorenzo Bettini 2015-11-24 13:45:37 UTC
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!
Comment 33 Tom Furniss 2015-11-24 14:22:10 UTC
I applied the patch and it resolved my flickering problem.
Comment 34 Kimmo Nikkanen 2015-11-25 07:39:33 UTC
Assigning to our QA for verification
Comment 35 Mika Kahola 2015-11-25 10:14:09 UTC
(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.
Comment 36 Mika Kahola 2015-11-25 10:23:40 UTC
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.
Comment 37 Kimmo Nikkanen 2015-12-01 12:09:31 UTC
Lowering the priority. 
This is not blocking our work and we haven't been able to reproduce the problem on our side.
Comment 38 Lorenzo Bettini 2015-12-01 17:32:35 UTC
(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?
Comment 39 Mika Kahola 2015-12-02 06:47:14 UTC
(In reply to Lorenzo Bettini from comment #38)
> (In reply to Mika Kahola from comment #36)
> > Created attachment 120109 [details] [review] [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/
Comment 40 Luke Hutchison 2015-12-04 04:10:15 UTC
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.
Comment 41 Mika Kahola 2015-12-04 07:34:15 UTC
That is a bit strange. Could you provide a dmesg log with the option drm.debug=0xe?
Comment 42 Tom Furniss 2015-12-04 16:29:28 UTC
(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.

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.
Comment 43 flux242 2015-12-05 11:00:17 UTC
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
Comment 44 flux242 2015-12-05 14:19:32 UTC
(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
Comment 45 Tom Furniss 2015-12-06 10:03:02 UTC
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.
Comment 46 Oscar Morante 2015-12-06 16:26:36 UTC
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!
Comment 47 Mika Kahola 2015-12-07 14:15:25 UTC
(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!
Comment 48 Mika Kahola 2015-12-07 15:00:12 UTC
Created attachment 120389 [details] [review]
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
Comment 49 Tom Furniss 2015-12-12 13:25:38 UTC
Created attachment 120480 [details]
Syslog for resume from sleep flickering

Sleep initiated at 13:03.
Comment 50 Tom Furniss 2015-12-12 13:26:58 UTC
Created attachment 120481 [details]
dmesg for resume from sleep flickering
Comment 51 Tom Furniss 2015-12-12 13:27:28 UTC
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.
Comment 52 Andrew Merzlyakov 2015-12-12 14:54:10 UTC
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?
Comment 53 Andrew Merzlyakov 2015-12-12 14:54:53 UTC
Created attachment 120485 [details]
dmesg with drm.debug=14
Comment 54 Mika Kahola 2015-12-14 11:05:12 UTC
(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.
Comment 55 Mika Kahola 2015-12-14 11:39:10 UTC
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.
Comment 56 flux242 2015-12-15 10:03:25 UTC
(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?
Comment 57 Andrew Merzlyakov 2015-12-15 10:31:10 UTC
> 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.
Comment 58 Tom Furniss 2015-12-15 10:45:47 UTC
(In reply to Mika Kahola from comment #55)
> Created attachment 120493 [details] [review] [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.
Comment 59 flux242 2015-12-24 11:00:31 UTC
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
Comment 60 Tom Furniss 2015-12-24 13:01:24 UTC
Created attachment 120678 [details]
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.
Comment 61 Mika Kahola 2016-01-04 11:48:48 UTC
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.
Comment 62 Tom Furniss 2016-01-05 17:04:15 UTC
Created attachment 120818 [details]
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.
Comment 63 Tom Furniss 2016-01-05 17:08:23 UTC
Created attachment 120819 [details]
dmesg after three patches and returned flicker
Comment 64 flux242 2016-01-06 09:58:59 UTC
> 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
Comment 65 Rodrigo Vivi 2016-01-07 23:28:35 UTC
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?
Comment 66 Tom Furniss 2016-01-08 09:57:39 UTC
(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.
Comment 67 flux242 2016-01-08 10:15:47 UTC
> 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.
Comment 68 Mika Kahola 2016-01-08 11:53:39 UTC
Created attachment 120893 [details] [review]
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.
Comment 69 Tom Furniss 2016-01-09 11:58:35 UTC
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

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?
Comment 70 Tom Furniss 2016-01-09 12:00:38 UTC
Created attachment 120920 [details]
dmesg for 3 patches with increased debug
Comment 71 Mika Kahola 2016-01-11 11:05:26 UTC
(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.
Comment 72 Tom Furniss 2016-01-16 20:46:54 UTC
Hi Mika

Yes, applying patch 66697 against the latest intel-drm-nightly does still resolve the issue.
Comment 73 Alberto Salvia Novella 2016-01-18 08:21:57 UTC
Also reported in (https://bugs.launchpad.net/ubuntu/+source/libdrm/+bug/1522922).
Comment 74 Tom Furniss 2016-01-18 10:10:03 UTC
(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.
Comment 75 Mika Kahola 2016-01-18 11:24:43 UTC
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?
Comment 76 yulian kalev 2016-01-20 03:46:30 UTC
Created attachment 121148 [details]
In my case it crashes the PC. Got a kdump.

see also https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1535048
Comment 77 jlrivitti 2016-01-26 23:47:48 UTC
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.
Comment 78 jlrivitti 2016-02-04 22:46:20 UTC
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
Comment 79 Lorenzo Bettini 2016-02-08 07:58:15 UTC
(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
Comment 80 Lorenzo Bettini 2016-03-07 10:35:28 UTC
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.
Comment 81 Andreas Reis 2016-03-12 00:41:46 UTC
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.
Comment 82 Pavel Procopiuc 2016-03-16 09:49:49 UTC
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.
Comment 83 Mika Kahola 2016-03-16 11:37:49 UTC
(In reply to Pavel Procopiuc from comment #82)
> Created attachment 122338 [details] [review] [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.
Comment 84 Pavel Procopiuc 2016-03-16 12:05:17 UTC
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?
Comment 85 Mika Kahola 2016-03-16 13:18:26 UTC
(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.
Comment 86 Pavel Procopiuc 2016-03-17 08:11:04 UTC
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?
Comment 87 Mika Kahola 2016-03-17 08:33:14 UTC
(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
Comment 88 Pavel Procopiuc 2016-03-18 08:07:42 UTC
Created attachment 122405 [details]
dmesg-before-flicker
Comment 89 Pavel Procopiuc 2016-03-18 08:10:55 UTC
Created attachment 122406 [details]
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.
Comment 90 Mika Kahola 2016-03-23 13:56:22 UTC
Created attachment 122497 [details] [review]
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 ;)
Comment 91 Pavel Procopiuc 2016-03-24 08:37:16 UTC
Created attachment 122517 [details]
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.
Comment 92 Pavel Procopiuc 2016-03-24 08:45:13 UTC
I was applying patches against 6f78897 of drm-intel. All 4 patches also apply against vanilla 4.5.0 also fixing the issue.
Comment 93 Mika Kahola 2016-03-24 13:13:33 UTC
Great that the patches worked out for you. I guess its time to upstream these patches.
Comment 94 Lorenzo Bettini 2016-03-28 07:27:00 UTC
(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.
Comment 95 thoehlig 2016-03-29 13:58:30 UTC
Are these patches in latest-drm-nightly already?
Comment 96 Mika Kahola 2016-03-30 07:09:56 UTC
(In reply to thoehlig from comment #95)
> Are these patches in latest-drm-nightly already?

Not yet. These patches needs to be reviewed first.
Comment 97 Andreas Reis 2016-04-01 12:44:50 UTC
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.
Comment 98 alex 2016-04-07 19:00:40 UTC
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.
Comment 99 Timo Aaltonen 2016-04-18 08:37:58 UTC
Has the latest patch even been sent to the list? At least I can't find it.
Comment 100 Mika Kahola 2016-04-20 11:10:18 UTC
(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.
Comment 101 Nico Hwege 2016-04-21 00:43:24 UTC
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
Comment 102 Pavel Procopiuc 2016-04-21 07:05:53 UTC
(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/
Comment 103 Nico Hwege 2016-04-21 07:14:34 UTC
(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!
Comment 104 Mika Kahola 2016-04-21 07:17:14 UTC
(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.
Comment 105 Pavel Procopiuc 2016-04-21 07:19:00 UTC
(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.
Comment 106 thoehlig 2016-04-21 07:21:43 UTC
(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
Comment 107 Nico Hwege 2016-04-21 09:35:29 UTC
(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.
Comment 108 Rodrigo Vivi 2016-04-21 13:22:04 UTC
*** Bug 94593 has been marked as a duplicate of this bug. ***
Comment 109 alex 2016-04-25 00:52:41 UTC
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?????
Comment 110 Mika Kahola 2016-04-25 09:54:58 UTC
(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.
Comment 111 alex 2016-04-26 03:41:16 UTC
Created attachment 123264 [details]
systemd logs with drm.debug=0x1e for stock 4.5.1 kernel (arch) with flicker after standby
Comment 112 alex 2016-04-26 03:50:19 UTC
(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.
Comment 113 Mika Kahola 2016-04-27 13:52:31 UTC
(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/
Comment 114 Jani Nikula 2016-04-27 14:52:01 UTC
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.
Comment 116 Lorenzo Bettini 2016-04-29 06:07:08 UTC
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?
Comment 117 Mika Kahola 2016-05-18 11:29:05 UTC
Created attachment 123877 [details] [review]
Revert Fast Link Training

This patch reverts the fast link training feature. However, I have seen that some of the flickering issues are not caused by this feature. Please, give this a go and report back if this patch fixes the screen flickering.
Comment 118 Elric 2016-05-21 08:27:42 UTC
I'm also having the same issue on my XPS 9350 (FHD version)

Attaching /sys/kernel/debug/dri/0/i915_vbt dump as requested.

My machine was running linux 4.6.0-trunk-amd64 from Debian unstable at the moment of the dump and I got flickering after waking up.

It was way worse with older versions of the kernel. So I'm not sure if it's the same bug.
Comment 119 Elric 2016-05-21 08:30:08 UTC
Created attachment 123955 [details]
/sys/kernel/debug/dri/0/i915_vbt dump
Comment 120 Evandro Myller 2016-05-22 08:34:18 UTC
(In reply to Mika Kahola from comment #117)
> Created attachment 123877 [details] [review] [review]
> Revert Fast Link Training
> 
> This patch reverts the fast link training feature. However, I have seen that
> some of the flickering issues are not caused by this feature. Please, give
> this a go and report back if this patch fixes the screen flickering.

Mika, I've been following this thread for a while now.

Since kernel 4.3, I always tried and compiled it with a patch that disabled the fast link training feature and it worked. Now, for kernel 4.6, I tried your latest patch and once again my screen is working like a charm. Earlier today, I also tried the latest original kernel, but the flickering was even worse than in previous versions - one can't even pass the gdm login screen!

Please let me know if I can provide and logs or dumps, and their specific files.

Thank you.
Comment 121 Mika Kahola 2016-06-07 07:07:37 UTC
(In reply to Evandro Myller from comment #120)
> (In reply to Mika Kahola from comment #117)
> > Created attachment 123877 [details] [review] [review] [review]
> > Revert Fast Link Training
> > 
> > This patch reverts the fast link training feature. However, I have seen that
> > some of the flickering issues are not caused by this feature. Please, give
> > this a go and report back if this patch fixes the screen flickering.
> 
> Mika, I've been following this thread for a while now.
> 
> Since kernel 4.3, I always tried and compiled it with a patch that disabled
> the fast link training feature and it worked. Now, for kernel 4.6, I tried
> your latest patch and once again my screen is working like a charm. Earlier
> today, I also tried the latest original kernel, but the flickering was even
> worse than in previous versions - one can't even pass the gdm login screen!
> 
> Please let me know if I can provide and logs or dumps, and their specific
> files.
> 
> Thank you.

Are you using DP or eDP? Does your panel support PSR? For eDP the fast link training should be ok as you could assume that the cable length and connections are not changing. Anyway, logs and dumps are always welcomed as there are quite a variety of different HW combinations out there.
Comment 122 alex 2016-06-11 22:46:18 UTC
Created attachment 124480 [details]
VBT dump of affected computer
Comment 123 alex 2016-06-11 22:47:47 UTC
Regression still present in 4.6.2.  Attached VBT dump as requested.  

When are you guys going to either commit a proper fix or revert the regression on the main line?
Comment 124 Joshua Pratt 2016-06-17 04:57:15 UTC
Seconding this request for a real fix. This is causing nausea while using my laptop and it would be lovely to have a screen that is reliable (I'm having flickers every minute or so).
Comment 125 Jani Nikula 2016-06-17 16:36:30 UTC
http://patchwork.freedesktop.org/patch/msgid/1466162081-12042-1-git-send-email-mika.kahola@intel.com reverting the fast link training will be merged and backported to stable. We'll stop banging our heads against this. Tested-by's welcome. If flickering remains with that, it's something else.
Comment 126 Matthias Hille 2016-06-20 07:58:53 UTC
I had the same problem with my machine (Thinkpad X250, Intel(R) Core(TM) i7-5600U). I'm using the Thinkpad Ultradock and the second screen which is connected via DP flickered occasionally.
This is gone since I'm using the nightly build of last week's Tuesday (kernel 4.7.0-rc2, Commit bb3592f8f98bf02f85da4636f186773f43bc3a65).
Comment 127 Jani Nikula 2016-06-20 09:48:48 UTC
commit 91df09d92ad82c8778ca218097bf827f154292ca
Author: Mika Kahola <mika.kahola@intel.com>
Date:   Mon Jun 20 11:10:26 2016 +0300

    drm/i915: Revert DisplayPort fast link training feature
Comment 128 Lorenzo Bettini 2016-06-20 13:18:35 UTC
(In reply to Jani Nikula from comment #127)
> commit 91df09d92ad82c8778ca218097bf827f154292ca
> Author: Mika Kahola <mika.kahola@intel.com>
> Date:   Mon Jun 20 11:10:26 2016 +0300
> 
>     drm/i915: Revert DisplayPort fast link training feature

where do we find this fixed kernel in binary form?
Comment 129 Jani Nikula 2016-06-21 15:45:32 UTC
(In reply to Lorenzo Bettini from comment #128)
> (In reply to Jani Nikula from comment #127)
> > commit 91df09d92ad82c8778ca218097bf827f154292ca
> > Author: Mika Kahola <mika.kahola@intel.com>
> > Date:   Mon Jun 20 11:10:26 2016 +0300
> > 
> >     drm/i915: Revert DisplayPort fast link training feature
> 
> where do we find this fixed kernel in binary form?

Wait for that to find its way in Linus' upstream, then get backported to stable kernels, then to be picked up by distros, then be rolled out to users...
Comment 130 Elric 2016-06-27 21:04:47 UTC
I built RC5 from git and sadly sadly it doesn't fix the flickering for me. I'm also still getting randomly getting my display shutting down and not recovering until y suspend and wake up the laptop (XPS 13 9350 with FHD panel).
I'll attack another dump of the vbt in case it makes any difference across kernel versions.
Comment 131 Elric 2016-06-27 21:06:19 UTC
Created attachment 124745 [details]
vbt dump after flicker -> panel shutting down -> suspending -> resuming
Comment 132 Lorenzo Bettini 2016-06-29 07:59:37 UTC
(In reply to Jani Nikula from comment #129)
> (In reply to Lorenzo Bettini from comment #128)
> > (In reply to Jani Nikula from comment #127)
> > > commit 91df09d92ad82c8778ca218097bf827f154292ca
> > > Author: Mika Kahola <mika.kahola@intel.com>
> > > Date:   Mon Jun 20 11:10:26 2016 +0300
> > > 
> > >     drm/i915: Revert DisplayPort fast link training feature
> > 
> > where do we find this fixed kernel in binary form?
> 
> Wait for that to find its way in Linus' upstream, then get backported to
> stable kernels, then to be picked up by distros, then be rolled out to
> users...

I've tried the ubuntu kernel ppa mainline, and by using this one

http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-nightly/2016-06-21-yakkety/

which I guess it's based on the commit you were mentioning, flickering is gone: I can change the screen resolution and even after screensaver resume there's no flickering.

However, when using desktop effects like "show all windows/expose" (both in unity with compiz and with KDE) there's some flickering...

By the way, while using kernel 4.2 I used to fix the flickering by reverting the commits mentioned in https://bugs.freedesktop.org/show_bug.cgi?id=91393#c25 and recompiling the kernel.

This reverting cannot be done on kernel 4.4 though.  Thus, the reverted commits you're mentioning are not the ones mentioned in https://bugs.freedesktop.org/show_bug.cgi?id=91393#c25 ?
Comment 133 Jani Nikula 2016-06-29 09:46:29 UTC
(In reply to Elric from comment #130)
> I built RC5 from git and sadly sadly it doesn't fix the flickering for me.

Then you have a different bug. Please file a new bug.


bug/show.html.tmpl processed on Mar 27, 2017 at 04:40:35.
(provided by the Example extension).