kernel 6.10rc1-to-rc7 & 6.10 display corruption - amd 6750xt related to adaptive sync

Brief summary of the problem:

The problem started with kernel 6.10rc (tested rc6 &rc7 mainline same problem). Everything is fine with kernel 6.9.

See screenshot below. The 1/6 at the top of the screen is corrupted when things are moving on the screen (i.ex moving the mouse or windows, etc..) in kde wayland. The 5/6 screen real estate below that is fine.

The same corruption continues on the tty terminal while the text is scrolling during the systemd services shutdown to reboot the system.

It always constantly happens and starts right after login in kde.

Hardware description:

• CPU: amd ryzen 7900x
• GPU: amd rx 6750xt
• System Memory: 32gb ddr5 6000
• Display(s): Samsung G7 LS28AG70
• Type of Display Connection: DP

System information:

• Distro name and Version: Cachyos (Archlinux rolling).
• Kernel version: linux-mainline 6.10rc7-1 (from here)
• Custom kernel: N/A
• AMD official driver version: amd mesa v: 24.1.2-arch1.2

How to reproduce the issue:

1. log into kde
2. move the mouse (or anything else)

Attached files:

Screenshots/video files

Log files (for system lockups / game freezes / crashes)

• Full system log

added 6000 dGPU Series label

Can you bisect?

Here is some information on bisecting using git:

https://docs.kernel.org/admin-guide/bug-bisect.html

https://wiki.archlinux.org/title/Bisecting_bugs_with_Git

Here is the bisect log: bisect.log

1. I started it by setting 6.10rc1 as bad and 6.9 as good. It gave me 13 steps. I have done all of them.
2. After the only good bisect, the next couple ones (bad): on the kde login screen I got a black screen with a working mouse pointer.
3. And after that, the several next ones crashed on boot with a stack trace and network manager failing to start, with a 10 minutes delay for network manager to restart. After waiting the 10 minutes, I got a black screen with no login manager. And on the tty, I could enter the user name, but then I got no response (no terminal) after entering the password.
4. And then the several last ones failed to build with:

INSTALL libbpf_headers make[5]: *** No rule to make target « ~/tmp/src/linux-mainline/tools/include/linux/panic.h », needed for « ~/tmp/src/linux-mainline/tools/bpf/resolve_btfids/libsubcmd/parse-options.o ». Stop. make[4]: *** [Makefile:80: ~/tmp/src/linux-mainline/tools/bpf/resolve_btfids/libsubcmd/libsubcmd-in.o] Error 2

So, I'm not sure if this will really precisely pin point the problem.

But as you can see, the bad one (with the display corruption as in the original report & screenshot) just before the only good one (where the problem didn't happen) was:

bad: [db5d28c0bfe566908719bec8e25443aabecbb802] Merge tag 'drm-next-2024-05-15' of https://gitlab.freedesktop.org/drm/kernel

You need to run make clean in between builds typically when that happens.

Ok, I have completely restarted the bistect from a new git download. With "make clean" every time.

Here is bisect_report_and_log.log

I don't think the commit bisect reported at the end as the first bad commit is the right one. Because another bug appeared during the runs that prevented some of the kernels to get to a loaded login screen:

1. after the 2nd detected good commit, all of the bad commits resulted in a crash on boot with a stack trace and network manager failing to start, with a 10 minutes delay for network manager to restart. After waiting the 10 minutes, I got a black screen with no login manager, but only the mouse cursor with an underscore ("_") in the top left of the screen). And on the tty, I could enter the username, but then I got no response (no terminal) after entering the password.
2. also, all of these problematic commits (and also the good ones at the end), were in the v.6.9-rc2 range. But I never had any issues with the 6.9rc and 6.9 kernels when they came out.
3. -> so I think the first bad commit reported by bisect is the other bug that appeared during the runs, which, I think, has nothing to do with the display corruption but in the 6.10rc kernels.

So I think the bad commit is (or around):

bad: [db5d28c0bfe566908719bec8e25443aabecbb802] Merge tag 'drm-next-2024-05-15' of https://gitlab.freedesktop.org/drm/kernel

Yeah I also don't think it's likely that commit. I think what you should do is mark any commit that is a "different" but bad behavior as a "skip". This will let it try something else near by and get you more determinate result.

