My Lenovo X220, running up-to-date F20 occasionally gets into a state where closing the laptop lid does not trigger suspend.
I want to narrow down on the problem, but I'm slightly lost on how "the signal is routed" through the stack. udev->?-> systemd-suspend -> kernel ?
thank you!
m
On Thu, Mar 13, 2014 at 3:07 PM, Martin Langhoff martin.langhoff@gmail.com wrote:
My Lenovo X220, running up-to-date F20 occasionally gets into a state where closing the laptop lid does not trigger suspend.
I want to narrow down on the problem, but I'm slightly lost on how "the signal is routed" through the stack. udev->?-> systemd-suspend -> kernel ?
I wonder whether this is related to the fact that, on most Lenovos, if you press the suspect button twice without waiting long enough, the second press is ignored.
--Andy, wearing his very-occasional-lenovo-driver-hacker hat
thank you!
m
martin.langhoff@gmail.com
- ask interesting questions
- don't get distracted with shiny stuff - working code first
~ http://docs.moodle.org/en/User:Martin_Langhoff
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
On Thu, Mar 13, 2014 at 6:38 PM, Andrew Lutomirski luto@mit.edu wrote:
I wonder whether this is related to the fact that, on most Lenovos, if you press the suspect button twice without waiting long enough, the second press is ignored.
Seems unlikelye. I am very careful with double-presses, and my testing was deliberate.
When it gets the funk, it seems to ignore lid switch and clear individual presses of the power button.
I need to look more in the logs, but they are bulky/noisy, so if I know what components are involved, I can narrow down on it.
cheers,
m
On 03/13/2014 03:07 PM, Martin Langhoff wrote:
My Lenovo X220, running up-to-date F20 occasionally gets into a state where closing the laptop lid does not trigger suspend.
I want to narrow down on the problem, but I'm slightly lost on how "the signal is routed" through the stack. udev->?-> systemd-suspend -> kernel ?
systemd - logind You could check that the input device for the lid switch is actually sending events.
On Thu, 13.03.14 18:07, Martin Langhoff (martin.langhoff@gmail.com) wrote:
My Lenovo X220, running up-to-date F20 occasionally gets into a state where closing the laptop lid does not trigger suspend.
I want to narrow down on the problem, but I'm slightly lost on how "the signal is routed" through the stack. udev->?-> systemd-suspend -> kernel ?
The lid switch is exposed as input device in Linux. logind opens that device and reacts on it. However it gives DEs the chance to inhibit this if they desire so. Gnome at least doesn't inhibit it perminantly though, but some components might delay suspends, for example Telepathy to log you out of your Jabber server...
Normally when you close the lid logind should log something about "Lid closed" or so... Look around the logs around this to figure out what mightbe going on.
Lennart
On Fri, 2014-03-14 at 01:45 +0100, Lennart Poettering wrote:
On Thu, 13.03.14 18:07, Martin Langhoff (martin.langhoff@gmail.com) wrote:
My Lenovo X220, running up-to-date F20 occasionally gets into a state where closing the laptop lid does not trigger suspend.
I want to narrow down on the problem, but I'm slightly lost on how "the signal is routed" through the stack. udev->?-> systemd-suspend -> kernel ?
The lid switch is exposed as input device in Linux. logind opens that device and reacts on it. However it gives DEs the chance to inhibit this if they desire so. Gnome at least doesn't inhibit it perminantly though, but some components might delay suspends, for example Telepathy to log you out of your Jabber server...
Normally when you close the lid logind should log something about "Lid closed" or so... Look around the logs around this to figure out what mightbe going on.
I've run into this too, is there a quick command to get the list of offending suspend inhibitors so we can debug further?
(pressing the power button to initiate suspend usually works for me when lid close does not...)
Dan
On Fri, Mar 14, 2014 at 11:38:31AM -0500, Dan Williams wrote:
The lid switch is exposed as input device in Linux. logind opens that device and reacts on it. However it gives DEs the chance to inhibit this if they desire so. Gnome at least doesn't inhibit it perminantly though, but some components might delay suspends, for example Telepathy to log you out of your Jabber server...
Normally when you close the lid logind should log something about "Lid closed" or so... Look around the logs around this to figure out what mightbe going on.
I've run into this too, is there a quick command to get the list of offending suspend inhibitors so we can debug further?
systemd-inhibit --list
On Fri, Mar 14, 2014 at 12:41 PM, Tomasz Torcz tomek@pipebreaker.pl wrote:
systemd-inhibit --list
Fantastic info - Tomasz and Lennart. Thanks!
m
On Fri, 2014-03-14 at 17:41 +0100, Tomasz Torcz wrote:
On Fri, Mar 14, 2014 at 11:38:31AM -0500, Dan Williams wrote:
The lid switch is exposed as input device in Linux. logind opens that device and reacts on it. However it gives DEs the chance to inhibit this if they desire so. Gnome at least doesn't inhibit it perminantly though, but some components might delay suspends, for example Telepathy to log you out of your Jabber server...
Normally when you close the lid logind should log something about "Lid closed" or so... Look around the logs around this to figure out what mightbe going on.
I've run into this too, is there a quick command to get the list of offending suspend inhibitors so we can debug further?
systemd-inhibit --list
Thanks...
*drum roll*
The offending package was telepathy-mission-control. Not really sure why it cared about suspend/resume, since I didn't have any telepathy services configured, and wasn't using it (or empathy or gnome-accounts-service) for any online accounts.
Dan
On Mon, 17.03.14 17:18, Dan Williams (dcbw@redhat.com) wrote:
systemd-inhibit --list
Thanks...
*drum roll*
The offending package was telepathy-mission-control. Not really sure why it cared about suspend/resume, since I didn't have any telepathy services configured, and wasn't using it (or empathy or gnome-accounts-service) for any online accounts.
They want to set the IM accounts to "offline" when the machine goes down.
BTW, logind versions from Rawhide will actually log the identity of all processes that take "delay" suspend locks and which don't release them by the time the timeout we put on that elapses. Or with other words, if something like Telepathy delays your suspend you should see logind mentioned that it is responsible for that in the logs. This hopefully puts enough shame on people to not delay suspend unnecessarily... ;-)
Lennart
On Tue, 2014-03-18 at 02:21 +0100, Lennart Poettering wrote:
On Mon, 17.03.14 17:18, Dan Williams (dcbw@redhat.com) wrote:
systemd-inhibit --list
Thanks...
*drum roll*
The offending package was telepathy-mission-control. Not really sure why it cared about suspend/resume, since I didn't have any telepathy services configured, and wasn't using it (or empathy or gnome-accounts-service) for any online accounts.
They want to set the IM accounts to "offline" when the machine goes down.
Yeah, I figured that was the case, but since I didn't have any Telepathy accounts actually configured, I assumed it wouldn't care about suspend/resume. Obviously a bug in mission-control.
BTW, logind versions from Rawhide will actually log the identity of all processes that take "delay" suspend locks and which don't release them by the time the timeout we put on that elapses. Or with other words, if something like Telepathy delays your suspend you should see logind mentioned that it is responsible for that in the logs. This hopefully puts enough shame on people to not delay suspend unnecessarily... ;-)
Neat!
Dan
Lennart
-- Lennart Poettering, Red Hat
On Thu, Mar 13, 2014 at 8:45 PM, Lennart Poettering mzerqung@0pointer.dewrote:
Normally when you close the lid logind should log something about "Lid closed" or so... Look around the logs around this to figure out what mightbe going on.
Thanks -- this has worked and led me to a local service of mine (an openvpn service that goes all funky when NM preps the network for suspend).
cheers,
m