[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1430916098.2786.9.camel@hadess.net>
Date: Wed, 06 May 2015 14:41:38 +0200
From: Bastien Nocera <hadess@...ess.net>
To: Chirantan Ekbote <chirantan@...omium.org>
Cc: "Rafael J. Wysocki" <rjw@...ysocki.net>,
John Stultz <john.stultz@...aro.org>,
Olof Johansson <olof@...om.net>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
snanda@...omium.org, Tomeu Vizoso <tomeu.vizoso@...labora.com>,
Linux PM list <linux-pm@...r.kernel.org>
Subject: Re: A desktop environment[1] kernel wishlist
On Tue, 2015-05-05 at 12:22 -0700, Chirantan Ekbote wrote:
> On Tue, May 5, 2015 at 3:46 AM, Bastien Nocera <hadess@...ess.net>
> wrote:
> >
> > > The last thing the power manager does, right before
> > > writing "mem" to /sys/power/state, is write the wakeup_count
> > > that it
> > > read earlier to /sys/power/wakeup_count. If the write fails, the
> > > power manager considers the suspend attempt failed, reads the new
> > > wakeup_count, and starts a timer (usually 10 seconds) to retry
> > > the
> > > suspend. The same thing happens if the write to /sys/power/state
> > > fails.
> >
> > Is this something that logind should do as well?
> >
>
> We do it to avoid a race condition where a wakeup event occurs after
> userspace has started the suspend process but before anything writes
> "mem" to /sys/power/state. I'm guessing that this is something
> logind
> should be doing as well since the chances of missing a wakeup event
> increase the longer any given delay inhibitor takes to delay a
> suspend.
File https://bugzilla.freedesktop.org/show_bug.cgi?id=90339
Cheers
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists