suspend on 'idle'

[Chris Ball]

Hi,

[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?

Thanks,

- Chris.
-- 
Chris Ball   <cjb at laptop.org>