On 18.05.22 07:54, Kai-Heng Feng wrote:
> On Wed, May 18, 2022 at 1:52 PM Thorsten Leemhuis
> <regressions@xxxxxxxxxxxxx> wrote:
>>
>> On 17.05.22 19:37, casteyde.christian@xxxxxxx wrote:
>>
>>> I've tryied to revert the offending commit on 5.18-rc7 (887f75cfd0da
>>> ("drm/amdgpu: Ensure HDA function is suspended before ASIC reset"), and
>>> the problem disappears so it's really this commit that breaks.
>>
>> In that case I'll update the regzbot status to make sure it's visible as
>> regression introduced in the 5.18 cycle:
>>
>> #regzbot introduced: 887f75cfd0da
>>
>> BTW: obviously would be nice to get this fixed before 5.18 is released
>> (which might already happen on Sunday), especially as the culprit
>> apparently was already backported to stable, but I guess that won't be
>> easy...
>>
>> Which made me wondering: is reverting the culprit temporarily in
>> mainline (and reapplying it later with a fix) a option here?
>
> It's too soon to call it's the culprit.
Well, sure, the root-cause might be somewhere else. But from the point
of kernel regressions (and tracking them) it's the culprit, as that's
the change that triggers the misbehavior. And that's how Linus
approaches these things as well when it comes to reverting to fix
regressions -- and he even might...
> The suspend on the system
> doesn't work properly at the first place.
...ignore things like this, as long as a revert is unlikely to cause
more damage than good.
Ciao. Thorsten
>> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
>>
>> P.S.: As the Linux kernel's regression tracker I deal with a lot of
>> reports and sometimes miss something important when writing mails like
>> this. If that's the case here, don't hesitate to tell me in a public
>> reply, it's in everyone's interest to set the public record straight.
>
