Bug 1121520 - systemd puts notebook into suspend when it wakes up in docking station with lid closed
Summary: systemd puts notebook into suspend when it wakes up in docking station with l...
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: 20
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
Assignee: systemd-maint
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-07-21 06:54 UTC by Tomáš Hozza 🤓
Modified: 2015-06-17 23:57 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-06-17 23:57:59 UTC


Attachments (Terms of Use)

Description Tomáš Hozza 🤓 2014-07-21 06:54:07 UTC
Description of problem:
Every day in the evening I log out, suspend my notebook outside of the docking station and close the lid after it is suspended. In the morning I put the notebook into the docking station and wake it up using the power button in on the docking station (with lid closed). System starts up. After I log in, the system suspends itself and I have to wake up the notebook once again. 

Really nice feature is that after the last wake-up, the system does not require password and I'm already logged in.

This happens every day and is getting incredibly annoying ;)

Version-Release number of selected component (if applicable):
systemd-208-19.fc20.x86_64
gnome-shell-3.10.4-5.fc20.x86_64
kernel-3.15.4-200.fc20.x86_64

How reproducible:
always

Steps to Reproduce:
0. log out (no users are logged in)
1. suspend the notebook outside of the docking station
2. close the lid
3. put the notebook into docking station
4. turn it on using the power button on the docking station
5. log in
6. see your notebook suspending

Actual results:
The system suspends after waking up in the docking station with lid closed

Expected results:
The system does NOT suspend after waking up in the docking station with lid closed

Additional info:
There are also other variants of this issue:
1. while logged in with notebook outside of the docking station suspend the system.
2. close the lid
3. put the notebook into the docking station
4. wake up the notebook using power button on the docking station (with lid closed)
5. log in
6. everything works just fine until ...
7. log out
8. your system suspends by itself

Something is seriously broken in the systemd-{logind,sleep}

Jul 20 22:52:38 thozza-pc systemd-logind[892]: Delay lock is active but inhibitor timeout is reached.
Jul 20 22:52:38 thozza-pc systemd[1]: Starting Sleep.
Jul 20 22:52:38 thozza-pc systemd[1]: Reached target Sleep.
Jul 20 22:52:38 thozza-pc systemd[1]: Starting Suspend...
Jul 20 22:52:38 thozza-pc systemd-sleep[27034]: Suspending system...
Jul 20 22:52:38 thozza-pc kernel: PM: Syncing filesystems ... done.
Jul 20 22:52:38 thozza-pc kernel: PM: Preparing system for mem sleep
Jul 21 08:10:23 thozza-pc kernel: Freezing user space processes ... (elapsed 0.001 seconds) done.
Jul 21 08:10:23 thozza-pc systemd[1]: Time has been changed
Jul 21 08:10:23 thozza-pc systemd[3062]: Time has been changed
Jul 21 08:10:23 thozza-pc systemd[1092]: Time has been changed
Jul 21 08:10:23 thozza-pc systemd[1701]: Time has been changed
Jul 21 08:10:23 thozza-pc systemd-logind[892]: Lid closed.
Jul 21 08:10:23 thozza-pc systemd-sleep[27034]: System resumed.
Jul 21 08:10:23 thozza-pc systemd[20713]: Time has been changed
Jul 21 08:10:23 thozza-pc systemd[1]: Started Suspend.
Jul 21 08:10:23 thozza-pc systemd[1]: Requested transaction contradicts existing jobs: File exists
Jul 21 08:10:23 thozza-pc systemd[1]: Service sleep.target is not needed anymore. Stopping.
Jul 21 08:10:23 thozza-pc systemd[1]: Stopping Sleep.
Jul 21 08:10:23 thozza-pc systemd[1]: Stopped target Sleep.
Jul 21 08:10:23 thozza-pc systemd[1]: Reached target Suspend.
Jul 21 08:10:23 thozza-pc systemd-logind[892]: Operation finished.
Jul 21 08:10:24 thozza-pc kernel: Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
Jul 21 08:10:23 thozza-pc NetworkManager[1002]: <info> wake requested (sleeping: yes  enabled: yes)
Jul 21 08:10:23 thozza-pc NetworkManager[1002]: <info> waking up and re-enabling...
Jul 21 08:10:23 thozza-pc NetworkManager[1002]: <info> (em1): device state change: unmanaged -> unavailable (reason 'managed') [10 20 2]
Jul 21 08:10:23 thozza-pc NetworkManager[1002]: <info> (em1): bringing up device.
Jul 21 08:10:23 thozza-pc NetworkManager[1002]: <info> NetworkManager state is now DISCONNECTED
Jul 21 08:10:23 thozza-pc NetworkManager[1002]: <info> (wlp3s0): device state change: unmanaged -> unavailable (reason 'managed') [10 20 2]
Jul 21 08:10:23 thozza-pc NetworkManager[1002]: <info> (wlp3s0): bringing up device.
Jul 21 08:10:24 thozza-pc gnome-session[26865]: Window manager warning: Could not assign CRTC to outputs, ignoring configuration
Jul 21 08:10:24 thozza-pc gnome-session[26865]: Window manager warning: Could not make default configuration for current output layout, leaving unconfigured
Jul 21 08:10:24 thozza-pc kernel: PM: Entering mem sleep
Jul 21 08:10:24 thozza-pc kernel: Suspending console(s) (use no_console_suspend to debug)
Jul 21 08:10:24 thozza-pc kernel: sd 1:0:0:0: [sdb] Synchronizing SCSI cache
Jul 21 08:10:24 thozza-pc kernel: sd 1:0:0:0: [sdb] Stopping disk
Jul 21 08:10:24 thozza-pc kernel: sd 0:0:0:0: [sda] Synchronizing SCSI cache
Jul 21 08:10:24 thozza-pc kernel: sd 0:0:0:0: [sda] Stopping disk

