Suspend and resume

  For the general public

The XO can suspend and resume with little effort; as there are no moving parts to spin down, total time to resume can possibly be brought down to below 100ms. As of build 623 it takes 900-1000 ms. As of build 860, it takes closer to 500 ms. (under 100ms of that is hardware time, the rest is kernel and software time, refreshing the DCON, &c.) Short suspensions allow for suspension between bouts of activity for slow applications, and for aggressive suspend modes that conserve significant amounts of power. The current default setting is to suspend after ~15 seconds of inactivity.

For the latest notes on suspension, see:

Power Management Overview

Powerd

Older notes follow. For the original discussion of suspension on XO-1s, including test machines, see #Older notes below.

  For Developers

The contents of this page are considered outdated and some of the information may be stale. Please use information here with caution, or update it.

Disabling Suspensions

.ini files from /etc/ohm/plugins.d

# acadapter preference values

# xorg preference values
xorg.display 0

# dpms preference values
# method:
# 0     stagger
# 1     standby
# 2     suspend
# 3     off
dpms.method 3 public
powerstatus.percentage_low 20 public
powerstatus.percentage_critical 10 public
suspend.fixme_inhibit 0 public

# backlight preference values
backlight.hardware_brightness 15 public
backlight.percent_brightness 100 public

# battery preference values
timeouts.timer_momentary 25000 public
timeouts.timer_powerdown 30000 public

# timeremaining preference values
timeremaining.calculate_hysteresis 1 public
display.value_ac 15 public
display.value_battery 15 public
display.value_idle 6 public
display.value_user 15 public

# button preference values

# xrandr preference values

Disable suspend features

To prevent suspend from happening.

 # touch /etc/ohm/inhibit-suspend

To re-enable suspend.

 # rm  /etc/ohm/inhibit-suspend

Still under consideration, refusing to suspend when certain classes of USB devices are plugged in. This hasn't been implemented yet (as of Update.1 build 680)

Testing Suspensions

Also see OFW Suspend/Resume Tests and Test Resume Suspend.

The most important tool for testing suspension is a setup for monitoring the power consumption of the laptop. The "Tinderbox" was designed to measure power consumption, and various measurements have been taken with it, but there's no automated (e.g. nightly) testing that can tell us whether our software, as it evolves, is burning more or less power than it did yesterday.

Richard Smith suggests examining the couloumb counter in the battery to determine how much energy is used over time. (cat /sys/devices/platform/olpc-battery.0/power_supply/olpc-battery/accum_current; it is in bizarre units.) That's a great resource, but requires that the tests be run with AC power off. This is easy for manual testing, but might require additional infrastructure in an automated testbed.

Kernel Support For Suspend

This sysfs file lets user programs control whether the system wakes up from WiFi events:

 echo 3 > /sys/module/usb8xxx/parameters/wakeup

for wake on bcast and unicast, for example. The value is the sum of 1 for broadcast, 2 for unicast, 4 for "mac event". It was added to the kernel on 13 Nov 2007.

Other Non-Suspend Power Saving Strategies

When the notebook is in ebook mode (and the keyboard and mouse are covered up), those peripherals should be unpowered, or should be put into their lowest possible power consumption.

The SD interface may require special consideration. The most common case is that there is nothing in the slot; this should not block automatic suspension, and indeed an empty slot should be almost completely powered down at all times, whether the CPU is suspended or not. Ideally the system should be able to detect an inserted card, but should spend almost zero power until a card is inserted. I do not yet know if the hardware is capable of this. If it isn't, perhaps inserting an SD card should require a specific software or hardware action by the user (e.g. pressing the power button, or clicking on something in the Journal).

The next most common case of an inserted but largely unused SD/MMC memory card can eventually be handled by letting it write its cache, quiesce, then silently powering it down. Resume its power later, whenever the software needs to access it. For increased safety of its file system integrity, the file system should probably be sync'd or quietly internally dismounted before powering down the slit (and quietly remounted at the first access; /proc/mounts would continue to show it as mounted throughout, but the file system structures on the media would be synchronized as if dismounted).

The same strategy would be fruitful for USB mass storage devices. They need not burn power forever when plugged in and used briefly. USB non-mass-storage devices, such as network interfaces, serial ports, keyboards, mice, etc, may sit idle for a long time "unused" by the CPU and user software, yet have the potential to interrupt at any time from an external event. All of these devices would prevent automatic suspensions, and thus they cause battery life to drop dramatically.

It may be useful to have a user-settable control which would allow such devices to be powered down when not in active use. If the user set this control, they'd be overriding the system's "safe" default decision to always keep the device powered on (and thus to avoid all automatic suspensions).

Older notes

Notes from early XO-1 suspend work:

There are also some substantial delays associated with powering-up the USB bus after suspending. The gen2 laptop should NOT attach its network via USB -- or at least not via an externally visible, powered, USB bus that gets turned off during suspend. To modify a XO-1 B2 to suspend, see B2 Suspend ECR. Further fixes were made between XO-1 B4 and C2 builds.

