What's the current status of suspend/resume?

[John Gilmore]

> I've lost track of this area.  Could somebody please give me/us a review 
> and/or update.

On which hardware?

XO-1 had a lot of niggling bugs around the edges (all documented in
trac).  The largest was that the Linux kernel does busy-waits for the
USB bus's startup delays for sequencing power and signalling.  It took
about 900ms to resume, instead of the expected 100-200ms.  As far as I
know, nobody is working on fixing that.  Turning on the USB bus is on
the critical path to receive any packets that the WiFi chip has for
us, but it can be done with timers and interrupts, allowing the rest
of the system to come up more quickly, run user processes, handle
keyboard/mouse input, etc, in parallel with bringing up the WiFi
interface.  This is http://dev.laptop.org/ticket/9054.

The next worst of those was that we could only wake up on 1-second
boundaries because the system was only wired to wake up when the
realtime clock ticked (in classic MSDOS style: "Wake this machine at
8AM please").  That's http://dev.laptop.org/ticket/4606.  We had a fix
planned, which was for the EC to support sub-second timing and wake
the CPU when instructed.  I believe that Richard wrote the EC support,
but the Linux kernel has never used it.

Fixing these two problems would allow the system to suspend even when
user processes are running and expecting to wake up in a few seconds,
without messing up the user processes.  Currently, when it suspends,
it goes down hard and only comes back up when a key, mouse, or packet
arrives (and takes almost 1s to come back).  This causes various
troubles like the screen brightness not being changeable during
suspend because the machine can't wake up to dim it, and suspend
not being viable unless the machine is very idle.

There is also a layer of bugs, most of which were never chased down to
a fix, most of which relate to I/O devices screwing up when we
suspend.  For example http://dev.laptop.org/ticket/6528, "Packets that
wake the laptop from suspend are often lost"; or #3732, "arp broadcasts
don't wake up autosuspended laptop".

There were numerous bugs producing dozens to hundreds of useless
wakeups per second.  The most egregious was #4680, "Sugar apps' pygtk
main loop polls 10 times a second, always".  Many of these, including
that one, have been fixed somewhere upstream.  I don't know whether
modern Fedora (or any OLPC release) has all those fixes, but have heard
that new releases only make small numbers of wakeups per second.

Fixing all of the above would let the kernel invisibly autosuspend
whenever it had no processes to schedule for half a second or so (and
based on recent history, expected no TCP packets to arrive for a
similar period).

I'm not up on the XO-1.5 suspend/resume status at all.

	John