Bug 1059924 - Sony Vaio Duo 11: suspend to ram broken [NEEDINFO]
Summary: Sony Vaio Duo 11: suspend to ram broken
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 20
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-01-31 00:27 UTC by Stephan Mueller
Modified: 2014-12-10 15:00 UTC (History)
14 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2014-12-10 15:00:26 UTC
Type: Bug
Embargoed:
jforbes: needinfo?


Attachments (Terms of Use)
journalctl debug output around failed suspend (3.48 KB, text/x-vhdl)
2014-03-03 14:22 UTC, Stephan Mueller
no flags Details

Description Stephan Mueller 2014-01-31 00:27:25 UTC
Description of problem:

When using the KDE Suspend mechanism, the systemd-sleep is triggered eventually. When having no network connection, this suspend-sleep invocation either at the first but at least wit the 2nd invocation does not put the system into sleep (i.e it is possible that the first invocation of suspend-sleep after a reboot succeeds and suspends the system, but at least with the second suspend, system is not shut down).

When having network connections, the suspend-sleep will work a bit longer, i.e. the suspend will succeed more often. But after some suspend/resume cycles, again, the suspend does not succeed.

Suspending the system "manually" with either pm-suspend or echo mem > /sys/power/state works reliably (i.e. 10 suspends in a row worked). Also, invoking /lib/systemd/systemd-sleep suspend works reliably.

The result in a failed suspend means that the system somehow is alive -- the screen is dark, the keyboard illumination is dark, but the LEDs indicating the system status show that the system is still powered. Pressing any key or the power button does not revive the system. Only pressing the power button for 4 secs works to shut off the system. I even waited for 30 minutes for the suspend to be performed, but the LEDs indicate that the power is still on.

In the journal, when the suspend did not succeed, the last message before the kernel reboot messages is "Suspending system..." from systemd-sleep.

There is no /etc/systemd/sleep.conf file. Though, I tried to configure platform or suspend with SuspendMode individually without any improvement.

Note, suspend to disk works flawless.

Version-Release number of selected component (if applicable):
F20
208-9

How reproducible:
Without network: at least the 2nd suspend does not work
With network: maybe after the 5th or 6th suspend at most, suspend does not work

Steps to Reproduce:
1. Suspend the system

Actual results:
System is not powered down to suspend mode

Expected results:
System is suspended

Comment 1 Lennart Poettering 2014-02-23 15:47:53 UTC
Please boot the system with "systemd.log_level=debug" and then paste the journalctl output around such a failed suspend attempt.

Comment 2 Stephan Mueller 2014-03-03 14:22:26 UTC
Created attachment 869941 [details]
journalctl debug output around failed suspend

Comment 3 Lennart Poettering 2014-06-17 00:54:35 UTC
Everything looks alright from systemd's side. Appears to be kernel problem. Reassigning.

Comment 4 Justin M. Forbes 2014-11-13 16:00:35 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.17.2-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 have moved on to Fedora 21, and are still experiencing this issue, please change the version to Fedora 21.

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

Comment 5 Justin M. Forbes 2014-12-10 15:00:26 UTC
This bug is being closed with INSUFFICIENT_DATA as there has not been a response in over 3 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.