Bug 1730136 - unable to successfully suspend (Thinkpad X1 carbon)
Summary: unable to successfully suspend (Thinkpad X1 carbon)
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: rawhide
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2019-07-16 00:03 UTC by Joel Diaz
Modified: 2019-07-16 00:03 UTC (History)
16 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed:

Attachments (Terms of Use)
boot log (with rawhide kernel) (162.27 KB, text/plain)
2019-07-16 00:03 UTC, Joel Diaz
no flags Details

Description Joel Diaz 2019-07-16 00:03:45 UTC
Created attachment 1590924 [details]
boot log (with rawhide kernel)

1. Please describe the problem:
Cannot put Thinkpad X1 Carbon to sleep.

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
   https://koji.fedoraproject.org/koji/packageinfo?packageID=8 :
Unsure. Has been happening for a while (originally thought it was related to undocking, but it turns out it happens without coming near the dock).

4. Can you reproduce this issue? If so, please provide the steps to reproduce
   the issue below:
Boot. Login (Gnome Wayland). Close lid. Initially looks like it succeeds (red light throbs on/off), but then the light comes on solid.

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``:
Yes. Failed on rawhide: kernel-core-5.3.0-0.rc0.git3.1.fc31.x86_64

(also, the command to install rawhide turns out to need '--releasever 31' added as a parameter...)

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

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.

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