Re: PROBLEM: AMD Ryzen 9 7950X iGPU - Blinking Issue

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jun 7, 2023 at 4:42 AM Felix Richter <judge@xxxxxxxxxxxxxxxxx> wrote:
>
> Hi Guys,
>
> so I checked, the kernel I am running has this commit
> (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> /commit/?id=08da182175db4c7f80850354849d95f2670e8cd9) applied already!
>
> https://github.com/ju6ge/linux/commit/917680e6056aa288cac288d3afd2745d372beb61u
>
> And the bug of display flickering persists with or without the
> amdgpu.sg_display=0 variable applied!

That is unexpected.  Setting sg_display=0 should be equivalent to
reverting 81d0bcf9900932633d270d5bc4a54ff599c6ebdb.  Does the attached
patch (with sg_display=0 set) make any difference?

Alex


>
> Kind regards,
> Felix Richter
>
>
> On 6/5/23 16:11, Alex Deucher wrote:
> > + Hamza
> > This is a known issue.  You can workaround it by setting
> > amdgpu.sg_display=0.  It should be issue should be fixed in:
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=08da182175db4c7f80850354849d95f2670e8cd9
> >
> > Alex
> >
> >
> >
> >> Now if this is the desired long term fix I do not know …
> >>
> >> Kind regards,
> >> Felix Richter
> >>
> >> On 02.05.23 16:12, Linux regression tracking (Thorsten Leemhuis) wrote:
> >>> On 02.05.23 15:48, Felix Richter wrote:
> >>>> On 5/2/23 15:34, Linux regression tracking (Thorsten Leemhuis) wrote:
> >>>>> On 02.05.23 15:13, Alex Deucher wrote:
> >>>>>> On Tue, May 2, 2023 at 7:45 AM Linux regression tracking (Thorsten
> >>>>>> Leemhuis)<regressions@xxxxxxxxxxxxx>  wrote:
> >>>>>>
> >>>>>>> On 30.04.23 13:44, Felix Richter wrote:
> >>>>>>>> Hi,
> >>>>>>>>
> >>>>>>>> I am running into an issue with the integrated GPU of the Ryzen 9
> >>>>>>>> 7950X. It seems to be a regression from kernel version 6.1 to 6.2.
> >>>>>>>> The bug materializes in from of my monitor blinking, meaning it
> >>>>>>>> turns full white shortly. This happens very often so that the
> >>>>>>>> system becomes unpleasant to use.
> >>>>>>>>
> >>>>>>>> I am running the Archlinux Kernel:
> >>>>>>>> The Issue happens on the bleeding edge kernel: 6.2.13
> >>>>>>>> Switching back to the LTS kernel resolves the issue: 6.1.26
> >>>>>>>>
> >>>>>>>> I have two monitors attached to the system. One 42 inch 4k Display
> >>>>>>>> and a 24 inch 1080p Display and am running sway as my desktop.
> >>>>>>>>
> >>>>>>>> Let me know if there is more information I could provide to help
> >>>>>>>> narrow down the issue.
> >>>>>>> Thanks for the report. To be sure the issue doesn't fall through the
> >>>>>>> cracks unnoticed, I'm adding it to regzbot, the Linux kernel regression
> >>>>>>> tracking bot:
> >>>>>>>
> >>>>>>> #regzbot ^introduced v6.1..v6.2
> >>>>>>> #regzbot title drm: amdgpu: system becomes unpleasant to use after
> >>>>>>> monitor starts blinking and turns full white
> >>>>>>> #regzbot ignore-activity
> >>>>>>>
> >>>>>>> This isn't a regression? This issue or a fix for it are already
> >>>>>>> discussed somewhere else? It was fixed already? You want to clarify
> >>>>>>> when
> >>>>>>> the regression started to happen? Or point out I got the title or
> >>>>>>> something else totally wrong? Then just reply and tell me -- ideally
> >>>>>>> while also telling regzbot about it, as explained by the page listed in
> >>>>>>> the footer of this mail.
> >>>>>>>
> >>>>>>> Developers: When fixing the issue, remember to add 'Link:' tags
> >>>>>>> pointing
> >>>>>>> to the report (the parent of this mail). See page linked in footer for
> >>>>>>> details.
> >>>>>> This sounds exactly like the issue that was fixed in this patch which
> >>>>>> is already on it's way to Linus:
> >>>>>> https://gitlab.freedesktop.org/agd5f/linux/-/commit/08da182175db4c7f80850354849d95f2670e8cd9
> >>>>> FWIW, you in the flood of emails likely missed that this is the same
> >>>>> thread where you yesterday replied "If the module parameter didn't help
> >>>>> then perhaps you are seeing some other issue.  Can you bisect?". That's
> >>>>> why I decided to add this to the tracking. Or am I missing something
> >>>>> obvious here?
> >>>>>
> >>>>> /me looks around again and can't see anything, but that doesn't have to
> >>>>> mean anything...
> >>>>>
> >>>>> Felix, btw, this guide might help you with the bisection, even if it's
> >>>>> just for kernel compilation:
> >>>>>
> >>>>> https://docs.kernel.org/next/admin-guide/quickly-build-trimmed-linux.html
> >>>>>
> >>>>> And to indirectly reply to your mail from yesterday[1]. You might want
> >>>>> to ignore the arch linux kernel git repo and just do a bisection between
> >>>>> 6.1 and the latest 6.2.y kernel using upstream repos; and if I were you
> >>>>> I'd also try 6.3 or even mainline before that, in case the issue was
> >>>>> fixed already.
> >>>>>
> >>>>> [1]
> >>>>> https://lore.kernel.org/all/04749ee4-0728-92fe-bcb0-a7320279eaac@xxxxxxxxxxxxxxxxx/
> >>>>>
> >>>> Thanks for the pointers, I'll do a bisection on my desktop from 6.1 to
> >>>> the newest commit.
> >>> FWIW, I wonder what you actually mean with "newest commit" here: a
> >>> bisection between 6.1 and mainline HEAD might be a waste of time, *if*
> >>> this is something that only happens in 6.2.y (say due to a broken or
> >>> incomplete backport)
> >>>
> >>>> That was the part I was mostly unsure about … where
> >>>> to start from.
> >>>>
> >>>> I was planning to use PKGBUILD scripts from arch to achieve the same
> >>>> configuration as I would when installing
> >>>> the package and just rewrite the script to use a local copy of the
> >>>> source code instead of the repository.
> >>>> That way I can just use the bisect command, rebuild the package and test
> >>>> again.
> >>> In my experience trying to deal with Linux distro's package managers
> >>> creates more trouble than it's worth.
> >>>
> >>>> But I probably won't be able to finish it this week, since I am on
> >>>> vacation starting tomorrow and will not have access to the computer in
> >>>> question. I will be back next week, by that time the patch Alex is
> >>>> talking about might
> >>>> already be in mainline. So if that fixes it, I will notice and let you
> >>>> know. If not I will do the bisection to figure out what the actual issue
> >>>> is.
> >>> Enjoy your vacation!
> >>>
> >>> Ciao, Thorsten
>
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index cc65c334cb64..195b4ff7a287 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -1631,10 +1631,7 @@ static int amdgpu_dm_init(struct amdgpu_device *adev)
 		break;
 	}
 	if (init_data.flags.gpu_vm_support &&
-	    (amdgpu_sg_display == 0))
-		init_data.flags.gpu_vm_support = false;
-
-	if (init_data.flags.gpu_vm_support)
+	    (amdgpu_sg_display != 0))
 		adev->mode_info.gpu_vm_support = true;
 
 	if (amdgpu_dc_feature_mask & DC_FBC_MASK)

[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux