> 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 _______________________________________________ Devel mailing list [email protected] http://lists.laptop.org/listinfo/devel
