PSR2 Selective Fetch causes underruns on Tigerlake

Hi Lyude

Thanks for the bug, logs and video.

It only happens when cursor goes to x=0? Odd as HW only sends full lines but could be something not being properly programmed with cursor...

Does it happens out of lock screen? What happens if you leave a browser window playing video close or at x=0? Just to run out the possibility that this is a cursor only issue.

Other odd thing is the stepping, looks a production stepping.

[ 4.138674] kernel: i915 device info: pciid=0x9a49 rev=0x01 platform=TIGERLAKE (subplatform=0x1) gen=12

static const struct intel_step_info tgl_uy_revids[] = {
...
	[1] = { COMMON_GT_MEDIA_STEP(B0), .display_step = STEP_C0 },

Is this expected?

Cc @miku

Hi, I have the Lenovo ThinkPad X1 Carbon 9th and the same issues.

I tried as you said. Leave a browser window playing video and move cursor to the left edge. Screen flickering.

Move cursor to the top edge. I will see a black line flickering on the screen.

Move to the right and bottom, nothing happened.

@zehortigoza Assigning to you, Thanks.

assigned to @zehortigoza

added platform: TGL label

added feature: display/PSR label

Can you give a try with this branch? https://github.com/zehortigoza/linux/tree/upstream-psr2-new-wa There is a missing TGL workaround for PSR2, please share the logs again with this branch + i915.psr_safest_params=1 set.

Thanks

Hello, I have too a Thinkpad X1 Carbon 9 which exhibits same screen flickering. I took dmesg.log from a kernel running on drm-tip tree.

dmesg.log.gz

PS: https://github.com/zehortigoza/linux/tree/upstream-psr2-new-wa branch failed to compile with following error: In file included from ./include/asm-generic/bug.h:5, from ./arch/x86/include/asm/bug.h:83, from ./include/linux/bug.h:5, from drivers/net/ethernet/netronome/nfp/bpf/jit.c:6: In function ‘ur_load_imm_any’, inlined from ‘jeq_imm’ at drivers/net/ethernet/netronome/nfp/bpf/jit.c:3118:13: ./include/linux/compiler.h:345:45: error: call to ‘__compiletime_assert_646’ declared with attribute error: BUILD_BUG_ON failed: (((0x0ffULL) + (1ULL << (__builtin_ffsll(0x0ffULL) - 1))) & (((0x0ffULL) + (1ULL << (__builtin_ffsll(0x0ffULL) - 1))) - 1)) != 0 345 | _compiletime_assert(condition, msg, _compiletime_assert, LINE)

Take the first two patches of that branch and applies to drm-tip or fetch the first two patches from here: https://patchwork.freedesktop.org/series/99989/

Hey - I will get back to you soon, sorry about that! Had to take some time off work unexpectedly

Attached log from kernel running on drm-tip branch plus two patches from https://patchwork.freedesktop.org/series/99989/. dmesg2.log.gz

Other device with pre-prodution silicon.

Feb 11 20:29:00 kernel: i915 device info: pciid=0x9a49 rev=0x01 platform=TIGERLAKE (subplatform=0x1) gen=12

Does it help? the branch that I shared in github has one additional patch to print debug information, so I know if this WA was applied in this device or not.

Setting i915.enable_psr2_sel_fetch=0 also fixes the issue for you?

Yes i915.enable_psr2_sel_fetch=0 fix the issue for my case too.

Finally I managed to compile above branch(https://github.com/zehortigoza/linux/tree/upstream-psr2-new-wa) so please see below log taken from respective kernel.

dmesg3.log

Regards, Mihai

I can also reproduce this now. Switched to Fedora35 and it's rather easy to reproduce. I couldn't reproduce this with Ubuntu 20.04. I'm using Dell XPS laptop.

You probably couldn't reproduce this on Ubuntu 20.04 because that version of Ubuntu is still using the Xorg display server, as opposed to Wayland on Fedora 35.

On DELL XPS 13 9310 with a Tiger Laker CPU and running Arch Linux with Gnome on Wayland, I started encountering this bug somewhere between 5.15.13 and 5.16, bisecting that brought me to find the PSR2 enabling being the culprit and this thread. Disabling it indeed fixes the problem for me. Hopefully, we'll see a fix for this upstream soon.

I can reproduce this bug on Dell XPS laptop with the new test I wrote:

https://patchwork.freedesktop.org/series/100559/

The glitch seems to happen on full frame update triggered by cursor moving to x < 0 or y < 0. Based on this information I prepared this patch:

https://patchwork.freedesktop.org/series/100550/

@lyudess, @plumerlis, @cornul11 and @mharpau, I would really appreciate for any testing support with my patch. At least on Dell XPS I'm not able to see the issue with the patch. While without the patch it's reproducing easily in my environment.

@jhogande, I have just applied this patch on 5.16.10 and the flickering seems to have disappeared. I do not notice it anymore when moving the cursor around the upper or left sides of the screen.

Would be great to comment with tested-by on ml for the series ? Thanks Jouni for the patch.

@jani.saarinen I'm still checking internally for the patch correctness. Thus haven't yet sent it to intel-gfx mailing list. It is currently only in intel-gfx-trybot. Yes, looks promising...

I can confirm that on drm-tip branch with above patch applied the flickers disappeared.

[mihai@devops ~]$ uname -r 5.17.0-rc5+ [mihai@devops ~]$ sudo cat /sys/kernel/debug/dri/0/i915_edp_psr_status Sink support: yes [0x03] PSR mode: PSR2 enabled Source PSR ctl: enabled [0xc2004a26] Source PSR status: SLEEP [0x300d0130] Busy frontbuffer bits: 0x00000000 Frame: PSR2 SU blocks: 0 300 1 300 2 300 3 300 4 300 5 300 6 300 7 300 PSR2 selective fetch: enabled [mihai@devops ~]$