[AMD Official Use Only - General]
-----Original Message----- From: Thorsten Leemhuis regressions@leemhuis.info Sent: Wednesday, May 18, 2022 01:37 To: Kai-Heng Feng kai.heng.feng@canonical.com Cc: casteyde.christian@free.fr; stable@vger.kernel.org; regressions@lists.linux.dev; Deucher, Alexander Alexander.Deucher@amd.com; gregkh@linuxfoundation.org; Limonciello, Mario Mario.Limonciello@amd.com 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@leemhuis.info wrote:
On 17.05.22 19:37, casteyde.christian@free.fr 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.