what about having network connections inhibit sleep?

[Mikus Grinbergs]

> The real fix is to only force a suspend when the kernel knows no
> process is scheduled to run now or soon, and to waken in less than a
> whole second.

I'm just a user, exercising whatever functions have been made 
available in Joyride.  [I manually 'touch/rm' the various inhibit 
files in /etc/ohm and in /etc, to prohibit/allow 'suspend'.]

I have a *number* of additional devices plugged in to my XO 
(principally a "permanent" SD card).  It is my personal opinion that 
  'waken' will be made to happen in less than a second __ONLY__ if 
what 'resume' performs is "re-establishing the *original* software 
environment (as it existed at the moment when suspend took place)", 
and leaves "device discovery" to some sort of a follow-on process.


I do not have my XO instrumented, to see what is actually happening 
during 'resume'.  But in the past it has appeared to me that the 
system was trying to re-index the content of the SD card (in case 
cards were swapped while suspended ??).  Given the hundreds of files 
on that card, one common result was that 'resume' gave up (timed out 
??), and the XO went back into suspend state (power light blinking).

Also, I use an USB-ethernet adapter.  'Suspend' drops power to USB, 
and my adapter re-initializes so slowly after power-on that 'resume' 
replaces the system's previous wired IP-address (on 'eth_') by a 
radio IP-address.  Lately, I've been attaching my ethernet adapter 
through an independently-powered USB hub -- and having that ethernet 
adapter be still "powered up" when 'resume' runs in the XO *does* 
allow the system to keep its wired IP-address (though currently the 
ethernet network connection does not work after the 'resume' -- some 
sort of 'route' information seems to have been lost by 'resume').


What I'm saying is that in my opinion, performing "discovery of 
external devices" during 'resume' might make "wake in less than a 
second" an impossibility.


mikus