On Tue, Nov 28, 2023 at 11:45 PM Luben Tuikov <ltuikov89@xxxxxxxxx> wrote: > > On 2023-11-28 17:13, Alex Deucher wrote: > > On Mon, Nov 27, 2023 at 6:24 PM Phillip Susi <phill@xxxxxxxxxxxx> wrote: > >> > >> Alex Deucher <alexdeucher@xxxxxxxxx> 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@xxxxxxxxxxxxxxxx/ > > 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. Alex
