5:07 p.m.
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
--
martin.langhoff(a)gmail.com
- ask interesting questions
- don't get distracted with shiny stuff - working code first
~ http://docs.moodle.org/en/User:Martin_Langhoff
5:38 p.m.
On Thu, Mar 13, 2014 at 3:07 PM, Martin Langhoff
<martin.langhoff(a)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(a)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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
5:54 p.m.
On Thu, Mar 13, 2014 at 6:38 PM, Andrew Lutomirski <luto(a)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
--
martin.langhoff(a)gmail.com
- ask interesting questions
- don't get distracted with shiny stuff - working code first
~ http://docs.moodle.org/en/User:Martin_Langhoff
6:38 p.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.
7:45 p.m.
On Thu, 13.03.14 18:07, Martin Langhoff (martin.langhoff(a)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
--
Lennart Poettering, Red Hat
11:38 a.m.
On Fri, 2014-03-14 at 01:45 +0100, Lennart Poettering wrote:
On Thu, 13.03.14 18:07, Martin Langhoff (martin.langhoff(a)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
11:41 a.m.
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
--
Tomasz Torcz RIP is irrevelant. Spoofing is futile.
xmpp: zdzichubg(a)chrome.pl Your routes will be aggreggated. -- Alex Yuriev
1:40 p.m.
On Fri, Mar 14, 2014 at 12:41 PM, Tomasz Torcz <tomek(a)pipebreaker.pl> wrote:
systemd-inhibit --list
Fantastic info - Tomasz and Lennart. Thanks!
m
--
martin.langhoff(a)gmail.com
- ask interesting questions
- don't get distracted with shiny stuff - working code first
~ http://docs.moodle.org/en/User:Martin_Langhoff
5:18 p.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
8:21 p.m.
On Mon, 17.03.14 17:18, Dan Williams (dcbw(a)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
--
Lennart Poettering, Red Hat
9:43 a.m.
On Tue, 2014-03-18 at 02:21 +0100, Lennart Poettering wrote:
On Mon, 17.03.14 17:18, Dan Williams (dcbw(a)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
9:19 a.m.
On Thu, Mar 13, 2014 at 8:45 PM, Lennart Poettering <mzerqung(a)0pointer.de>wrote:
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
--
martin.langhoff(a)gmail.com
- ask interesting questions
- don't get distracted with shiny stuff - working code first
~ http://docs.moodle.org/en/User:Martin_Langhoff
3688
days inactive
3704
days old
11 comments
6 participants
participants (6)
-
Andrew Lutomirski -
Dan Williams -
Lennart Poettering -
Martin Langhoff -
Samuel Sieb -
Tomasz Torcz