Created attachment 1876330 [details]
journalctl --no-hostname -k > dmesg.txt
1. Please describe the problem:
Cannot wake from sleep with laptop internal keyboard and power button.
But can wake from sleep by plugging or unplugging the power cable.
2. What is the Version-Release number of the kernel:
3. Did it work previously in Fedora? If so, what kernel version did the issue
*first* appear? Old kernels are available for download at
Yes, it did work. I don't remember exactly when this issue starts happening.
4. Can you reproduce this issue? If so, please provide the steps to reproduce
the issue below:
It produces every time.
First, suspend the machine, either by `Suspend` button in the GNOME UI, or by `systemctl suspend`.
Second, try to wake. Keyboard and power button don't work, and the power light is still flashing.
But plugging or unplugging the power cable can wake the machine normally.
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``:
Sorry, I'm not able to test that.
6. Are you running any modules that not shipped with directly Fedora's kernel?:
Perhaps no. I don't have nvidia.
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.
And I think these things may help:
# cat /proc/acpi/wakeup
Device S-state Status Sysfs node
GPP0 S4 *disabled
GPP1 S4 *disabled
GP17 S4 *enabled pci:0000:00:08.1
I tested an earlier version kernel. Kernel 5.16.18-200.fc35.x86_64 doesn't have this issue.
I have experienced the same issue.
I'm on a ThinkPad T14 Gen 2a
For me the issue did not occur with kernel 5.16.19-200.fc35 and began occuring with 5.17.4-200.fc35
It does not occur with the latest rawhide kernel 5.18.0-0.rc4.20220429git38d741cb70b3074.37.fc37
I also tested some kernels from the kernel-vanilla-fedora repo, and experienced the issue with vmlinuz-5.17.4-250.vanilla.1.fc35 but not with vmlinuz-5.17.5-250.vanilla.1.fc35
It seems likely, based on this, that this is an upstream regression in 5.17 that has a fix in 5.18 and 5.17.5