Yrurtj

I have a ThinkPad X220 running Fedora 23. All was good until yesterday when the machine did not wake up from suspend-to-RAM any more. Only holding the power button for several seconds would turn the machine off completely.

The journal ends with the following (journalctl -b-1):

Mär 20 09:07:01 martin-friese.fritz.box systemd[1]: Started Session 36 of user mu.

Mär 20 09:07:01 martin-friese.fritz.box systemd[1]: Starting Session 36 of user mu.

Mär 20 09:07:01 martin-friese.fritz.box audit[6412]: USER_START pid=6412 uid=0 auid=1000 ses=36 subj=system_u:system_r:crond_t:s0-s0:c0.c1023 msg='op=PAM:session_open grantors=pam_loginuid,pam_keyinit,pam_limits,pam_systemd acct="mu" exe="

Mär 20 09:07:01 martin-friese.fritz.box audit[6412]: CRED_REFR pid=6412 uid=0 auid=1000 ses=36 subj=system_u:system_r:crond_t:s0-s0:c0.c1023 msg='op=PAM:setcred grantors=pam_env,pam_unix acct="mu" exe="/usr/sbin/crond" hostname=? addr=? te

Mär 20 09:07:01 martin-friese.fritz.box CROND[6416]: (mu) CMD (/home/mu/bin/brightness --auto > /dev/null 2> /dev/null)

Mär 20 09:07:03 martin-friese.fritz.box audit[6412]: CRED_DISP pid=6412 uid=0 auid=1000 ses=36 subj=system_u:system_r:crond_t:s0-s0:c0.c1023 msg='op=PAM:setcred grantors=pam_env,pam_unix acct="mu" exe="/usr/sbin/crond" hostname=? addr=? te

Mär 20 09:07:03 martin-friese.fritz.box audit[6412]: USER_END pid=6412 uid=0 auid=1000 ses=36 subj=system_u:system_r:crond_t:s0-s0:c0.c1023 msg='op=PAM:session_close grantors=pam_loginuid,pam_keyinit,pam_limits,pam_systemd acct="mu" exe="/

Mär 20 09:07:38 martin-friese.fritz.box NetworkManager[1358]: <info>  sleep requested (sleeping: no  enabled: yes)

Mär 20 09:07:38 martin-friese.fritz.box NetworkManager[1358]: <info>  sleeping...

Mär 20 09:07:38 martin-friese.fritz.box NetworkManager[1358]: <info>  (wlp3s0): device state change: unavailable -> unmanaged (reason 'sleeping') [20 10 37]

Mär 20 09:07:38 martin-friese.fritz.box NetworkManager[1358]: <info>  NetworkManager state is now ASLEEP

Mär 20 09:07:38 martin-friese.fritz.box systemd[1]: Reached target Sleep.

Mär 20 09:07:38 martin-friese.fritz.box systemd[1]: Starting Sleep.

Mär 20 09:07:38 martin-friese.fritz.box systemd[1]: Starting Suspend...

Mär 20 09:07:38 martin-friese.fritz.box systemd-sleep[6516]: Suspending system...

The kernel that I run is 4.4.5-300.fc23.x86_64.

Perhaps it is due to this update:

[root@martin-friese mu]# env LC_ALL=C dnf history info 251

Transaction ID : 251

Begin time     : Fri Mar 18 14:50:13 2016

Begin rpmdb    : 4555:f742ed24f025e31a2cf17b39e7cbbaae3adede0e

End time       :            14:51:35 2016 (82 seconds)

End rpmdb      : 4554:3afdbed35e1c373fe7e000bc5d1e5258054c1c33

User           : System <unset>

Return-Code    : Success

Transaction performed with:

    Installed     dnf-1.1.7-2.fc23.noarch         @updates

    Installed     rpm-4.13.0-0.rc1.12.fc23.x86_64 @updates

