Messages in this thread | | | Date | Tue, 28 Nov 2023 23:44:57 -0500 | Subject | Re: Radeon regression in 6.6 kernel | From | Luben Tuikov <> |
| |
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. -- Regards, Luben [unhandled content-type:application/pgp-keys][unhandled content-type:application/pgp-signature] | |