Comment 1 Lennart Poettering 2014-07-23 19:22:08 UTC
What kind of docking station is this? Do you use a graphics driver that properly reports multiple connected dispays? Does your docking station report docking station with the input layer (SW_DOCK)?

Comment 2 Tomáš Hozza 🤓 2014-07-24 07:09:44 UTC
(In reply to Lennart Poettering from comment #1)
> What kind of docking station is this?

ThinkPad Mini Dock Series 3 (notebook is ThinkPad T420s)

> Do you use a graphics driver that properly reports multiple connected dispays? 

$ systemd-inhibit --list | grep Multi
     Why: Multiple displays attached

So I hope so.

> Does your docking station report docking station with the input layer (SW_DOCK)?

If you tell me how to gather these information for you I'll be more than happy to provide them.

Comment 3 Lennart Poettering 2014-08-18 22:52:37 UTC
(In reply to Tomas Hozza from comment #2)
> (In reply to Lennart Poettering from comment #1)
> > What kind of docking station is this?
> 
> ThinkPad Mini Dock Series 3 (notebook is ThinkPad T420s)

is that an usb dock?

does this also occur on rawhide?

Comment 4 Tomáš Hozza 🤓 2014-08-19 08:20:47 UTC
(In reply to Lennart Poettering from comment #3)
> (In reply to Tomas Hozza from comment #2)
> > (In reply to Lennart Poettering from comment #1)
> > > What kind of docking station is this?
> > 
> > ThinkPad Mini Dock Series 3 (notebook is ThinkPad T420s)
> 
> is that an usb dock?

I don't know. It's connected via some lenovo port.
https://forums.lenovo.com/t5/image/serverpage/image-id/13613i4FF305AC1DAD7C7A?v=mpbl-1

> does this also occur on rawhide?

Didn't test it with rawhide. Will try to reproduce it.

Comment 5 Fedora End Of Life 2015-05-29 12:25:35 UTC
This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '20'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 20 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 6 Lennart Poettering 2015-06-17 23:57:59 UTC
I am pretty sure this works better with more recent systemd versions, specifically on rawhide. Closing hence. Feel free top reopen if it still doesn't work.

(reason: logind now tracks video plug state on its own, this is not a job of GNOME anymore)


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