Re: Radeon regression in 6.6 kernel

From: Alex Deucher <alexdeucher@gmail.com>
To: Luben Tuikov <ltuikov89@gmail.com>
Cc: "Phillip Susi" <phill@thesusis.net>,
	"Linux regressions mailing list" <regressions@lists.linux.dev>,
	"Christian König" <ckoenig.leichtzumerken@gmail.com>,
	linux-kernel@vger.kernel.org,
	"amd-gfx@lists.freedesktop.org" <amd-gfx@lists.freedesktop.org>,
	dri-devel@lists.freedesktop.org,
	"Alex Deucher" <alexander.deucher@amd.com>,
	"Christian König" <christian.koenig@amd.com>
Subject: Re: Radeon regression in 6.6 kernel
Date: Wed, 29 Nov 2023 10:22:57 -0500	[thread overview]
Message-ID: <CADnq5_OC=JFpGcN0oGbTF5xYEt4X3r0=jEY6hJ12W8CzYq1+cA@mail.gmail.com> (raw)
In-Reply-To: <CADnq5_MYEWx=e1LBLeVs0UbR5_xEScjDyw_-75mLe8RAMnqh6g@mail.gmail.com>

On Wed, Nov 29, 2023 at 8:50 AM Alex Deucher <alexdeucher@gmail.com> wrote:
>
> On Tue, Nov 28, 2023 at 11:45 PM Luben Tuikov <ltuikov89@gmail.com> wrote:
> >
> > On 2023-11-28 17:13, Alex Deucher wrote:
> > > On Mon, Nov 27, 2023 at 6:24 PM Phillip Susi <phill@thesusis.net> wrote:
> > >>
> > >> Alex Deucher <alexdeucher@gmail.com> writes:
> > >>
> > >>>> In that case those are the already known problems with the scheduler
> > >>>> changes, aren't they?
> > >>>
> > >>> Yes.  Those changes went into 6.7 though, not 6.6 AFAIK.  Maybe I'm
> > >>> misunderstanding what the original report was actually testing.  If it
> > >>> was 6.7, then try reverting:
> > >>> 56e449603f0ac580700621a356d35d5716a62ce5
> > >>> b70438004a14f4d0f9890b3297cd66248728546c
> > >>
> > >> At some point it was suggested that I file a gitlab issue, but I took
> > >> this to mean it was already known and being worked on.  -rc3 came out
> > >> today and still has the problem.  Is there a known issue I could track?
> > >>
> > >
> > > At this point, unless there are any objections, I think we should just
> > > revert the two patches
> > Uhm, no.
> >
> > Why "the two" patches?
> >
> > This email, part of this thread,
> >
> > https://lore.kernel.org/all/87r0kircdo.fsf@vps.thesusis.net/
> >
> > clearly states that reverting *only* this commit,
> > 56e449603f0ac5 drm/sched: Convert the GPU scheduler to variable number of run-queues
> > *does not* mitigate the failed suspend. (Furthermore, this commit doesn't really change
> > anything operational, other than using an allocated array, instead of a static one, in DRM,
> > while the 2nd patch is solely contained within the amdgpu driver code.)
> >
> > Leaving us with only this change,
> > b70438004a14f4 drm/amdgpu: move buffer funcs setting up a level
> > to be at fault, as the kernel log attached in the linked email above shows.
> >
> > The conclusion is that only b70438004a14f4 needs reverting.
>
> b70438004a14f4 was a fix for 56e449603f0ac5.  Without b70438004a14f4,
> 56e449603f0ac5 breaks amdgpu.

We can try and re-enable it in the next kernel.  I'm just not sure
we'll be able to fix this in time for 6.7 with the holidays and all
and I don't want to cause a lot of scheduler churn at the end of the
6.7 cycle if we hold off and try and fix it.  Reverting seems like the
best short term solution.

Alex

>
> Alex