#6589 BLOC Update.: xo stops responding to mesh path requests frames

[Zarro Boogs per Child]

#6589: xo stops responding to mesh path requests frames
-----------------------+----------------------------------------------------
  Reporter:  jcardona  |       Owner:  dwmw2   
      Type:  defect    |      Status:  new     
  Priority:  blocker   |   Milestone:  Update.1
 Component:  wireless  |     Version:          
Resolution:            |    Keywords:          
  Verified:  1         |    Blocking:          
 Blockedby:            |  
-----------------------+----------------------------------------------------

Comment(by ashish):

 Replying to [comment:19 dwmw2]:
 > We should already be waiting for 200ms after sending the final block of
 the firmware.
 > That wait_event_interruptible() will stay asleep until woken either by
 the {{{if_usb_fw_timeo()}}} function, or by {{{if_usb_receive_fwload()}}}
 upon receiving the {{{FIRMWARE_READY}}} event.
 >
 > We reset the timer to 200ms immediately before setting
 {{{cardp->fwdnldover}}} after sending the final block (again, in
 {{{if_usb_receive_fwload()}}}, so execution in
 {{{if_usb_prog_firmware()}}} shouldn't resume sooner.
 >
 > The only possible exception I see is if it's interrupted by a signal
 while it's waiting for the event. We should probably change that
 {{{wait_event_interruptible()}}} to just {{{wait_event()}}}.
 >
 > Or is it that 200ms is not enough, and we just need to be waiting for
 longer?

 Unfortunately, I missed this part of the code. 200ms wait is long enough
 when driver could not receive FIRMWARE_READY event. In the current
 implementation there is possiblity of firmware bug as I could see HW_SPEC
 (0x3) command echoed back without any change in command parameters. This
 might be becuase as soon as driver gets FIRMWARE_READY it resumes card
 initialization and issues HW_SPEC (0x3) command and firmware might have
 failed to send back proper response.
 Interestingly, enabling libertas debug log during XO boot-up always gives
 expected result (proper MAC and other information). So adding a small
 delay (either in form of debug log o/p delay or fixed wait 200ms, can be
 much lower but not experimented) after firmware download somehow prevents
 this race.
 I will update here with more information shortly.

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