#11428 NORM Not Tri: Using runin to automate reporting of problematic XOs

[Zarro Boogs per Child]

#11428: Using runin to automate reporting of problematic XOs
------------------------------------+---------------------------------------
           Reporter:  reuben        |       Owner:  rsmith       
               Type:  enhancement   |      Status:  new          
           Priority:  normal        |   Milestone:  Not Triaged  
          Component:  not assigned  |     Version:  not specified
         Resolution:                |    Keywords:               
        Next_action:  never set     |    Verified:  0            
Deployment_affected:                |   Blockedby:               
           Blocking:                |  
------------------------------------+---------------------------------------

Comment(by Quozl):

 OFW test results can be written to internal SD or eMMC, there's a
 partition that can be written to reasonably safely.  Then they can be read
 by the deployed build and sent by wireless to HQ.

 How much time can the OFW tests take from usage of the laptop?
 Comprehensive OFW tests take a considerable time, as far as a child is
 concerned, during which time the operating system is unavailable.  Can the
 tests be interactive, or must they be non-interactive?

 RUNIN testing is designed to stress a laptop, to consume the maximum
 amount of power, and has an impact on the lifetime of the unit.  Use of
 the RUNIN sdwrite test would reduce the lifetime of the microSD or eMMC.

 Of the tests in RUNIN, the benefit and cost would be:

 ||''test''||''benefit''||''cost''||
 ||accelerometer||detection of failed part||none||
 ||battery||detection of low capacity||reduction of lifetime||
 ||camera||none||none||
 ||cpu temperature||potential detection of head spreader failure||power||
 ||fscheck||detection of filesystem corruption||power, reduction of
 lifetime||
 ||light sensor||none||none||
 ||memory||potential detection of memory failure||power||
 ||sdwrite||detection of FLASH failure||reduction of lifetime||
 ||sound||none||none||
 ||suspend||none||none||
 ||wlan||detection of missing card or connector break, not antenna
 break||none||

 As you can see, the RUNIN tests are not suited to this task.

 It would be better to have post-deployment tests written, based on:
  * capturing powerd logs,
  * capturing CPU and battery temperatures,
  * capturing evidence of use of critical features, such as camera,
 speakers, microphone, lid switch, ebook switch, network association, USB
 ports, rotate keys, keyboard keys, touchpad, DC power input.

 Post-processing these very small logs at HQ would be effective.  However,
 if the laptop has to do the processing work itself, this is also possible.

 Privacy of the learner is also a concern for any global design.

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