Re: [PATCH 0/8] Suspend block api (version 8)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tuesday 01 June 2010, Alan Stern wrote:
> On Tue, 1 Jun 2010, Neil Brown wrote:
> 
> > > With wakeup events the problem isn't so bad.  Wakeup events are always
> > > noticed, and if the system is designed properly they will either abort
> > > a suspend-in-progress or else cause the system to resume as soon as the
> > > suspend is complete.  (Linux is not yet properly designed in this
> > > sense.)
> > 
> > This is exactly the issue.  Linux doesn't get this right.  A wakeup that is
> > processed by the driver just before suspend may not get all the way out to
> > it's final destination (possibly in meat-space) until after some other event
> > wakes the device.  It is not possible to guarantee full delivery of a wakeup
> > event with Linux in its current state.  This is a bug.
> 
> That wasn't what I meant.  An important requirement is that a wakeup 
> event received after the device has been suspended, but before the 
> system suspend is complete, should cause the system suspend to abort.  
> This is one of the things suspend blockers were meant to help with.  In 
> theory it should already work correctly -- but it doesn't.  That's a 
> real bug.
> 
> The other things you're talking about aren't really bugs.  That is,
> they are things which the kernel _ought_ to do but it wasn't _intended_
> to do.  They are misfeatures: failures of design, not failures of 
> execution.
> 
> > I don't think I'm missing that.  Wakeup events are the only events of
> > interest.  But wakeup events are more than just low-level hardware events.
> > They are also the virtual events that are a direct consequence of the
> > original hardware event.
> 
> This is a matter of semantics and it is highly debatable.
> 
> > A UART asserts 'data ready' which is routed to an IO interrupt line that
> > wakes the device.  This is a wakeup event.
> 
> Yes.
> 
> > So are the bits that appear on the data line which represent the data
> > So are the characters that appear on the serial port
> > So is the "here is a message from the GSM processor" event
> > So is the "there is a new TXT message" event
> > So is the "'beep beep beep' out the speaker" event
> 
> None of those things can cause the system to wake up after it is
> suspended.  Indeed, they can't happen at all if the CPU isn't running
> (unless the GSM processor runs autonomously -- let's ignore such
> details).  Hence it makes little sense to call them "wakeup" events.
> 
> > All these events are wakeup events, and should abort or instant-resume the
> > system.  Currently only the first can be guaranteed to do this (... and maybe
> > the second, depending on the details of the implementation).
> > suspend-blocks effectively pass a lock from one event to the next to ensure
> > that all of these event block the suspend.  There are various other ways to
> > achieve the same thing, and I think it can be done with no significant change
> > to the API.  But some how we need to allow all of these events to be
> > linked wake-up events, not just the first one.
> 
> That's not entirely clear.  Yes, for Android's use case that's what you 
> want.  But in other situations maybe you don't.  Consider the example 
> of someone who closes the lid of their laptop and throws it in a 
> backpack.  The computer should suspend immediately; it shouldn't be 
> delayed by these "virtual wakeup" events.

BTW, this is an important point.  We've already had some bug reports regarding
such unwanted wakeup events.

Rafael
_______________________________________________
linux-pm mailing list
linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/linux-pm


[Index of Archives]     [Linux ACPI]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [CPU Freq]     [Kernel Newbies]     [Fedora Kernel]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux