|Summary:||i915 flickering in new XPS13 9380 (2019)|
|Product:||DRI||Reporter:||Paulo J. Matos <paulo>|
|Component:||DRM/Intel||Assignee:||Ville Syrjala <ville.syrjala>|
|Status:||RESOLVED MOVED||QA Contact:||Intel GFX Bugs mailing list <intel-gfx-bugs>|
|Priority:||high||CC:||intel-gfx-bugs, kai.heng.feng, stanislav.lisovskiy, tjaalton|
|i915 platform:||CFL||i915 features:||display/Other|
Description Paulo J. Matos 2019-04-25 10:24:02 UTC
Created attachment 144092 [details] 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.
Comment 1 Timo Aaltonen 2019-04-25 15:14:17 UTC
and happens with current nightly too
Comment 2 Lakshmi 2019-04-29 05:47:06 UTC
Stan, any help here? I see hotplug events in dmesg.
Comment 3 Timo Aaltonen 2019-05-16 06:09:13 UTC
Ping? With 5.0 and up PSR seems to be messing with the results, but disabling it doesn't fix the original issue.
Comment 4 Paulo J. Matos 2019-05-16 06:12:33 UTC
If I can help at all sorting this one out let me know. logs, ssh access to the machine, you name it.
Comment 5 Ville Syrjala 2019-05-17 15:10:20 UTC
Created attachment 144287 [details] [review] [PATCH] drm/i915: Dump the full ESI register block on short pulse This patch might help us figure out what the sink is trying to tell us.
Comment 6 Timo Aaltonen 2019-05-17 18:13:29 UTC
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
Comment 7 Paulo J. Matos 2019-05-22 13:02:05 UTC
Created attachment 144318 [details] Timo rc5+ kernel dmesg
Comment 8 Paulo J. Matos 2019-05-22 13:03:03 UTC
Timo, I have attached the dmesg with rc5+ kernel you asked me to test.
Comment 9 Ville Syrjala 2019-05-22 15:51:07 UTC
[ 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.
Comment 10 Paulo J. Matos 2019-05-22 16:18:47 UTC
(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.
Comment 11 Paulo J. Matos 2019-05-22 16:19:30 UTC
Created attachment 144319 [details] rc5+ kernel with enable_psr=0
Comment 12 Paulo J. Matos 2019-05-22 16:23:01 UTC
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?
Comment 13 Ville Syrjala 2019-05-22 18:10:15 UTC
(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.
Comment 14 Ville Syrjala 2019-05-22 18:11:53 UTC
Created attachment 144325 [details] [review] [PATCH] hack: Disable 5.4ghz link rate for skl This should drop the link rate to 4.32ghz, which is the lowest we can go with this panel. Please test.
Comment 15 Ville Syrjala 2019-05-22 18:18:22 UTC
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.
Comment 16 Timo Aaltonen 2019-05-23 19:53:51 UTC
new kernel build with the hack in http://aaltoset.kapsi.fi/xps13-flicker/
Comment 17 Paulo J. Matos 2019-05-25 16:40:26 UTC
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?
Comment 18 Ville Syrjala 2019-05-27 12:01:22 UTC
Can we get a test with just 'git revert f11cb1c19ad0' ?
Comment 19 Timo Aaltonen 2019-05-28 06:11:01 UTC
kernel -10 with the revert availabe behind the same url but reverting it would reopen 109959
Comment 20 Timo Aaltonen 2019-06-06 21:15:05 UTC
Paulo, please test kernel build -10
Comment 21 Paulo J. Matos 2019-06-07 06:59:58 UTC
Apologies, I dropped the ball on this one. I will do that today.
Comment 22 Paulo J. Matos 2019-06-08 21:25:09 UTC
I can confirm that the kernel with the reverted commit works. Apologies for the delay.
Comment 23 josh 2019-06-25 07:25:07 UTC
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?
Comment 24 Ville Syrjala 2019-07-11 16:15:41 UTC
Created attachment 144765 [details] [review] [PATCH] drm/i915: Try to use fast+narrow link on eDP again and fall back to the old max strategy on failure 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
Comment 25 Kai-Heng Feng 2019-07-17 05:35:21 UTC
Timo isn't around, please test this kernel: https://people.canonical.com/~khfeng/bfo110511/
Comment 26 Paulo J. Matos 2019-07-17 09:00:23 UTC
I will take a look a this later. Apologies but I am on and off summer holidays these days.
Comment 27 Kai-Heng Feng 2019-08-13 07:31:21 UTC
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.
Comment 28 Lakshmi 2019-08-27 10:28:11 UTC
(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?
Comment 29 Paulo J. Matos 2019-09-03 07:25:54 UTC
(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.
Comment 30 Lakshmi 2019-09-05 17:58:19 UTC
(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?
Comment 31 Paulo J. Matos 2019-09-05 19:00:18 UTC
Created attachment 145270 [details] attachment-3420-0.html It depends if the fix in the kernel I tested is upstream, I guess. Kai? On 5 September 2019 19:58:19 CEST, email@example.com wrote: >https://bugs.freedesktop.org/show_bug.cgi?id=110511 > >--- Comment #30 from Lakshmi <firstname.lastname@example.org> --- >(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.
Comment 32 Ville Syrjala 2019-09-06 11:30:40 UTC
The fix is nowhere yet. And judging from the ubuntu bug it may not even work :(
Comment 33 Timo Aaltonen 2019-11-01 22:15:00 UTC
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
Comment 34 Martin Peres 2019-11-29 19:04:58 UTC
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/intel/issues/272.