#2621 BLOC Trial-3: wireless suspend/resume failure under high-traffic

[Zarro Boogs per Child]

#2621: wireless suspend/resume failure under high-traffic
-----------------------+----------------------------------------------------
  Reporter:  marcelo   |       Owner:  rchokshi
      Type:  defect    |      Status:  new     
  Priority:  blocker   |   Milestone:  Trial-3 
 Component:  wireless  |     Version:          
Resolution:            |    Keywords:  power   
  Verified:  0         |  
-----------------------+----------------------------------------------------

Comment(by jcardona):

 We have been trying to reproduce this problem on one of the C1's ECO'd for
 #1835 that Chris sent us this week.  So far we have not been able to
 reproduce.  We do see lots of USB failures (urb status -71 and -2 in the
 kernel logs) but the wireless stays operational and responsive after
 thousands of iterations.

 ==== First Overnight Test ====

 In this test the DUT was pinging  a non-existent mesh node.  This should
 put some stress on the wireless internal buffers, as unresolved frames get
 queued up and discarded.  The test run for 3K+ suspend iterations and
 failed due to a kernel panic.

 {{{INIT: PANIC: segmentation violation at 0x804a200 (code)! sleeping for
 30 seconds}}}

 Full log here:
 [https://cozybit1.dnsalias.org/~javier/logs/overnight_sus_res_test_on_c1.log.txt
 here]

 Notes on this log:
  1. The PANIC does not show up on that log, as the serial console died
 after the PANIC).
  2. The frequent 'E' messages are generated by flood ping when it fails to
 send a frame to the device.  Pinging a non-existent mesh node will do
 that.

 ==== Second Overnight Test ====

 This time the DUT was pinging another mesh node, in the same way that wad
 describes in the previous comment.  The test went on for over 10K
 iterations.  At some point it looks like the suspend script stops.  There
 were many USB errors reported on the kernel logs (~2K '-71' errors and ~4K
 '-2' errors, but after all those iterations the wireless was operational
 and responding to host commands.  The wireless device had not been reset,
 nor the firmware reloaded.

 Full log available
 [https://cozybit1.dnsalias.org/~javier/logs/minicom_sept_21.log here (120
 MB!)].  Last iteration
 [https://cozybit1.dnsalias.org/~javier/logs/minicom_sept_21_tail.log
 here].

-- 
Ticket URL: <https://dev.laptop.org/ticket/2621#comment:29>
One Laptop Per Child <https://dev.laptop.org>
OLPC bug tracking system