#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):

 Replying to [comment:7 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.

 I am sorry. This post is broken. I am repeating.

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