Bug 1262034 - Thinkpad X201t randomly fails to suspend, resume, or sometimes just shuts off
Thinkpad X201t randomly fails to suspend, resume, or sometimes just shuts off
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
23
x86_64 Linux
unspecified Severity high
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-09-10 12:30 EDT by Jean-François Fortin Tam
Modified: 2016-12-05 08:21 EST (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-10-26 12:50:26 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
journalctl output (83.49 KB, text/plain)
2015-09-10 12:31 EDT, Jean-François Fortin Tam
no flags Details
lspci output (23.86 KB, text/plain)
2015-09-10 12:32 EDT, Jean-François Fortin Tam
no flags Details
lsmod (3.98 KB, text/plain)
2015-09-17 23:30 EDT, Jean-François Fortin Tam
no flags Details
dmesg output on boot after a failed resume (69.87 KB, text/plain)
2015-09-17 23:32 EDT, Jean-François Fortin Tam
no flags Details
Full journal of f23 resume crash (1.38 MB, text/x-vhdl)
2015-11-11 03:28 EST, Marcel Ziswiler
no flags Details

  None (edit)
Description Jean-François Fortin Tam 2015-09-10 12:30:14 EDT
I'm really puzzled by this... starting around July 2015 up to this day (I think coinciding with kernel 4.1.x in F22?) my Thinkpad X201t is very unreliable when it comes to suspend/resume. It might go for days/weeks without problems, and then become real unreliable when it comes to suspend/resume.

Current symptoms when suspending either from the lid or pressing fn+F4:

- Sometimes it might go to suspend mode but "not really": the crescent moon suspend LED on the laptop will light up, but the various other power LEDs will not shut off, and the fan will still be spinning. Any attempt to wake the laptop (opening the lid, pressing the fn key) will fail. Requires a hard poweroff.

- Sometimes it will go fully to suspend mode but refuse to wake. Requires a hard poweroff

- Rarely, instead of suspending it will just shut off entirely.



More info:
- There have been no BIOS upgrades in the past few years, so no changes on that front.
- The battery is mostly dead, but the issue also occurs without the battery, so that's not the cause.
- This is without a docking station involved.
- It worked fine with previous Fedora releases, maybe once every few months I might get an issue where the laptop wouldn't go to sleep or wake, but it was infrequent enough that I could live with it. Now it's so frequent that suspend/resume is completely unusuable because I cannot trust it.
- Intel graphics, Intel wifi, lspci attached.
- journalctl log of the past hour attached, in case you can spot something

I'd say that about 1 in 3 suspend/resumes fail for me right now.
Comment 1 Jean-François Fortin Tam 2015-09-10 12:31:50 EDT
Created attachment 1072276 [details]
journalctl output
Comment 2 Jean-François Fortin Tam 2015-09-10 12:32:44 EDT
Created attachment 1072277 [details]
lspci output
Comment 3 Jean-François Fortin Tam 2015-09-10 12:59:04 EDT
Also of note: this happens with kernels 4.1.6 as well as 4.1.4 and 4.1.3 (the only ones available/installed on my machine, somehow older kernels got pruned)
Comment 4 Erich Cordoba 2015-09-10 23:33:09 EDT
Could you please attach the dmesg output?.  Also the output of lsmod command would be useful to understand the issue.
Comment 5 Jean-François Fortin Tam 2015-09-17 23:30:24 EDT
Here is the current dmesg.txt and lsmod output on a fresh boot after a resume failure (screen black, LEDs on, machine locked up) that required me to do a hard poweroff.

Here is also the tail of journalctl -b -1, where you see that the system suspended (some hours ago) but never resumed or shut down cleanly:

sep 17 13:28:30 my_laptop systemd[1]: Reached target Sleep.
sep 17 13:28:30 my_laptop systemd[1]: Starting Sleep.
sep 17 13:28:30 my_laptop systemd[1]: Starting Suspend...
sep 17 13:28:30 my_laptop systemd-sleep[4643]: Suspending system...
Comment 6 Jean-François Fortin Tam 2015-09-17 23:30:50 EDT
Created attachment 1074671 [details]
lsmod
Comment 7 Jean-François Fortin Tam 2015-09-17 23:32:01 EDT
Created attachment 1074672 [details]
dmesg output on boot after a failed resume
Comment 8 Justin M. Forbes 2015-10-20 15:29:53 EDT
*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 22 kernel bugs.

Fedora 22 has now been rebased to 4.2.3-200.fc22.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you have moved on to Fedora 23, and are still experiencing this issue, please change the version to Fedora 23.

If you experience different issues, please open a new bug report for those.
Comment 9 Jean-François Fortin Tam 2015-11-03 23:51:51 EST
Still happens with Fedora 23 and the latest available kernel (just like it did on F22 with the latest 4.2.3 kernel).

Eric, any ideas?
Comment 10 Marcel Ziswiler 2015-11-11 03:28 EST
Created attachment 1092596 [details]
Full journal of f23 resume crash
Comment 11 Marcel Ziswiler 2015-11-11 03:33:41 EST
T440s in an Ultra Dock with a HDMI screen. Suspended yesterday evening Nov 10 16:59:49 and resumed this morning Nov 11 08:43:58. As usual the external screen did not come to live so I opened the notebook screen. USB mouse was working, not so the USB keyboard. Un-plugged/re-plugged both after which no more reaction whatsoever, see below in above attached log:

Nov 11 08:43:58 localhost.localdomain kernel: usb 1-3: USB disconnect, device number 2
Nov 11 08:43:58 localhost.localdomain kernel: usb 1-3.4: USB disconnect, device number 4

Had to hard power-cycle to get it back to life!

Unfortunately I admit the log does not seem to reveal much anything really.
Comment 12 Sam Tygier 2016-04-29 17:44:15 EDT
Does reverting to an older kernel help? I had similar-ish issues last year on an x230 that turned out to be a hardware failure. can you reproduce with an F21 live image?
Comment 13 Jean-François Fortin Tam 2016-06-02 12:11:09 EDT
Hi Sam, I can attest to the fact that older kernels are reliable. At least if booting 3.10.0-327 on Centos7 is any indication. I can suspend/resume dozens of times without any problems.

Really, the issue started occuring with the 4.x series for me, sporadically, since Summer 2015. Depending on the kernel release it might be more, or less, prominent. Currently, and for the past two months or so with any kernel provided by Fedora 23, I've had it fail to suspend or resume with about 30-50% probability. To the point I don't even carry the battery anymore, forcing myself to do a full poweroff because the suspend/resume can't be trusted for anything.
Comment 14 Laura Abbott 2016-09-23 15:38:08 EDT
*********** MASS BUG UPDATE **************
 
We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 23 kernel bugs.
 
Fedora 23 has now been rebased to 4.7.4-100.fc23.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.
 
If you have moved on to Fedora 24 or 25, and are still experiencing this issue, please change the version to Fedora 24 or 25.
 
If you experience different issues, please open a new bug report for those.
Comment 15 Laura Abbott 2016-10-26 12:50:26 EDT
*********** MASS BUG UPDATE **************
This bug is being closed with INSUFFICIENT_DATA as there has not been a response in 4 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.

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