Kernel 5.17.3 breaks resume after suspend

Brief summary of the problem:

After installing kernel 5.17.3 the system can't resume after it's put in suspension mode (s2idle). The laptop seems completely frozen and the power button needs to be kept pushed for ~15secs in order to reboot the system.

Hardware description:

• CPU: AMD 4700u
• GPU: 03:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Renoir [1002:1636] (rev c2)
• System Memory: 16Gb

System information:

• Distro name and Version: ArchLinux
• Kernel version: 5.17.3
• linux-firmware package version: 20220411
• amd-ucode package version: amd-ucode-20220411.705f19a

How to reproduce the issue:

1. Install kernel v 5.17.3
2. Suspend the system
3. Try to resume the system

Attached files:log.txt

changed the description

It's probably caused by https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.17.y&id=f8dea54f74cae8c2e4d7b2952e8fed7743a85c87. This caused a problem in 5.18-rc2 as well and copied to stable. If you can please revert that and confirm it helps? If it does then please try to apply https://lore.kernel.org/linux-gpio/20220414025705.598-1-mario.limonciello@amd.com/ and see if it helps. If it does, please reply with a Tested-By: and to add a Link: to this bug report.

I've been able to flawlessly resume the system ~10 times on kernel v.5.17.3 with the patch you provided.

I don't know whether this is relevant or not: I boot the system with the acpi.ec_no_wakeup=1 kernel parameter activated otherwise the resuming used to fail on previous kernel versions too.

You reverted the first commit and applied the patch, or did you apply the patch without removing the commit?

I hope I didn't misunderstand what I was supposed to do.

Reverting the commit solved the issue. Then I compiled the kernel without reverting the commit and applying the patch. Apparently this solved the issue for me.

OK. I will compile the kernel with the patch and report back.

The patch seems to do the trick for me too.

I don;t understand the "If it does, please reply with a Tested-By: and to add a Link: to this bug report."

added s0ix label

On my dell inspiron 14 this bugs blocks resume completely and i assume the behaviour would be same for other dell laptops too. i.e. the laptop is bricked until you either drain the battery or disconnect battery by opening the laptop. Ill test the fix once i receive my new screwdriver set (reverting to 517.2 for now)

My Lenovo T14 also is affected. I use S0ix but other users have reported issues with S3 also.

Operating System: Arch Linux Kernel Version: 5.17.3-arch1-1 (64-bit) Graphics Platform: X11 Processors: 12 × AMD Ryzen 5 PRO 4650U with Radeon Graphics Graphics Processor: AMD RENOIR

Thank for those of you that checked the patch and confirmed it fixes the problem. The linux-gpio maintainers will need to accept it. The following versions I can tell have backported the problematic patch:

• 5.17.3
• 5.16.20
• 5.15.34
• 5.10.111

5.15.34 has the same issue on my laptop. Do you need me to test the patch on that release as well?

I think we've got good representation on this issue, but you can pick it up and use it on your end until a solution is committed upstream.

Hello @superm1 how was it possible that a change like this that failed in the rolling release ram also happened to affect the extended support branch?

I upgraded two days ago and ran into this error, I always have the LTS kernel backed up because it's supposed to be more stable but this one was also affected. I had to remove Arch and install another distro.

Hello @superm1 how was it possible that a change like this that failed in the rolling release ram also happened to affect the extended support branch?

I don't know what rolling release ram is. If it tracks the stable trees, sure I don't see why not.

I upgraded two days ago and ran into this error, I always have the LTS kernel backed up because it's supposed to be more stable but this one was also affected.

This affects LTS stable kernels; yes.

I had to remove Arch and install another distro.

IMO you don't need to distro hop for a kernel bug. Stick to what you're comfortable with. Revert a patch, apply a patch and build your own kernel until the fix can be landed.

Can we make it happen asap? Be voting it or something?

You can reply to the mailing list with the patch (see the bottom of the patch page for instructions). You can add a Tested-By: and your email.

Beyond that it's kernel process. This problematic patch either needs to be reverted or this fix accepted and it's up to the kernel subsystem maintainer to do either action.

mentioned in issue #1979 (closed)

Hi @superm1,

I tested today with you patch on 5.18.0-rc3 and this is working. https://lore.kernel.org/linux-gpio/20220414025705.598-1-mario.limonciello@amd.com/

A good day.

This is not the same issue. It should have it's own bug with all the context. If this is Renoir (not cezanne) it might be #1712 (closed).

mentioned in commit nouveau@06fb4ecf

This was picked up by Linus today, so closing this issue. It will take some time to trickle to stable releases though, so FYI.

closed

Thanks you; We are talking about 5.18?

Yeah, It will be part of rc4.

mentioned in commit nouveau@54e6180c

mentioned in commit nouveau@571a67b0

mentioned in commit nouveau@d3f54679

mentioned in issue #1995 (closed)