ThinkPad X220 with Fedora 23 does not wake up any more
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.
suspend
asked Mar 20 '16 at 13:49
Martin UedingMartin Ueding
1,33511229
bumped to the homepage by Community♦ 21 mins ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
add a comment |
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.
suspend
asked Mar 20 '16 at 13:49
Martin UedingMartin Ueding
1,33511229
bumped to the homepage by Community♦ 21 mins ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
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.
– Gilles
Mar 20 '16 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 withtp-acpion 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.
– Martin Ueding
Mar 21 '16 at 20:22
If that's the only obstacle, you could runtp-acpifrom 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).
– Gilles
Mar 21 '16 at 20:29
add a comment |
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.
suspend
asked Mar 20 '16 at 13:49
Martin UedingMartin Ueding
1,33511229
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.
suspend
suspend
asked Mar 20 '16 at 13:49
Martin UedingMartin Ueding
1,33511229
asked Mar 20 '16 at 13:49
Martin UedingMartin Ueding
1,33511229
edited Mar 21 '16 at 20:21
Martin Ueding
asked Mar 20 '16 at 13:49
Martin UedingMartin Ueding
1,33511229
asked Mar 20 '16 at 13:49
Martin UedingMartin Ueding
1,33511229
asked Mar 20 '16 at 13:49
Martin UedingMartin Ueding
1,33511229
1,33511229
bumped to the homepage by Community♦ 21 mins ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
bumped to the homepage by Community♦ 21 mins ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
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.
– Gilles
Mar 20 '16 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 withtp-acpion 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.
– Martin Ueding
Mar 21 '16 at 20:22
If that's the only obstacle, you could runtp-acpifrom 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).
– Gilles
Mar 21 '16 at 20:29
add a comment |
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.
– Gilles
Mar 20 '16 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 withtp-acpion 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.
– Martin Ueding
Mar 21 '16 at 20:22
If that's the only obstacle, you could runtp-acpifrom 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).
– Gilles
Mar 21 '16 at 20:29
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.
– Gilles
Mar 20 '16 at 18:16
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.
– Gilles
Mar 20 '16 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.– Martin Ueding
Mar 21 '16 at 20:22
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.– Martin Ueding
Mar 21 '16 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).– Gilles
Mar 21 '16 at 20:29
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).– Gilles
Mar 21 '16 at 20:29
add a comment |
1 Answer
1
active
oldest
votes
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.
answered Mar 21 '16 at 20:00
DougDoug
11
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.
– Martin Ueding
Mar 21 '16 at 20:11
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f271045%2fthinkpad-x220-with-fedora-23-does-not-wake-up-any-more%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
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.
answered Mar 21 '16 at 20:00
DougDoug
11
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.
– Martin Ueding
Mar 21 '16 at 20:11
add a comment |
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.
answered Mar 21 '16 at 20:00
DougDoug
11
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.
– Martin Ueding
Mar 21 '16 at 20:11
add a comment |
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.
answered Mar 21 '16 at 20:00
DougDoug
11
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.
answered Mar 21 '16 at 20:00
DougDoug
11
answered Mar 21 '16 at 20:00
DougDoug
11
answered Mar 21 '16 at 20:00
DougDoug
11
answered Mar 21 '16 at 20:00
DougDoug
11
11
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.
– Martin Ueding
Mar 21 '16 at 20:11
add a comment |
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.
– Martin Ueding
Mar 21 '16 at 20:11
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.
– Martin Ueding
Mar 21 '16 at 20:11
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.
– Martin Ueding
Mar 21 '16 at 20:11
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f271045%2fthinkpad-x220-with-fedora-23-does-not-wake-up-any-more%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
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.
– Gilles
Mar 20 '16 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-acpion 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.– Martin Ueding
Mar 21 '16 at 20:22
If that's the only obstacle, you could run
tp-acpifrom 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).– Gilles
Mar 21 '16 at 20:29