#5194 BLOC Ship.2: WLAN module communication issues

[Zarro Boogs per Child]

#5194: WLAN module communication issues
-----------------------+----------------------------------------------------
  Reporter:  mbletsas  |       Owner:  rbhagwat                         
      Type:  defect    |      Status:  new                              
  Priority:  blocker   |   Milestone:  Ship.2                           
 Component:  distro    |     Version:  Development build as of this date
Resolution:            |    Keywords:  wireless, USB                    
  Verified:  1         |  
-----------------------+----------------------------------------------------

Comment(by carrano):

 I am trying for some hours now to reproduce the blinking-light/broken-
 wireless status in
 order to determine if, after the crash, the XO still forward frames.

 I started testing 20p42 in four XOs (with builds varying from 640 to 643)
 and I got very
 stable results. One of the XOs is pinging the AP ("media lab 802.11") for
 3+ hours now
 using 2k packets and an interval of 100ms with 0% loss. The other 3 are
 doing default
 pings, also with no packet loss.

 I then went back to 20p4. Again I couldn't break it the same way, but I
 could break it in other ways.

 In the uploaded capture file (capture-crash.pcap) after a successful
 association and some pinging to the AP, the XO stoped pinging and began to
 dump "usb_tx_block using URB already in flight" on the screen. After some
 time we had a kernel panic (not registered in the capture file which was
 interrupted first).

 Kernel Panic - Not syncing: Fatal exception in interrupt
 atkbd.c: Spurious ACK on isa0060/serio0. Some program might be trying to
 access hardware
 directly.


 The after-kernel-panic file shows packets captured after the kernel panic.

 In resume, 20p42 at least in my tests is much more reliable than 20p4 or
 20p41.

 The 20p4, on the other hand. is relatively easy to break. Just associating
 and generating some traffic will do the job (at least here at 1cc). But
 right now, I couldn't get the continuously blinking led scenario again.

 {{{
 Kernel Panic - Not syncing: Fatal exception in interrupt
 atkbd.c: Spurious ACK on isa0060/serio0. Some program might be trying to
 access hardware
 directly.
 }}}

 The after-kernel-panic file shows packets captured after the kernel panic.

 In resume, 20p42 at least in my tests is much more reliable than 20p4 or
 20p41.

 The 20p4, on the other hand. is relatively easy to break. Just associating
 and generating some traffic will do the job (at least here at 1cc). But
 right now, I couldn't get the continuously blinking led scenario again.

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