[AMD Official Use Only - General]
> -----Original Message-----
> From: Thorsten Leemhuis <regressions@xxxxxxxxxxxxx>
> Sent: Wednesday, May 18, 2022 01:37
> To: Kai-Heng Feng <kai.heng.feng@xxxxxxxxxxxxx>
> Cc: casteyde.christian@xxxxxxx; stable@xxxxxxxxxxxxxxx;
> regressions@xxxxxxxxxxxxxxx; Deucher, Alexander
> <Alexander.Deucher@xxxxxxx>; gregkh@xxxxxxxxxxxxxxxxxxx; Limonciello,
> Mario <Mario.Limonciello@xxxxxxx>
> Subject: Re: [REGRESSION] Laptop with Ryzen 4600H fails to resume video
> since 5.17.4 (works 5.17.3)
>
> 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.
I think the right way to focus on this is to fix the original suspend issue.
The fact that the first suspend is failing with s3 should be a red flag that
the system is in a pretty bad state.
Maybe can we get /sys/power/pm_debug_messages turned on as well
as /sys/power/pm_print_times. Then we should have a better idea on
what is going on that triggers that first failure.
Again, it would be much better to put all this in a bug report somewhere.
It's really hard to associate dmesgs in a threaded email with what's going
on. Kernel Bugzilla, AMD's Gitlab, it doesn't matter where really. Anywhere
is better than email threads IMO.
In this case the revert would causes problems for the resume of any dGPU.
So it's a tradeoff of many dGPU resume failures vs one APU resume failure
in s2idle after a failed suspend in s3.
BTW - I'm not really sure why the system is picking s2idle for "the second try".
Is that the kernel doing this, or is this userspace causing it? We really shouldn't
be seeing different suspend modes across attempts without a user consciously
selecting one.
>
> 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.
> >
