Bug 1912061 - Resume failure on 5.10.4-200.fc33 kernel
Summary: Resume failure on 5.10.4-200.fc33 kernel
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 33
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-01-03 05:51 UTC by Robert Hancock
Modified: 2021-01-12 02:56 UTC (History)
18 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-01-12 02:56:15 UTC
Type: Bug


Attachments (Terms of Use)
dmesg from normal bootup (107.26 KB, text/plain)
2021-01-03 05:54 UTC, Robert Hancock
no flags Details

Description Robert Hancock 2021-01-03 05:51:53 UTC
1. Please describe the problem:

System fails to resume from suspend on kernel 5.10.4. Monitors wake up but have a blank display and no input response or disk activity.

2. What is the Version-Release number of the kernel:

5.10.4-200.fc33.x86_64 (from https://koji.fedoraproject.org/koji/buildinfo?buildID=1663265)

3. Did it work previously in Fedora? If so, what kernel version did the issue
   *first* appear?  Old kernels are available for download at
   https://koji.fedoraproject.org/koji/packageinfo?packageID=8 :

Worked in 5.9.16-200.fc33.x86_64

4. Can you reproduce this issue? If so, please provide the steps to reproduce
   the issue below:

Yes - just suspend and try to resume on this system (Asus PRIME H270-PRO motherboard, Core i5-7500 CPU)

5. Does this problem occur with the latest Rawhide kernel? To install the
   Rawhide kernel, run ``sudo dnf install fedora-repos-rawhide`` followed by
   ``sudo dnf update --enablerepo=rawhide kernel``:

n/a - 5.10 kernel test

6. Are you running any modules that not shipped with directly Fedora's kernel?:

No

7. Please attach the kernel logs. You can get the complete kernel log
   for a boot with ``journalctl --no-hostname -k > dmesg.txt``. If the
   issue occurred on a previous boot, use the journalctl ``-b`` flag.

Used "echo 1 > /sys/power/pm_trace" prior to suspending. After failed resume and reset into the same kernel, saw this:

Dec 07 18:00:00 haswell kernel: PM:   Magic number: 0:161:320
Dec 07 18:00:00 haswell kernel: platform microcode: hash matches
Dec 07 18:00:00 haswell kernel: tty tty45: hash matches

The microcode driver seems like a possible culprit.

Will attach kernel log from normal boot with this kernel.

Comment 1 Robert Hancock 2021-01-03 05:54:08 UTC
Created attachment 1743984 [details]
dmesg from normal bootup

Comment 2 Masami Ichikawa 2021-01-05 13:09:55 UTC
I have same issue with i7-9700K(UHD Graphics 630), ASRock Z390 Extreme4 baseboard.
5.9.16-200.fc33.x86_64 works fine.

Comment 3 Masami Ichikawa 2021-01-10 00:44:36 UTC
I confirmed that linux 5.10.6 fixed this issue.

This patch fixed this issue. https://github.com/torvalds/linux/commit/3d5c5fdcee0f9a94deb0472e594706018b00aa31

Comment 4 Robert Hancock 2021-01-12 02:56:15 UTC
Not seeing this problem anymore with kernel-5.10.6-200.fc33.x86_64 but I have also since upgraded to discrete graphics so I'm not testing the exact same config. However, it sounds like this is resolved from comments above.


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