Bug 1046593 - System freeze on resume/suspend
Summary: System freeze on resume/suspend
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 20
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-12-26 09:03 UTC by Loïc Favory
Modified: 2014-06-18 14:10 UTC (History)
11 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2014-06-18 14:10:39 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
Output from lspci -vvv (10.52 KB, text/plain)
2014-01-10 11:45 UTC, Mikkel Lauritsen
no flags Details
Output from dmidecode (13.64 KB, text/plain)
2014-01-10 11:46 UTC, Mikkel Lauritsen
no flags Details
lspci output (10.60 KB, text/plain)
2014-01-18 14:13 UTC, Jesper Sørensen
no flags Details
dmidecode output (13.67 KB, text/plain)
2014-01-18 14:14 UTC, Jesper Sørensen
no flags Details

Description Loïc Favory 2013-12-26 09:03:23 UTC
Description of problem:
Since Fedora 20 update, my laptop can't resume after suspend.
On resume, the waiting screen of GDM appears with animated arrows in the bottom of the screen but after 2~3 seconds, no more animations and my mouse is not working. I don't have keyboard leds, but my keyboard doesn't seem to work anymore.
I can't access anymore to my laptop with ssh.
If I'm fast enough, I can identify and access gnome-shell, but after 1~2  seconds, my laptop freeze with the same symptoms : no more mouse, no more keyboards & no more ssh access.

Version-Release number of selected component (if applicable):
Fedora 20

$ uname -r
3.12.5-302.fc20.x86_64


How reproducible:

Steps to Reproduce:
1. Click on suspend in gnome shell or close my laptop screen.
2. Wake my laptop to resume, wait 2~3 seconds and my laptop freeze
3.

Actual results:
Laptop freezed

Expected results:
Laptop awaked

Comment 1 Michele Baldessari 2013-12-26 19:46:38 UTC
Hi,

hard to say without more data. Would you be able to collect a crash dump
when this happens?

https://fedoraproject.org/wiki/How_to_use_kdump_to_debug_kernel_crashes

If after the resume you quickly switch to a console tty (Ctrl-Alt-F3 for example)
do you see any messages there?

Thanks,
Michele

Comment 2 Loïc Favory 2013-12-30 09:31:09 UTC
(In reply to Michele Baldessari from comment #1)
> Hi,
> 
> Would you be able to collect a crash dump
> when this happens?
> 
> https://fedoraproject.org/wiki/How_to_use_kdump_to_debug_kernel_crashes
> 
> If after the resume you quickly switch to a console tty (Ctrl-Alt-F3 for
> example)
> do you see any messages there?
> 
> Thanks,
> Michele

Hi,

I followed the How To, but the /var/crash directory is empty.
I'll try to change config to write on a shared directory over network.
May be I did something wrong, it's the first I try tu use kdump.

I can't switch to tty, laptop freeze on keydown.

If the session is just locked (without suspend), everything work fine.
But on suspend, the laptop can't wake up normally.

Thanks for you help,
Loïc.

Comment 3 Michele Baldessari 2014-01-01 18:04:35 UTC
Hi Loïc,

having a working kdump is always a good thing as it can help
in other circumstances as well. Don't forget you can test if it is working
or not without waiting for the resume hang ;)

Without more infos it'll be hard. I'll see if other users have resume issues
and see if they could be relevant here. Can you also upload the output of
"lspci -vvv" and "dmidecode" as a file to this BZ so that we have a bit of an
idea of what system this is?

Thanks,
Michele

Comment 4 Mikkel Lauritsen 2014-01-10 11:45:24 UTC
Created attachment 848139 [details]
Output from lspci -vvv

Comment 5 Mikkel Lauritsen 2014-01-10 11:46:00 UTC
Created attachment 848140 [details]
Output from dmidecode

Comment 6 Mikkel Lauritsen 2014-01-10 11:46:28 UTC
I have what appears to be the exact same problem - when resuming after suspend neither mouse nor keyboard works, the animated arrows are shown once and the machine is otherwise completely unresponsive. The logs show absolutely nothing; no output at all.

In my case the problem appeared before the upgrade to F20, so the regression has happened at version before that installed by F20.

Output from lspci -vvv and dmidecode has been attached.

Comment 7 Mikkel Lauritsen 2014-01-15 14:54:57 UTC
The recent update to 3.12.7-300 hasn't made any difference; it still hangs when resuming. The fan starts spinning after a couple of seconds which could indicate some kind of livelock?

The part of /var/log/messages covering suspend and resume is as follows:

