lkml.org 
[lkml]   [2023]   [Nov]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: Radeon regression in 6.6 kernel
From
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]
\
 
 \ /
  Last update: 2023-11-29 05:45    [W:0.155 / U:0.204 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site