Categories of Suspensions

The two fundamental categories of suspends are 'manual' and 'automatic'. Manual suspends are done on specific command by the user, e.g. by closing the laptop lid. Such suspends should not be resumed without manual action by the user (e.g. opening the lid). Automatic suspends are done by the laptop on its own initiative, without input from or consultation with the user. These should be transparent to the user -- the user should not be able to tell whether the laptop is suspended or not. They should be automatically resumed whenever the laptop needs to do something.

OS code in build 624 produces a suspension when the power button is pressed, that has elements of both a manual and an automatic suspend. The two kinds of suspends should not be confused; but numerous bugs in suspend are reported because of this confusion. E.g. manual suspends are waking up when a packet arrives, when a key is hit, or when the battery charge changes. That's useful for automated testing, but not for end users. From a programming point of view, people talk about it being troublesome to "wake the CPU for some event (like a battery charge update, or a switch from ebook mode to laptop-closed) and then have it immediately go back to sleep". Automatic suspends make such things trivial.

Automatic Suspensions

The laptop should suspend automatically whenever the CPU and DMA activity is expected to be idle for a significant period of time. This is strictly a power-saving measure, and should not result in any user-visible changes to the screen or peripherals. Anything and everything that requires CPU attention should cause it to power-up immediately. Before suspending, the system will set a timer to ensure that it wakes up before the next scheduled event in the kernel or any user process.

Unfortunately, the USB bus must be powered down when the CPU is; and the network chip is attached to USB. Thus the chip has a separate "wakeup" wire to ask the system to resume when the network chip needs service. Another impact is that the system can't suspend when the USB bus is in use by an external device (unless it's a USB mass storage device and has been fully allowed to write any cached info and quiesce itself).

A further complication is that the USB implementation constantly does DMA, to poll the plugged-in devices, whether or not any real user visible I/O activity is happening. Thus, the decision to enter an automatic suspension must ignore the DMA caused by the USB idle polling, as well as ignoring the presence of the network chip on the USB bus, in order to successfully decide to suspend.

Because DMA must be inactive when the CPU is powered down (there's no bus arbiter), the CPU will not be able to suspend whenever audio input or output is occurring; nor when the video camera is in use. Pending reads and writes to flash, SD, or network will all prevent automatic suspend.

Automatic suspension may eventually be implemented with a new Linux kernel infrastructure called "cpuidle", which allows the CPU to decide what to do when it becomes idle. But until that works, it is being handled by the OHM daemon, which watches idle times in the X server and perhaps on ttys, and asks the kernel to suspend.

Manual Suspensions

Once automatic suspensions are working, the only time that end-users would normally want to explicitly suspend the laptop is by closing the lid. It's conceivable that scenarios could be invented, such as when a USB device is plugged in and automatic suspend won't work, when the user might want to specifically suspend the laptop. But they can do so by closing the lid. The laptop should only resume when the lid is opened (or perhaps to do an automatic clean shutdown and power-off when the battery is about to go dead). Pressing keys, moving the mouse, network packets should all be ignored (keys and mouse motions are ghosts, possibly from jostling or dropping the laptop). Indeed, the keyboard, mouse, USB, SD card, camera, and network should all be put into maximum power-saving mode (ideally with all power removed) when a manual suspension happens.

Pressing the power button could cause a different kind of suspend, if one is needed (either for testing, or by end users). Or the power button could be reclaimed for other uses. Laptops are going to live a large part of their lives closed, so that kind of suspend must work. Having only one kind of user-visible suspend would eliminate user confusion.

Perhaps the power button should be repurposed for "suspend to disk" (i.e. suspend to flash), which would allow the system to go into a state that consumes really tiny amounts of power (for only the EC), without requiring a reboot.

Manual suspensions should in general not be necessary in ebook mode. If the book is not being looked at, it should be closed. Using the power button to suspend an ebook and then stuff it into a backpack is likely to wake it up from having the power button jostled. The main additional power saving available in manual suspend is from turning off the screen and the backlight.

For now, one trick to do manual suspensions is to use the Terminal to run a saved script like the following. Run it before closing/walking away from your XO, and press Ctrl-C a few times to wake back up. Warning - don't just press alt-tab or a zoom key while it's suspended like this, the suspend will keep trying to trigger. Oh, and don't forget to "chmod +x mysuspend" and "./mysuspend" to use it!

#!/bin/sh
xset dpms force standby
while sleep 5 ;do
    xset dpms force standby
    su -c "echo mem > /sys/power/state"
done

There's a reason this isn't automatically set to work on the XO, it will break things. The wireless will likely disappear (both LEDs on the left go dark) and need a reboot to bring it back. Any USB or SD drives attached will be forced to detach, that is buggy and weird things may happen (in a terminal session cd'd into an SD card, the card's directory listing turned into gibberish. A reboot cured this with no permanent damage). Sometimes the kernel will simply break sleep support, and stay awake anyways.