1

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:

enter image description here

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

enter image description here

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

enter image description 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.

Improve this question
3
  • If software that worked before no longer does, that's surely a hardware issue... But do try unplugging the computer and removing the battery, wait a few minutes, then plug them back. I've had problems with laptops where the firmware was buggy and left something in a bad state that a mere power off didn't fix. Commented Mar 20, 2016 at 18:16
  • Taking the battery out sounds like a good thing. I am reluctant to do this as this would reset the charge-levels I have set with tp-acpi on Ubuntu. It is not packaged in Fedora, so I cannot change the charge levels back to my 80%/85% I currently have. Therefore I would really like to leave the battery until I have packaged that. Commented Mar 21, 2016 at 20:22
  • If that's the only obstacle, you could run tp-acpi from an Ubuntu live CD/USB. You may even be able to run that program under Fedora (it depends whether the tool requires a kernel version or option that Fedora doesn't have). Commented Mar 21, 2016 at 20:29

1 Answer 1

Reset to default
0

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.

Improve this answer
1
  • Thanks for the Reddit link, I posted my two cents there as well. I think that issue is not the same as my one does not wake up whereas the issue you describe happens on the second suspend. There are also some really weird issues in the UEFI, I will update my post above. Commented Mar 21, 2016 at 20:11

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.