[OLPC-devel] Thoughts on S3 resume.

[Matthew Garrett]

On Thu, Aug 10, 2006 at 09:58:52PM +0100, Chris Ball wrote:
> [ 1556.231402] platform i8042: suspend
> [ 1556.236933] acpi acpi: suspend

So on the bright side, it takes us 5 msec to do hardware suspend. Sadly, 
there's then 20 seconds between us hitting

> [ 1556.236971] PM: Entering mem sleep

and the hardware actually suspending. This doesn't give us any 
information about where it's blocking - that's going to require more 
debugging code sprinkled through acpi_enter_sleep_state_prep and 
acpi_enter_sleep_state in drivers/acpi/hardware/hwsleep.c . It's 
possible that it's the BIOS being insanely slow, or alternatively it 
could be Linux just behaving oddly. In any case, it might give us a clue 
as to why

> [   24.524549] Back to C!

takes so long.

> [   24.647785] acpi acpi: resuming
> [   24.647828] pci 0000:00:01.0: resuming
> [   24.648459] pci 0000:00:01.1: resuming
> [   24.649266] pci 0000:00:0f.0: resuming
> [   24.649891] pci 0000:00:0f.2: resuming
> [   24.650502] pci 0000:00:0f.3: resuming
> [   24.651114] pci 0000:00:0f.4: resuming
> [   24.651824] pci 0000:00:0f.5: resuming
> [   24.652537] pnp 00:00: resuming
> [   24.652562] pnp 00:01: resuming
> [   24.652585] pnp 00:02: resuming
> [   24.652686] pnp 00:03: resuming
> [   24.652712] pnp 00:04: resuming
> [   24.652735] platform pcspkr: resuming
> [   24.652759] vesafb vesafb.0: resuming
> [   24.652786] serial8250 serial8250: resuming
> [   24.653027] platform i8042: resuming

Driver resume takes about 10msec. We then sit around for 250msec while 
not much seems to happen, then

> [   26.914341] Restarting tasks... done
> [   26.950518] Thawing cpus ...

around 40 or so to get userspace running again. Doesn't look like the 
bottleneck is going to be in the driver code.

It would be interesting to see how well The Other ACPI Implementation 
manages. Has anyone got Windows running on one of the boards?

-- 
Matthew Garrett | mjg59 at srcf.ucam.org