Bug 2189510 - Resume after suspend fails on kernel >= 6.2
Summary: Resume after suspend fails on kernel >= 6.2
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 38
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2023-04-25 13:29 UTC by Mark Knoop
Modified: 2023-07-20 15:06 UTC (History)
19 users (show)

Fixed In Version:
Doc Type: ---
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: ---
Embargoed:


Attachments (Terms of Use)
Call trace after successful resume (44.71 KB, text/plain)
2023-04-25 13:30 UTC, Mark Knoop
no flags Details

Description Mark Knoop 2023-04-25 13:29:23 UTC
Dell XPS 13 (9350) laptop has been running Fedora since 2015 and never had any issues with suspend/resume. 

Beginning with kernel 6.2.8-200 on Fedora 37 there were frequent failures to resume after suspend. The first suspend-resume cycle after a reboot would often work, but subsequent attempts would fail. I tried to debug but without success and then did a clean install of Fedora 38.

The same problem occurred with kernels 6.2.9-300 and 6.2.11-300. One successful resume with this kernel generated a call trace which is attached. However this trace does not always appear.

I have installed older kernels from koji, the problem starts to appear with the first 6.2 kernel.

- 6.0.0-0.rc2.20220824gitc40e8341e3b3.23 working suspend-resume
- 6.1.0-0.rc8.20221209git0d1409e4ff08.62 working suspend-resume
- 6.2.0-0.rc2.18 resume fails after suspend


Reproducible: Sometimes

Steps to Reproduce:
1. Install a kernel version >= 6.2
2. Reboot, then suspend
3. Resume is successful ~50% of the time
4. Suspend again
5. Resume is almost never successful after two suspend cycles

Comment 1 Mark Knoop 2023-04-25 13:30:22 UTC
Created attachment 1959804 [details]
Call trace after successful resume

Comment 2 lukastymo 2023-07-20 15:06:59 UTC
Dell XPS 15 has precisely the same issue. The only difference is that I see the error almost every time I try to resume.

It happens for both s2idle and deep suspend. My reproducibility is almost 90%. Never two resumes within a day. 

I'm looking for a workaround, so far the below didn't help
- disable Bluetooth in BIOS
- switch to Nouveau
- switch to proprietary Nvidia drivers
- change s2idle -> deep

Steps to Reproduce and my observations:
- Suspend
- Wait a longer period (~1h)
- Press the keyboard on the laptop (nothing)
- Press the power button (nothing)
- Press many keys a couple of times (nothing, black screen)
- After 30 seconds of pressing keys, the CPU goes 100%, the laptop becomes very loud, like in some kind of intensive computation loop, and the whole laptop increases hot very quickly. All monitors stay off. I restart immediately to avoid overheating.
- It feels like the longer I wait on suspend, the less likely I will be able to resume. 

My specific setup which may affect the increase in reproducibility:
- 2 external monitors, 64GB RAM.

In previous Fedora/kernels s2idle worked fine, deep never. Now, deep works sometimes, but s2idle fails in 90% of cases.


Note You need to log in before you can comment on or make changes to this bug.