suspend on 'idle'
cjb at laptop.org
Thu Aug 7 11:04:10 EDT 2008
[Removing sugar@ from CC: to keep this to one list.]
> First of all. I want to mention that when I first install a Joyride
> build, the initial state of the 'inhibit' flags (i.e., filenames)
> in /etc and /etc/ohm is "not present" -- that allows the XO to
> 'suspend'. Yet on the 'Power' sub-panel within the olpc 'Control
> Panel', the 'Automatic power management' box is __NOT__ checked. I
> thought that box would control 'suspend' -- and leaving it
> unchecked would mean "I don't want my XO to suspend". Seems like
> an incompatibility somewhere.
Yup, noticed that yesterday. It's not an incompatibility, it's just
that OHM doesn't start out by reading the control panel value; if you
change the control panel value once, the two will stay in sync from
then on. Will fix.
> More to the point, I perform a number of actions as part of
> "installing" a new build. Lately, if I forget to first set
> 'inhibit-idle-suspend', the XO is __suspending__ on me while
> performing downloads (via yum) of modules to augment what the build
> contained. [I use ethernet, and 'suspend' currently kills it - so
> I have to reboot to again have an ethernet connection.]
Could you file a bug? I don't understand why you have to reboot to
regain your ethernet connection after suspending.
> I *really* would like 'idle' to mean "processor is idle" -- not
> just "keyboard is idle" (of course my keyboard is idle -- I'm
> waiting for the still-ongoing downloads to finish before I type the
> next command).
It does, but the idleness threshold obviously isn't working for you.
If I allowed any CPU use at all (ie. the minimal amount you're using
to write to the NAND from the network) to inhibit suspend, suspend would
never happen; kernel threads use CPU in the background all the time.
We look for CPU use over 20% for a few seconds of time when deciding
whether to suspend.
I think what you actually want is one of two things:
* Not to suspend in the presence of any large network transfer.
I think this would only be necessary for your ethernet case, since
on wireless we're just going to be woken up by the next incoming
packet. As a result, I'm not so interested in adding this given
that you can inhibit suspend manually.
* Not to suspend when a USB device capable of generating external
interrupts (USB keyboard, USB ethernet) is plugged in. I'd be
willing to add that, but I haven't worked out what the best way
to detect what classes of USB devices are being used is. Maybe
that's something you can help with?
Chris Ball <cjb at laptop.org>
More information about the Devel