i915 flickering in new XPS13 9380 (2019)

Submitted by Paulo J. Matos

Assigned to Ville Syrjälä @vsyrjala

Link to original bug (#110511)

Description

Created attachment 144092
dmesg from boot

This was previously reported here: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1826125

Brand new XPS 13 9380 arrived a couple of days ago from Dell with Ubuntu 18.04 preinstalled.

Flickering started immediatelly post boot and it was constant.
I updated BIOS from 1.1.1 to 1.2.1, tried i915.fastboot and i915.enable_rc6 combinations to no avail.

Updated to Ubuntu 19.04 and kernel-5 to no avail. However flickering changed from constant to only if there's a screen refresh.

Videos pre kernel 5:
https://photos.app.goo.gl/1PkL2HrjMBP41aML9
https://photos.app.goo.gl/CMzmMwrCPH5wh8aw6

Videos post kernel 5:
https://photos.app.goo.gl/tpmTGWVJXpChoERz6

I attach dmesg from boot.

Attachment 144092, "dmesg from boot":
out.dmesg

added Community feature: display/Other platform: CFL priority::high severity::critical + 1 deleted label

Timo Aaltonen said:

and happens with current nightly too

LAKSHMINARAYANA VUDUM @l4kshmi said:

Stan, any help here? I see hotplug events in dmesg.

Timo Aaltonen said:

Ping? With 5.0 and up PSR seems to be messing with the results, but disabling it doesn't fix the original issue.

Paulo J. Matos said:

If I can help at all sorting this one out let me know. logs, ssh access to the machine, you name it.

Ville Syrjälä @vsyrjala submitted a patch:

This patch might help us figure out what the sink is trying to tell us.

Patch 144287, "[PATCH] drm/i915: Dump the full ESI register block on short pulse":
0001-drm-i915-Dump-the-full-ESI-register-block-on-short-p.patch

Timo Aaltonen said:

thanks Ville, here's a kernel deb based on drm-intel-next-fixes-2019-05-15 plus this patch

http://aaltoset.kapsi.fi/xps13-flicker/

Paulo, please install, boot with drm.debug=14 and attach dmesg

Paulo J. Matos uploaded an attachment:

Attachment 144318, "Timo rc5+ kernel dmesg":
dmesg.log

Paulo J. Matos said:

Timo, I have attached the dmesg with rc5+ kernel you asked me to test.

Ville Syrjälä @vsyrjala said:

[ 4.550517] [drm:intel_dp_hpd_pulse [i915]] ESI: 41 00 00 00 00 00 00 00 00 00 00 00 81 01

According to that the sink thinks everything is fine, so no idea why generates short hpds.

Could be some kind of PSR fail. Please try passing i915.enable_psr=0 to the kernel cmdline.

Paulo J. Matos said:

(In reply to Ville Syrjala from comment 9)

[ 4.550517] [drm:intel_dp_hpd_pulse [i915]] ESI: 41 00 00 00 00 00 00 00
00 00 00 00 81 01

According to that the sink thinks everything is fine, so no idea why
generates short hpds.

Could be some kind of PSR fail. Please try passing i915.enable_psr=0 to the
kernel cmdline.

enable_psr=0 does not help. Posting dmesg with enable_psr=0.

Paulo J. Matos uploaded an attachment:

Attachment 144319, "rc5+ kernel with enable_psr=0":
dmesg.log

Paulo J. Matos said:

In https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1826125/comments/53 it is mentioned that the same laptop with PCLinuxOS with 5.0.2 doesn't flicker. Is it worth it getting some data from there perhaps?

Ville Syrjälä @vsyrjala said:

(In reply to Paulo J. Matos from comment 11)

Created attachment 144319 [details]
rc5+ kernel with enable_psr=0

The log was cut off so couldn't see that PSR was in fact disabled. You can fix that by passing eg. log_buf_len=2M to the kernel cmdline.

Anyways, after a second glance at the logs I see the sink does sometimes indicate that the receiver port was not synchronized. Not sure why the failure manifests at that level with the link otherwise being reported as stable. Looks like we could try to reduce the link rate a bit and still have enough bandwidth for the 4k@60 mode. I'll attach something to that effect.

Ville Syrjälä @vsyrjala submitted a patch:

This should drop the link rate to 4.32ghz, which is the lowest we can go with this panel. Please test.

Patch 144325, "[PATCH] hack: Disable 5.4ghz link rate for skl":
0001-hack-Disable-5.4ghz-link-rate-for-skl.patch

Ville Syrjälä @vsyrjala said:

Hmm, yes 4.32 is what the BIOS uses, so this might even help:
[ 1.391106] [drm:intel_dump_pipe_config [i915]] port clock: 432000, pipe src size: 3840x2160, pixel rate 533299

Hmm. That probably means this is a victim of commit f11cb1c19ad0 ("drm/i915/dp: revert back to max link rate and lane count on eDP"), which I think would have picked the lower link rate for us.

Yes, eDP revision seems to be 1.4a:
[ 1.385017] [drm:intel_dp_init_connector [i915]] eDP DPCD: 04 92 a5
so I believe that is indeed what would have happened.

Timo Aaltonen said:

new kernel build with the hack in

http://aaltoset.kapsi.fi/xps13-flicker/

Paulo J. Matos said:

I can confirm that with Timo's kernel, with Ville's patch it all works smoothly.
Great job guys! Thanks so much for the support. I will keep using this kernel until upstream is fixed. Can you please update this bug once a proper fix hits upstream?

Ville Syrjälä @vsyrjala said:

Can we get a test with just 'git revert f11cb1c19ad0' ?

Timo Aaltonen said:

kernel -10 with the revert availabe behind the same url

but reverting it would reopen 109959

Timo Aaltonen said:

Paulo, please test kernel build -10

Paulo J. Matos said:

Apologies, I dropped the ball on this one. I will do that today.

Paulo J. Matos said:

I can confirm that the kernel with the reverted commit works. Apologies for the delay.

josh@miltz.co.za said:

Hi all,

I have been following this bug report for a while - I just wanted to check in on status. Will the fix be rolled out now that Paulo has confirmed the working kernel version?

Ville Syrjälä @vsyrjala submitted a patch:

Here's an attempt at fixing this without horribly breaking a bunch of other eDP panels. Would appreciate if people can test this.

Also available here in git form:
git://github.com/vsyrjala/linux.git dp_retry_max_vs_optim

Patch 144765, "[PATCH] drm/i915: Try to use fast+narrow link on eDP again and fall back to the old max strategy on failure":
0001-drm-i915-Try-to-use-fast-narrow-link-on-eDP-again-an.patch

I'm using Dell XPS 13 7390 (Developer Edition 2019). The display flickering with vanilla kernel is terrible and renders the internal display totally useless. A patched 5.4.8 kernel with a version of your "Try to use fast+narrow link on eDP again and fall back to the old max strategy on failure" that was adapted to recent i915 refactorings (0001-drm-i915-Try-to-use-fast-narrow-link-on-eDP-again-an_5.4.x.patch) reduces flickering to a reasonable level. I don't know if the patch fixes the issue for original reporter's XPS 13 9380, though. I'd be willing to test kernel patches on XPS 13 7390, if that helps resolve the issue.

@jalberto @bradenbrodersen @janario.oliveira You might give the "fast+narrow" patch a try.

I have the 9380 and I'm using Manjaro if you can get me the latest manjaro lts kernel patched I'd be willing to test it asap. I would love to learn to patch my own kernel but right now I don't have the knowledge to do it. If you are not wiling to or yo cant is okay, just point me to a good tutorial. Thanks.

Kai-Heng Feng said:

Timo isn't around, please test this kernel:
https://people.canonical.com/~khfeng/bfo110511/

Paulo J. Matos said:

I will take a look a this later. Apologies but I am on and off summer holidays these days.

Kai-Heng Feng said:

According to
https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/1827790/comments/19

This issue is fixed by "dp_retry_max_vs_optim" branch.

LAKSHMINARAYANA VUDUM @l4kshmi said:

(In reply to Paulo J. Matos from comment 26)

I will take a look a this later. Apologies but I am on and off summer
holidays these days.

Paulo, is this issue still reproducible? any updates here?

Paulo J. Matos said:

(In reply to Kai-Heng Feng from comment 25)

Timo isn't around, please test this kernel:
https://people.canonical.com/~khfeng/bfo110511/

This kernel works.

LAKSHMINARAYANA VUDUM @l4kshmi said:

(In reply to Paulo J. Matos from comment 29)

(In reply to Kai-Heng Feng from comment 25)

Timo isn't around, please test this kernel:
https://people.canonical.com/~khfeng/bfo110511/

This kernel works.

Can we close this bug?

Paulo J. Matos uploaded an attachment:

It depends if the fix in the kernel I tested is upstream, I guess. Kai?

On 5 September 2019 19:58:19 CEST, bugzilla-daemon@freedesktop.org wrote:

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

--- Comment 30 from Lakshmi lakshminarayana.vudum@intel.com ---
(In reply to Paulo J. Matos from comment 29)

(In reply to Kai-Heng Feng from comment 25)

Timo isn't around, please test this kernel:
https://people.canonical.com/~khfeng/bfo110511/

This kernel works.

Can we close this bug?

--
You are receiving this mail because:
You reported the bug.

Attachment 145270, "attachment-3420-0.html":
attachment-3420-0.html

Ville Syrjälä @vsyrjala said:

The fix is nowhere yet. And judging from the ubuntu bug it may not even work :(

Timo Aaltonen said:

I've built a kernel here based on 5.3 plus the patch:

https://aaltoset.kapsi.fi/lp1826125

and it was tested on the LP bug and found to be working

assigned to @vsyrjala

Hi, I am experiencing the same issue on XPS 7590 Do you know on which kernel version the bug will be fixed ? Thanks

Similar problems here. The screen on my Dell XPS 13 9360 started flickering badly and intermittently several months ago. It has a 4k touch display and is running Ubuntu (19.10).

The flicker always occurs in these two regions. Video is at https://photos.app.goo.gl/vq3KhBemWE1ZYjVN8.

The built-in display diagnostics complete without error. I have not observed screen flicker on BIOS screens, so I have no reason to believe a pure hardware issue (e.g., cable or memory). I don't have windows, so can't speak to whether the issue occurs there. (However, plenty of users are complaining about screen flicker in windows in other threads.)

The problem is intermittent. It seems to happen most frequently after booting and after resuming. The problem goes away after a while (10-30 minutes, I guess).

I've had the laptop for 3 years and have always run linux on it. The issue showed up shortly have a firmware upgrade, but that might be just correlation. I upgraded to Ubuntu 19.10 was around the same time, I think.

Happy to try patched kernels if that's still useful.

similar issues in 7390 (2019 dev edition) on fedora

I have this same issue. Brand new dell xps 7390 and it screen flickers to the point of it just stopping and not rendering any graphical changes anymore. Thanks for looking into this and helping us out. :)

I have the same issue with ubuntu 19.10 and dell xps 13 7390

Tried with kernel 5.4.6 and latest video drivers from oibaf ppa, but still the same problem

Is there a workaround? or can I do some test that can help on the fix?

Hi! As sown in this post on the manjaro forums, I am having the same issues on my 9380, before it was fine but now in manjaro i have to stay in 4.19 because kernels newer than 5.2 have this problems.

Using a Dell XPS 15 9570 (2019) that exhibits similar i915 flickering with anything above kernel 5.x with a few distros, the Ubuntu mainline or Manjaro AUR kernels with newer drm-tip resolves for me. Any anticipation that the upstream Ubuntu or Arch/Manjaro kernels will get this built-in or resolved - be nice to have this working again properly for the upcoming Ububu 20.04 and Manjaro 19 cycles. Most users are either staying on 4.x kernels or using custom compiles to workaround.

Mainline Ubuntu kernel PPA: https://kernel.ubuntu.com/~kernel-ppa/mainline/drm-tip/current/

Manjaro AUR: https://aur.archlinux.org/packages/linux-drm-tip-git/

added UX label

Is there a workaround? or can I do some test that can help on the fix?

@janario.oliveira I also have a 7390. For me, the screen issues were fixed by this patch found in this issue discussion (which eventually links to the same issue linked to here).

Thanks! I have read both links but the implementation is going over my head, I'm tech-savvy but not that much. I would appreciate some help!

Hmm. Which part is confusing? What causes the bug, how you can fix the issue on your laptop, how the fix works, or something else?

How to implement it. Its not something that I am not used to.

What do you mean by "implement it"? How to apply the patch? If so, which distro do you use?

There were dbuf changes merged recently. At this time, good to reproduce this issue with drm-tip (https://cgit.freedesktop.org/drm-tip).

On Manjaro I've experienced no issues using distro provided 5.6rc kernels, on Ubuntu I will test with the drm-tip mainline kernel that gets built later today or tomorrow.

No issues experienced on newer builds of Ubuntu mainline drm-tip. Manjaro has been fine with its 5.6-rc kernels.

System:    Host: vLap Kernel: 5.6.0-994-generic x86_64 bits: 64 compiler: gcc v: 9.2.1  
           base: Ubuntu 18.04 bionic 
Machine:   Type: Laptop System: Dell product: XPS 15 9570
Graphics:  Device-1: Intel vendor: Dell driver: i915 v: kernel bus ID: 00:02.0 chip ID: 8086:3e9b 
           Display: x11 server: X.Org 1.20.5 driver: modesetting unloaded: fbdev,vesa 
           resolution: 1920x1080~60Hz 
           OpenGL: renderer: Mesa DRI Intel UHD Graphics 630 (Coffeelake 3x8 GT2) 

I have observed this artifact for the first time in BIOS setup as shown here.

This is the same machine (XPS 13 9360) as described three months ago in this thread.

Observing this display glitch in BIOS setup makes me question whether this is an OS issue at all.

Although this issue occurs at least daily for a year or so, I've been unable to infer factors that trigger it. It does seem to go away after several minutes. Also, it occurs only on the built-in display, so I focus my work on an external monitor.

Would someone please summarize why we think the issue is with Linux video drivers and not underlying hardware or firmware defects?

Can only express my experiences with it:

• No issues is BIOS (same hardware).

• No issues on Windows installation (same hardware).

• No issues kernel versions 5.0.x and 4.x, multiple distros.

• Issue is reproducible on multiple distros on kernel versions 5.3.x -> 5.5.x

• Issue began with edp_vswing and RC6 changes introduced in kernels above 5.0.x.

@genbushi: Is the flicker you see constant or intermittent? Is the banding similar to that shown in the video and images I posted?

The flicker I see is infrequent. I have tried several kernel flags over the past few months, sometimes thinking that they worked, only to find that I just didn't wait long enough.

The banding area is always the same. It always goes away after ~1-5 minutes. I have not associated with battery level, power supply, activity (e.g., music playing), or uptime.

Because it's infrequent and apparently random, and because I reboot relatively rarely, it was fortunate that I caught it during a BIOS setup. That strongly indicates, I think, that the OS (of any flavor) is not implicated. I don't have or run Windows, so I have no data on that.

If your flicker is qualitatively different, the underlying causes are likely different.