Hi! Since kernel 6.1.22 starting a resume from hibernate by hitting a key on the keyboard fails. However, if the PC was switched off and on again (or reset), the resume is OK. The APU is a Ryzen 5600G.
Bisecting between 6.1.21/22 turned up this:
Author: Tim Huang tim.huang@amd.com Date: Thu Mar 9 16:27:51 2023 +0800
drm/amdgpu: skip ASIC reset for APUs when go to S4
commit b589626674de94d977e81c99bf7905872b991197 upstream.
For GC IP v11.0.4/11, PSP TMR need to be reserved for ASIC mode2 reset. But for S4, when psp suspend, it will destroy the TMR that fails the ASIC reset. [...]
Reverting the commit solves the problem. Thanks.
Rainer Fiebig
[CCing the regression list, as it should be in the loop for regressions: https://docs.kernel.org/admin-guide/reporting-regressions.html]
On 06.04.23 14:06, Rainer Fiebig wrote:
Hi! Since kernel 6.1.22 starting a resume from hibernate by hitting a key on the keyboard fails. However, if the PC was switched off and on again (or reset), the resume is OK. The APU is a Ryzen 5600G.
Bisecting between 6.1.21/22 turned up this:
Author: Tim Huang tim.huang@amd.com Date: Thu Mar 9 16:27:51 2023 +0800
drm/amdgpu: skip ASIC reset for APUs when go to S4 commit b589626674de94d977e81c99bf7905872b991197 upstream. For GC IP v11.0.4/11, PSP TMR need to be reserved for ASIC mode2 reset. But for S4, when psp suspend, it will destroy the TMR that fails the ASIC reset.[...]
Reverting the commit solves the problem. Thanks.
Please try 6.1.23 and report back, because from the thread https://lore.kernel.org/all/20230330160740.1dbff94b@schienar/ it sounds a lot like "drm/amdgpu: allow more APUs to do mode2 reset when go to S4" might be fixing this, which went into 6.1.23.
Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat) -- Everything you wanna know about Linux kernel regression tracking: https://linux-regtracking.leemhuis.info/about/#tldr If I did something stupid, please tell me, as explained on that page.
Am 06.04.23 um 15:30 schrieb Linux regression tracking (Thorsten Leemhuis):
[CCing the regression list, as it should be in the loop for regressions: https://docs.kernel.org/admin-guide/reporting-regressions.html]
On 06.04.23 14:06, Rainer Fiebig wrote:
Hi! Since kernel 6.1.22 starting a resume from hibernate by hitting a key on the keyboard fails. However, if the PC was switched off and on again (or reset), the resume is OK. The APU is a Ryzen 5600G.
Bisecting between 6.1.21/22 turned up this:
Author: Tim Huang tim.huang@amd.com Date: Thu Mar 9 16:27:51 2023 +0800
drm/amdgpu: skip ASIC reset for APUs when go to S4 commit b589626674de94d977e81c99bf7905872b991197 upstream. For GC IP v11.0.4/11, PSP TMR need to be reserved for ASIC mode2 reset. But for S4, when psp suspend, it will destroy the TMR that fails the ASIC reset.[...]
Reverting the commit solves the problem. Thanks.
Please try 6.1.23 and report back, because from the thread https://lore.kernel.org/all/20230330160740.1dbff94b@schienar/ it sounds a lot like "drm/amdgpu: allow more APUs to do mode2 reset when go to S4" might be fixing this, which went into 6.1.23.
Yes, 6.1.23 seems OK so far.
I think, however, that rc-kernels and LTS-kernels are different matters. With a bleeding edge kernel, problems are to be expected. But an LTS-kernel is chosen for stability. And this is the second time within just a few weeks that I've been bitten by a time-consuming hibernate-bug caused by a backport of a commit in amdgpu.
So I'm asking the devs to either test their patches more thoroughly or to be a bit more conservative with what they recommend for backporting to LTS-kernels. Thanks.
Rainer Fiebig
Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
Everything you wanna know about Linux kernel regression tracking: https://linux-regtracking.leemhuis.info/about/#tldr If I did something stupid, please tell me, as explained on that page.
On Thu, Apr 06, 2023 at 05:39:07PM +0200, Rainer Fiebig wrote:
Am 06.04.23 um 15:30 schrieb Linux regression tracking (Thorsten Leemhuis):
[CCing the regression list, as it should be in the loop for regressions: https://docs.kernel.org/admin-guide/reporting-regressions.html]
On 06.04.23 14:06, Rainer Fiebig wrote:
Hi! Since kernel 6.1.22 starting a resume from hibernate by hitting a key on the keyboard fails. However, if the PC was switched off and on again (or reset), the resume is OK. The APU is a Ryzen 5600G.
Bisecting between 6.1.21/22 turned up this:
Author: Tim Huang tim.huang@amd.com Date: Thu Mar 9 16:27:51 2023 +0800
drm/amdgpu: skip ASIC reset for APUs when go to S4 commit b589626674de94d977e81c99bf7905872b991197 upstream. For GC IP v11.0.4/11, PSP TMR need to be reserved for ASIC mode2 reset. But for S4, when psp suspend, it will destroy the TMR that fails the ASIC reset.[...]
Reverting the commit solves the problem. Thanks.
Please try 6.1.23 and report back, because from the thread https://lore.kernel.org/all/20230330160740.1dbff94b@schienar/ it sounds a lot like "drm/amdgpu: allow more APUs to do mode2 reset when go to S4" might be fixing this, which went into 6.1.23.
Yes, 6.1.23 seems OK so far.
I think, however, that rc-kernels and LTS-kernels are different matters. With a bleeding edge kernel, problems are to be expected. But an LTS-kernel is chosen for stability. And this is the second time within just a few weeks that I've been bitten by a time-consuming hibernate-bug caused by a backport of a commit in amdgpu.
So I'm asking the devs to either test their patches more thoroughly or to be a bit more conservative with what they recommend for backporting to LTS-kernels. Thanks.
Please feel free to suggest better ways to have automated tests for stuff like this, or to help provide testing for the -rc LTS/stable kernel releases.
We can't do this alone :)
thanks,
greg k-h
Am 06.04.23 um 22:09 schrieb Greg KH:
On Thu, Apr 06, 2023 at 05:39:07PM +0200, Rainer Fiebig wrote:
Am 06.04.23 um 15:30 schrieb Linux regression tracking (Thorsten Leemhuis):
[CCing the regression list, as it should be in the loop for regressions: https://docs.kernel.org/admin-guide/reporting-regressions.html]
On 06.04.23 14:06, Rainer Fiebig wrote:
Hi! Since kernel 6.1.22 starting a resume from hibernate by hitting a key on the keyboard fails. However, if the PC was switched off and on again (or reset), the resume is OK. The APU is a Ryzen 5600G.
Bisecting between 6.1.21/22 turned up this:
Author: Tim Huang tim.huang@amd.com Date: Thu Mar 9 16:27:51 2023 +0800
drm/amdgpu: skip ASIC reset for APUs when go to S4 commit b589626674de94d977e81c99bf7905872b991197 upstream. For GC IP v11.0.4/11, PSP TMR need to be reserved for ASIC mode2 reset. But for S4, when psp suspend, it will destroy the TMR that fails the ASIC reset.[...]
Reverting the commit solves the problem. Thanks.
Please try 6.1.23 and report back, because from the thread https://lore.kernel.org/all/20230330160740.1dbff94b@schienar/ it sounds a lot like "drm/amdgpu: allow more APUs to do mode2 reset when go to S4" might be fixing this, which went into 6.1.23.
Yes, 6.1.23 seems OK so far.
I think, however, that rc-kernels and LTS-kernels are different matters. With a bleeding edge kernel, problems are to be expected. But an LTS-kernel is chosen for stability. And this is the second time within just a few weeks that I've been bitten by a time-consuming hibernate-bug caused by a backport of a commit in amdgpu.
So I'm asking the devs to either test their patches more thoroughly or to be a bit more conservative with what they recommend for backporting to LTS-kernels. Thanks.
Please feel free to suggest better ways to have automated tests for stuff like this, or to help provide testing for the -rc LTS/stable kernel releases.
Well, I'm afraid I can't offer a panacea or the ultimate automated quality assurance system. But for the two cases that I've encountered lately, a simple hibernate/resume would have shown that there's a problem. After all, that's how I and other users noticed it.
So I think the primary line of defence against regressions remains the developer himself who should try hard to imagine what ramifications his patch might have and test it accordingly. But I'm aware of the fact that we are all only humans.
Another idea might be to give patches that introduce new features or only minimal improvements ample time to mature in the latest stable kernel before backporting them to LTS-kernels, say three or four point-releases. Or to only backport fixes for bugs or security issues.
We can't do this alone :)
Right. For now I can't commit to testing release-candidates because of a lack in time. But I try to bisect and report problems as soon as possible so that they can be resolved quickly.
To avoid a false impression: kernelwise - and including amdgpu - I'm rather happy with the current state of affairs. Thanks to all!
Rainer Fiebig
On Fri, Apr 07, 2023 at 01:56:49PM +0200, Rainer Fiebig wrote:
Am 06.04.23 um 22:09 schrieb Greg KH:
On Thu, Apr 06, 2023 at 05:39:07PM +0200, Rainer Fiebig wrote:
Am 06.04.23 um 15:30 schrieb Linux regression tracking (Thorsten Leemhuis):
[CCing the regression list, as it should be in the loop for regressions: https://docs.kernel.org/admin-guide/reporting-regressions.html]
On 06.04.23 14:06, Rainer Fiebig wrote:
Hi! Since kernel 6.1.22 starting a resume from hibernate by hitting a key on the keyboard fails. However, if the PC was switched off and on again (or reset), the resume is OK. The APU is a Ryzen 5600G.
Bisecting between 6.1.21/22 turned up this:
Author: Tim Huang tim.huang@amd.com Date: Thu Mar 9 16:27:51 2023 +0800
drm/amdgpu: skip ASIC reset for APUs when go to S4 commit b589626674de94d977e81c99bf7905872b991197 upstream. For GC IP v11.0.4/11, PSP TMR need to be reserved for ASIC mode2 reset. But for S4, when psp suspend, it will destroy the TMR that fails the ASIC reset.[...]
Reverting the commit solves the problem. Thanks.
Please try 6.1.23 and report back, because from the thread https://lore.kernel.org/all/20230330160740.1dbff94b@schienar/ it sounds a lot like "drm/amdgpu: allow more APUs to do mode2 reset when go to S4" might be fixing this, which went into 6.1.23.
Yes, 6.1.23 seems OK so far.
I think, however, that rc-kernels and LTS-kernels are different matters. With a bleeding edge kernel, problems are to be expected. But an LTS-kernel is chosen for stability. And this is the second time within just a few weeks that I've been bitten by a time-consuming hibernate-bug caused by a backport of a commit in amdgpu.
So I'm asking the devs to either test their patches more thoroughly or to be a bit more conservative with what they recommend for backporting to LTS-kernels. Thanks.
Please feel free to suggest better ways to have automated tests for stuff like this, or to help provide testing for the -rc LTS/stable kernel releases.
Well, I'm afraid I can't offer a panacea or the ultimate automated quality assurance system. But for the two cases that I've encountered lately, a simple hibernate/resume would have shown that there's a problem. After all, that's how I and other users noticed it.
So I think the primary line of defence against regressions remains the developer himself who should try hard to imagine what ramifications his patch might have and test it accordingly. But I'm aware of the fact that we are all only humans.
Another idea might be to give patches that introduce new features or only minimal improvements ample time to mature in the latest stable kernel before backporting them to LTS-kernels, say three or four point-releases. Or to only backport fixes for bugs or security issues.
This is a long-running discussion. How do you determine that a "bug fix" should not be backported now? For example, this bugfix that caused a problem was a reported fix for something else, and it had passed the automated testing system that the DRM developers have. So why wait on it?
There's always going to be slip ups, and fixes needed for fixes as we can't test all hardware configurations or use-cases, all we can do is react quickly to fix problems when reported.
And in this case, it was fixed _before_ you reported it, which to be honest, is pretty fast :)
thanks,
greg k-h
linux-stable-mirror@lists.linaro.org
-
Greg KH -
Linux regression tracking (Thorsten Leemhuis) -
Rainer Fiebig