Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1060790 - undesired wakeup after suspend due to lid close [NEEDINFO]
Summary: undesired wakeup after suspend due to lid close
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 20
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2014-02-03 15:54 UTC by Peter F. Patel-Schneider
Modified: 2014-06-23 14:49 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2014-06-23 14:49:41 UTC
jforbes: needinfo?

Attachments (Terms of Use)
system log extracts under various conditions (deleted)
2014-02-03 15:55 UTC, Peter F. Patel-Schneider
no flags Details

Description Peter F. Patel-Schneider 2014-02-03 15:54:43 UTC
Description of problem:

On my laptop, a Lenovo Yoga 2 Pro running Fedora 20 with XFCE, something is
causing the machine to wake up just after a lid close suspend.  

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

Kernel:  3.12.8-300.fc20.x86_64
Systemd: 208-9.fc20

How reproducible:

This is
happening quite often, but not all the time.  Other people have informally
reported the same symptoms.  I have seen the bogus wakeups when Wi-Fi is
enabled but no connection is active, when Wi-Fi is disabled, and when
NetworkManager is not running.   If bogus wakeups happen with an active
connection, they happen much less often.

Steps to Reproduce:
1.  Close lid (with no active Wi-Fi connection)

Actual results:

System suspends, then quickly wakes up again, probably due to some Wi-Fi activity. 

Expected results:

System stays suspended until lid open.

Additional info:

I grabbed several extracts from the system log for suspend due to a
lid-close event and a few for suspend from the menu.  They are attached to
this report.

It appears that something during the lid-close suspend is causing
NetworkManager to turn on the Wi-Fi which then appears to be waking up the
machine.  I would have blamed NetworkManager, but I tried suspending after
killing NetworkManager.  A lid-close suspend without NetworkManager running
causes NetworkManager to be activated, whereas a menu suspend does not.

This indicates to me that the problem is somewhere in systemd, maybe in the
systemd scripts, so I am assigning this bug to systemd.

There are several other bugs related to suspend problems, but this appears to be different, even though I have heard others complaining about the same problem.

Comment 1 Peter F. Patel-Schneider 2014-02-03 15:55:52 UTC
Created attachment 858668 [details]
system log extracts under various conditions

Comment 2 Lennart Poettering 2014-02-23 15:33:15 UTC
Hmm? systemd has no control over what causes resumes from suspend. This sounds like a hardware (BIOS) bug, or maybe kernel bug, but systemd certainly not.

Comment 3 Peter F. Patel-Schneider 2014-02-23 17:44:33 UTC
OK.  I'll dig further.

Comment 4 Peter F. Patel-Schneider 2014-02-23 21:01:06 UTC
The resumes may be due to USB activity.  At least there is the claim that turning off wakeup-on-activity for the USB hubs prevents the result. is one place where this claim is made, and I haven't had the inadvertent wakeups since I put this fix in place.

Anyway, is there any way to determine the cause of a wakeup?

Comment 5 Peter F. Patel-Schneider 2014-04-30 14:59:41 UTC
I'm again asking if there is any way to determine why the Yoga 2 Pro routinely spontaneously wakes up from lid close sleep but doesn't wake up when explicitly put to sleep.   There is a workaround - turning off USB wakeups - but why the difference and is there any way to roll the workaround into the distributed system?

Comment 6 Justin M. Forbes 2014-05-21 19:39:46 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.

Comment 7 Justin M. Forbes 2014-06-23 14:49:41 UTC
*********** MASS BUG UPDATE **************
This bug is being closed with INSUFFICIENT_DATA as there has not been a response in 4 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.