Packages Altered:

    Erase    kernel-4.4.2-301.fc23.x86_64                               @updates

    Install  kernel-4.4.5-300.fc23.x86_64                               @updates

    Erase    kernel-core-4.4.2-301.fc23.x86_64                          @updates

    Install  kernel-core-4.4.5-300.fc23.x86_64                          @updates

    Erase    kernel-devel-4.4.2-301.fc23.x86_64                         @updates

    Install  kernel-devel-4.4.5-300.fc23.x86_64                         @updates

    Upgraded kernel-headers-4.4.4-301.fc23.x86_64                       @updates

    Upgrade                 4.4.5-300.fc23.x86_64                       @updates

    Erase    kernel-modules-4.4.2-301.fc23.x86_64                       @updates

    Install  kernel-modules-4.4.5-300.fc23.x86_64                       @updates

    Erase    kernel-modules-extra-4.4.2-301.fc23.x86_64                 @updates

    Install  kernel-modules-extra-4.4.5-300.fc23.x86_64                 @updates

    Erase    kmod-VirtualBox-4.4.2-301.fc23.x86_64-5.0.14-1.fc23.x86_64 @@commandline

    Upgraded libinput-1.2.1-4.fc23.x86_64                               @updates

    Upgrade           1.2.2-1.fc23.x86_64                               @updates

    Upgraded python-pygments-2.0.2-3.fc23.noarch                        @@commandline

    Upgrade                  2.1.3-1.fc23.noarch                        @updates

    Upgraded python3-pygments-2.0.2-3.fc23.noarch                       @@commandline

    Upgrade                   2.1.3-1.fc23.noarch                       @updates

    Upgrade  qt-1:4.8.7-12.fc23.x86_64                                  @updates

    Upgraded qt-1:4.8.7-5.fc23.x86_64                                   @updates

    Upgrade  qt-common-1:4.8.7-12.fc23.noarch                           @updates

    Upgraded qt-common-1:4.8.7-5.fc23.noarch                            @updates

    Upgrade  qt-devel-1:4.8.7-12.fc23.x86_64                            @updates

    Upgraded qt-devel-1:4.8.7-5.fc23.x86_64                             @updates

    Upgrade  qt-mysql-1:4.8.7-12.fc23.x86_64                            @updates

    Upgraded qt-mysql-1:4.8.7-5.fc23.x86_64                             @updates

    Upgrade  qt-x11-1:4.8.7-12.fc23.x86_64                              @updates

    Upgraded qt-x11-1:4.8.7-5.fc23.x86_64                               @updates

Old kernels did not help, either. I just tried 4.4.4 and 4.4.3, which have been working just fine in the days before. The update to the 4.4.5 has been Friday afternoon. Then I have started the laptop with the new kernel on Saturday afternoon and first suspended it in the evening, I think. Therefore it might very well be the 4.4.5 kernel.

However, as old kernels have the same effect, I assume that it is something with the hardware or something else. I'll try to boot from a Live USB with some very different version (say CentOS) and try that.

Waiting for a little while after waking the machine, it will try to start the fan (one can hear that) and it flashes all the lights. A short video and a longer video show the strange light-show.

Update 1

I just booted with Kubuntu 15.10 from the USB. It wakes up after suspend, but the screen is black and the wireless is not turned on again. Something is off there as well and the machine worked with Kubuntu 15.10 before.

Update 2

Arch Linux 2016.03.01 with Kernel 4.4.1 exhibits the same problem. I started the live session and used systemctl suspend. The system would go to sleep and not wake up again. I saw the same lightshow as before.

Is this a hardware defect?

Update 3

When digging in the UEFI to see whether I could change something there, I noticed that I cannot save changes there any more. I got the following error, then it froze in the UEFI:

I also tried to reset the UEFI to defaults, but that did not work either:

Another new error message between the “ThinkPad”-Splash and the GRUB is this one here:

A friend of mine suggested to update the UEFI, it could not really get worse than this odd-behaving UEFI. So we tried putting the ISO on an USB stick, which did not worked. Then we tried a DVD, which did not work either. We tried the GRUB method. All this did not work as my UEFI is locked in the “UEFI only” boot mode, whereas the Lenovo UEFI updater is a 16-bit DOS which only boots via legacy mode. Luckily (?) he had a HDD with Windows 7 on it, so we just flashed the UEFI using Windows. shrugg

After that, I would not get the error messages any more, the UEFI would still freeze after saving the data. The suspend issue remains, it still does not wake up.

We concluded that it might not be any of the software but really the UEFI itself that has a problem and therefore it would be possible that the part for waking-up is somehow broken.

It sounds like you are experiencing this on the first suspend attempt after a reboot. That differs from what just started for me, but otherwise very similar.

At first I thought mine was sporadic but now I realize it is a second suspend that shows the issue. It seems to match this report:

https://www.reddit.com/r/Fedora/comments/44mk4m/suspend_issues_after_upgrade_to_43_kernel/

That post notes that suspend to RAM will work once after a reboot and then fail the next time which is what I am seeing.

I am on a fully patched Fedora 23 64bit desktop, using "systemctl suspend" each night to save some electricity since I no longer run any services that require 24/7 operation.