Jan 15 15:46:47 localhost systemd: Starting Sleep.
Jan 15 15:46:47 localhost systemd: Reached target Sleep.
Jan 15 15:46:47 localhost systemd: Starting Suspend...
Jan 15 15:46:47 localhost systemd-sleep: Suspending system...
Jan 15 15:47:23 localhost systemd: Time has been changed
Jan 15 15:47:23 localhost systemd-logind: Lid opened.
Jan 15 15:47:23 localhost systemd: Time has been changed
Jan 15 15:47:23 localhost systemd: Time has been changed
Jan 15 15:47:24 localhost systemd-sleep: System resumed.
Jan 15 15:47:24 localhost systemd: Started Suspend.
Jan 15 15:47:24 localhost systemd: Service sleep.target is not needed anymore. Stopping.
Jan 15 15:47:24 localhost systemd: Stopping Sleep.
Jan 15 15:47:24 localhost systemd: Stopped target Sleep.
Jan 15 15:47:24 localhost systemd: Starting Suspend.
Jan 15 15:47:24 localhost systemd: Reached target Suspend.
Jan 15 15:47:24 localhost systemd-logind: Operation finished.
Jan 15 15:47:24 localhost NetworkManager[746]: <info> wake requested (sleeping: yes  enabled: yes)
Jan 15 15:47:24 localhost NetworkManager[746]: <info> waking up and re-enabling...
Jan 15 15:47:24 localhost NetworkManager[746]: <info> WWAN now enabled by management service
Jan 15 15:47:24 localhost NetworkManager[746]: <info> (p3p1): device state change: unmanaged -> unavailable (reason 'managed') [10 20 2]
Jan 15 15:47:24 localhost NetworkManager[746]: <info> (p3p1): bringing up device.
Jan 15 15:47:24 localhost NetworkManager[746]: <info> NetworkManager state is now DISCONNECTED
Jan 15 15:47:24 localhost NetworkManager[746]: <info> (wlp2s0): device state change: unmanaged -> unavailable (reason 'managed') [10 20 2]
Jan 15 15:47:24 localhost NetworkManager[746]: <info> (wlp2s0): bringing up device.
Jan 15 15:48:28 localhost systemd[1]: systemd 208 running in system mode. (+PAM +LIBWRAP +AUDIT +SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ)
Jan 15 15:48:28 localhost systemd[1]: Running in initial RAM disk.
Jan 15 15:48:28 localhost systemd[1]: Set hostname to <localhost.localdomain>.

Comment 8 Jesper Sørensen 2014-01-18 14:07:55 UTC
I believe I'm experiencing this issue as well.

I'm not running fedora 20 though, but the bug seems to be directly connected to the kernel version and not the fedora version.

I have no issues when running a pre 3.12-kernel:
3.11.10-200.fc19.x86_64

But when I use one of the latest 3.12-kernels both suspend and hibernation are broken, below are the version I have tested on my system:
3.12.6-200.fc19.x86_64
3.12.7-200.fc19.x86_64

Also, the same issue seems to be affecting arch users and ubuntu users as well:
https://bbs.archlinux.org/viewtopic.php?pid=1363702
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1247654

Comment 9 Jesper Sørensen 2014-01-18 14:13:19 UTC
Created attachment 852000 [details]
lspci output

Comment 10 Jesper Sørensen 2014-01-18 14:14:37 UTC
Created attachment 852001 [details]
dmidecode output

Comment 11 Mikkel Lauritsen 2014-01-20 08:04:47 UTC
As a data point, the arch issue listed above mentions that the problem has been seen on machines from Clevo (OEM'ed as System76 or Sager). Mine is a Clevo as well - output from inxi -M :

Machine:   Mobo: CLEVO model: W55xEU version: D02 Bios: American Megatrends version: 4.6.5 date: 11/02/2012

Comment 12 Carlos Vassalo 2014-01-20 08:34:57 UTC
Same problem with an ASUS :

Machine:   Mobo: ASUSTeK model: UX32VD version: 1.0 serial: xxxxxxxxxxxxxx
           Bios: American Megatrends version: UX32VD.214 date: 01/29/2013

Comment 13 Mikkel Lauritsen 2014-01-20 08:47:40 UTC
I have just upgraded to 3.12.8-300.fc20.x86_64 , and so far the problem seems to have been fixed - I've been able to succesfully resume from suspend.

Comment 14 Carlos Vassalo 2014-01-20 09:58:30 UTC
I update the kernel to this version and the problem is still there.

Comment 15 Jesper Sørensen 2014-01-20 10:12:12 UTC
My machine is also from Clevo:
Machine:   Mobo: CLEVO model: W55xEU version: D02 Bios: American Megatrends version: 4.6.5 date: 11/02/2012

As soon as I get the time I will try updating the kernel, and report back if it fixes the problem.

Comment 16 Jesper Sørensen 2014-01-21 12:56:48 UTC
I have now updated my kernel to 3.12.8-200.fc19.x86_64, and standby and hibernation now works again on my machine.

Comment 17 Justin M. Forbes 2014-02-24 13:55:29 UTC
*********** 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 20 kernel bugs.

Fedora 20 has now been rebased to 3.13.4-200.fc20.  Please test this kernel update and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you experience different issues, please open a new bug report for those.

Comment 18 Mikkel Lauritsen 2014-02-25 10:32:29 UTC
Still works for me - as mentioned in comment 13 it started working again in 3.12.8-300

Comment 19 Justin M. Forbes 2014-05-21 19:38:43 UTC
*********** 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 20 kernel bugs.

Fedora 20 has now been rebased to 3.14.4-200.fc20.  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 experience different issues, please open a new bug report for those.


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