Unfortunately that's a big merge commit you mention as bad or around, which means it doesn't really narrow down "too" much.

Ok, how can I narrow it down so that it doesn't go back into the 6.9rcs as it did (it went back to 6.9rc2...)?

So that it stays close to "Merge tag 'drm-next-2024-05-15' of https://gitlab.freedesktop.org/drm/kernel"

... and doesn't go too far back before this happened?

You can try to use the tags on https://gitlab.freedesktop.org/drm/kernel instead as your bisect points maybe.

Ok, this time I used between drm-fixes-2024-05-11 (drm fixes for 6.9 final) and drm-next-2024-05-25 (drm fixes for 6.10-rc1).

first bad commit: [6d4279cb99ac4f51d10409501d29969f687ac8dc] drm/amd/display: Drop legacy code.

bisect.log

Looking that over the most suspicious hunk would be

diff --git a/drivers/gpu/drm/amd/display/dc/optc/dcn20/dcn20_optc.c b/drivers/gpu/drm/amd/display/dc/optc/dcn20/dcn20_optc.c
index 58bdbd859bf9b..d6f095b4555dc 100644
--- a/drivers/gpu/drm/amd/display/dc/optc/dcn20/dcn20_optc.c
+++ b/drivers/gpu/drm/amd/display/dc/optc/dcn20/dcn20_optc.c
@@ -462,16 +462,6 @@ void optc2_setup_manual_trigger(struct timing_generator *optc)
 {
        struct optc *optc1 = DCN10TG_FROM_TG(optc);
 
-       /* Set the min/max selectors unconditionally so that
-        * DMCUB fw may change OTG timings when necessary
-        * TODO: Remove the w/a after fixing the issue in DMCUB firmware
-        */
-       REG_UPDATE_4(OTG_V_TOTAL_CONTROL,
-                                OTG_V_TOTAL_MIN_SEL, 1,
-                                OTG_V_TOTAL_MAX_SEL, 1,
-                                OTG_FORCE_LOCK_ON_EVENT, 0,
-                                OTG_SET_V_TOTAL_MIN_MASK, (1 << 1)); /* TRIGA */
-
        REG_SET_8(OTG_TRIGA_CNTL, 0,
                        OTG_TRIGA_SOURCE_SELECT, 21,
                        OTG_TRIGA_SOURCE_PIPE_SELECT, optc->inst,

Can you revert just that hunk and see if it helps?

No, unfortunately the issue is still there. Exactly the same as before.

(After building & testing I double checked again that dcn20_optc.c was correctly reverted after line 462).

added bisected label

Sounds like a duplicate of this issue: https://lists.freedesktop.org/archives/amd-gfx/2024-July/110790.html

@siqueira Seems to be specific to LG TVs connected via HDMI?

Reading that thread I just tested:

1. 60hz this FIXES THE PROBLEM!
2. 120hz the corruption bug is there.
3. 144hz (my original report) the corruption bug is there.

Here is the output of my "sudo cat /sys/kernel/debug/dri/0/amdgpu_firmware_info":

amdgpu_firmware_info.txt

I am on Samsung G7 LS28AG70 monitor via DP, amd rx6750xt.

Furthermore:

At 120hz the corruption is ~20% thinner than at 144hz.

Also:

I'm at 4k (3840x2160).

edit: I tested lowering the resolution. The lower the resolution the more the corruption flickers.

added DC label

changed title from kernel 6.10rc7 display corruption - amd 6750xt to kernel 6.10rc7 & 6.10 display corruption - amd 6750xt

Fyi, the release kernel 6.10 still has the same problem.

How could let such a broken driver go from rc to the final release? Is amd not about solid stable software with quality releases?

changed title from kernel 6.10rc7 & 6.10 display corruption - amd 6750xt to kernel 6.10rc1-to-rc7 & 6.10 display corruption - amd 6750xt

marked #3412 (closed) as a duplicate of this issue

marked this issue as related to #3412 (closed)

Does this patch fix it?

0001-drm-amd-display-fix-corruption-with-high-refresh-rat.patch

changed title from kernel 6.10rc1-to-rc7 & 6.10 display corruption - amd 6750xt to kernel 6.10rc1-to-rc7 & 6.10 display corruption - amd 6750xt related to adaptive sync

mentioned in issue #3412 (closed)

I'm closing this as everything is fine with the above patch.