#8050 NORM 9.1.0: cerebro spins endlessly when "extreme power managment" turns off wifi

[Zarro Boogs per Child]

#8050: cerebro spins endlessly when "extreme power managment" turns off wifi
-------------------------+--------------------------------------------------
   Reporter:  gnu        |       Owner:  ypod         
       Type:  defect     |      Status:  new          
   Priority:  normal     |   Milestone:  9.1.0        
  Component:  cerebro    |     Version:  not specified
 Resolution:             |    Keywords:  blocks?:8.2.0
Next_action:  never set  |    Verified:  0            
  Blockedby:             |    Blocking:               
-------------------------+--------------------------------------------------

Comment(by gnu):

 I doubt that cerebro is using much CPU when it's polling for the
 interface.  The problem is that it's waking up the system once a second to
 do the polling.  In a sane suspend/resume system (which we don't have but
 are trying to approach), this would prevent the system from ever
 suspending, even though it has no actual work to do.

 Inotify(2) won't let you sleep until a network interface changes state (it
 only works on file systems), so you'd be stuck with dbus to await network
 change notices.  I wonder if we could make a convention for inotify,
 though:  NetworkManager would create or remove entries in /var/run
 /network-interfaces/ whenever it brought up or took down an interface.
 Then you could inotify on that directory.  dbus is cleaner.

 Alternatively, cerebro could cleanly terminate when it finds no network
 interfaces, and rely on another program (like NetworkManager) to start it
 when an interface comes up.

 Hmm, I had shut down cerebro because it was yammering on my console.  When
 I bring it back up and that network interface is missing, it quits.  So if
 I turn off extreme power management, then do "service cerebro start", it
 comes up.  It then polls every 996 msec -- it's waking up once a second
 ALL THE TIME!  If I then turn on extreme power management, I got it into a
 really bad state, in which it does burn 100% of the CPU, sitting in a
 poll() loop.  It is trying to poll once a second or when fd's 4, 7, or 8
 wake up.  FD 7 gets a POLLERR event, so it does not delay at all, but the
 code doesn't handle the error, it just loops back and calls poll() again.
 So it is, in some failure modes, burning up all the CPU time.

-- 
Ticket URL: <http://dev.laptop.org/ticket/8050#comment:8>
One Laptop Per Child <http://laptop.org/>
OLPC bug tracking system