Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #74402 > unrolled thread

Bug#1005005: Regression from 3c196f056666 ("drm/amdgpu: always reset the asic in suspend (v2)") on suspend?

Back to article view | Back to linux.debian.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#1005005: Regression from 3c196f056666 ("drm/amdgpu: always reset the asic in suspend (v2)") on suspend? Salvatore Bonaccorso <carnil@debian.org> - 2022-02-12 19:30 +0100
    Bug#1005005: Regression from 3c196f056666 ("drm/amdgpu: always reset the asic in suspend (v2)") on suspend? Thorsten Leemhuis <regressions@leemhuis.info> - 2022-02-14 13:50 +0100
    Bug#1005005: Regression from 3c196f056666 ("drm/amdgpu: always reset the asic in suspend (v2)") on suspend? Salvatore Bonaccorso <carnil@debian.org> - 2022-02-20 17:40 +0100
      Bug#1005005: Regression from 3c196f056666 ("drm/amdgpu: always reset the asic in suspend (v2)") on suspend? Dominique Dumont <dod@debian.org> - 2022-02-21 13:00 +0100

#74402 — Bug#1005005: Regression from 3c196f056666 ("drm/amdgpu: always reset the asic in suspend (v2)") on suspend?

Hi Alex, hi all

In Debian we got a regression report from Dominique Dumont, CC'ed in
https://bugs.debian.org/1005005 that afer an update to 5.15.15 based
kernel, his machine noe longer suspends correctly, after screen going
black as usual it comes back. The Debian bug above contians a trace.

Dominique confirmed that this issue persisted after updating to 5.16.7
furthermore he bisected the issue and found 

	3c196f05666610912645c7c5d9107706003f67c3 is the first bad commit
	commit 3c196f05666610912645c7c5d9107706003f67c3
	Author: Alex Deucher <alexander.deucher@amd.com>
	Date:   Fri Nov 12 11:25:30 2021 -0500

	    drm/amdgpu: always reset the asic in suspend (v2)

	    [ Upstream commit daf8de0874ab5b74b38a38726fdd3d07ef98a7ee ]

	    If the platform suspend happens to fail and the power rail
	    is not turned off, the GPU will be in an unknown state on
	    resume, so reset the asic so that it will be in a known
	    good state on resume even if the platform suspend failed.

	    v2: handle s0ix

	    Acked-by: Luben Tuikov <luben.tuikov@amd.com>
	    Acked-by: Evan Quan <evan.quan@amd.com>
	    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
	    Signed-off-by: Sasha Levin <sashal@kernel.org>

	 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 5 ++++-
	 1 file changed, 4 insertions(+), 1 deletion(-)

to be the first bad commit, see https://bugs.debian.org/1005005#34 .

Does this ring any bell? Any idea on the problem?

Regards,
Salvatore

[toc] | [next] | [standalone]

#74408

[TLDR: I'm adding the regression report below to regzbot, the Linux
kernel regression tracking bot; all text you find below is compiled from
a few templates paragraphs you might have encountered already already
from similar mails.]

Hi, this is your Linux kernel regression tracker speaking.

CCing the regression mailing list, as it should be in the loop for all
regressions, as explained here:
https://www.kernel.org/doc/html/latest/admin-guide/reporting-issues.html

To be sure this issue doesn't fall through the cracks unnoticed, I'm
adding it to regzbot, my Linux kernel regression tracking bot:

#regzbot ^introduced 3c196f056666
#regzbot title amdgfx: suspend stopped working
#regzbot ignore-activity
#regzbot link: https://bugs.debian.org/1005005

Reminder for developers: when fixing the issue, please add a 'Link:'
tags pointing to the report (the mail quoted above) using
lore.kernel.org/r/, as explained in
'Documentation/process/submitting-patches.rst' and
'Documentation/process/5.Posting.rst'. This allows the bot to connect
the report with any patches posted or committed to fix the issue; this
again allows the bot to show the current status of regressions and
automatically resolve the issue when the fix hits the right tree.

I'm sending this to everyone that got the initial report, to make them
aware of the tracking. I also hope that messages like this motivate
people to directly get at least the regression mailing list and ideally
even regzbot involved when dealing with regressions, as messages like
this wouldn't be needed then.

Don't worry, I'll send further messages wrt to this regression just to
the lists (with a tag in the subject so people can filter them away), if
they are relevant just for regzbot. With a bit of luck no such messages
will be needed anyway.

Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)

P.S.: As the Linux kernel's regression tracker I'm getting a lot of
reports on my table. I can only look briefly into most of them and lack
knowledge about most of the areas they concern. I thus unfortunately
will sometimes get things wrong or miss something important. I hope
that's not the case here; if you think it is, don't hesitate to tell me
in a public reply, it's in everyone's interest to set the public record
straight.


On 12.02.22 19:23, Salvatore Bonaccorso wrote:
> Hi Alex, hi all
> 
> In Debian we got a regression report from Dominique Dumont, CC'ed in
> https://bugs.debian.org/1005005 that afer an update to 5.15.15 based
> kernel, his machine noe longer suspends correctly, after screen going
> black as usual it comes back. The Debian bug above contians a trace.
> 
> Dominique confirmed that this issue persisted after updating to 5.16.7
> furthermore he bisected the issue and found 
> 
> 	3c196f05666610912645c7c5d9107706003f67c3 is the first bad commit
> 	commit 3c196f05666610912645c7c5d9107706003f67c3
> 	Author: Alex Deucher <alexander.deucher@amd.com>
> 	Date:   Fri Nov 12 11:25:30 2021 -0500
> 
> 	    drm/amdgpu: always reset the asic in suspend (v2)
> 
> 	    [ Upstream commit daf8de0874ab5b74b38a38726fdd3d07ef98a7ee ]
> 
> 	    If the platform suspend happens to fail and the power rail
> 	    is not turned off, the GPU will be in an unknown state on
> 	    resume, so reset the asic so that it will be in a known
> 	    good state on resume even if the platform suspend failed.
> 
> 	    v2: handle s0ix
> 
> 	    Acked-by: Luben Tuikov <luben.tuikov@amd.com>
> 	    Acked-by: Evan Quan <evan.quan@amd.com>
> 	    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
> 	    Signed-off-by: Sasha Levin <sashal@kernel.org>
> 
> 	 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 5 ++++-
> 	 1 file changed, 4 insertions(+), 1 deletion(-)
> 
> to be the first bad commit, see https://bugs.debian.org/1005005#34 .
> 
> Does this ring any bell? Any idea on the problem?
> 
> Regards,
> Salvatore

-- 
Additional information about regzbot:

If you want to know more about regzbot, check out its web-interface, the
getting start guide, and the references documentation:

https://linux-regtracking.leemhuis.info/regzbot/
https://gitlab.com/knurd42/regzbot/-/blob/main/docs/getting_started.md
https://gitlab.com/knurd42/regzbot/-/blob/main/docs/reference.md

The last two documents will explain how you can interact with regzbot
yourself if your want to.

Hint for reporters: when reporting a regression it's in your interest to
CC the regression list and tell regzbot about the issue, as that ensures
the regression makes it onto the radar of the Linux kernel's regression
tracker -- that's in your interest, as it ensures your report won't fall
through the cracks unnoticed.

Hint for developers: you normally don't need to care about regzbot once
it's involved. Fix the issue as you normally would, just remember to
include 'Link:' tag in the patch descriptions pointing to all reports
about the issue. This has been expected from developers even before
regzbot showed up for reasons explained in
'Documentation/process/submitting-patches.rst' and
'Documentation/process/5.Posting.rst'.

[toc] | [prev] | [next] | [standalone]

#74466

Hi Dominique

[dropping almost all recipients for this reply]

On Sun, Feb 20, 2022 at 04:48:43PM +0100, Dominique Dumont wrote:
> On Monday, 14 February 2022 22:52:27 CET Alex Deucher wrote:
> > Does the system actually suspend?  
> 
> Not really. The screens looks like it's going to suspend, but it does come 
> back after 10s or so. The light mounted in the middle of the power button does 
> not switch off.
> 
> > Is this system S0i3 or regular S3?
> 
> I'm not sure how to check that. After a bit of reading on the Internet [1], I 
> hope that the following information answers that question. Please get back to 
> me if that's not the case.
> 
> Looks like my system supports both Soi3 and S3
> 
> $ cat /sys/power/state 
> freeze mem disk
> 
> I get the same result running these 2 commands as root:
> # echo freeze > /sys/power/state
> # echo mem > /sys/power/state
> 
> >  Does this patch help by any chance?
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?i
> > d=e55a3aea418269266d84f426b3bd70794d3389c8
> 
> yes, with this patch:
> - the suspend issue is solved
> - kernel logs no longer show messages like "failed to send message" or 
> "*ERROR* suspend of IP block <powerplay> failed" while suspending

Okay great :). This commit landed in 5.16.8 for the 5.16.y series. I
did upload 5.16.10-1 (but the signed packages are yet missing). Can
you test this one to confirm the issue is fixed?

Regards,
Salvatore

[toc] | [prev] | [next] | [standalone]

#74470

On Sunday, 20 February 2022 17:36:20 CET Salvatore Bonaccorso wrote:
> Okay great :). This commit landed in 5.16.8 for the 5.16.y series. I
> did upload 5.16.10-1 (but the signed packages are yet missing). Can
> you test this one to confirm the issue is fixed?

I confirm that suspend works fine with:

Linux ylum 5.16.0-2-amd64 #1 SMP PREEMPT Debian 5.16.10-1 (2022-02-18) x86_64 
GNU/Linux

All the best

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web