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

Zarro Boogs per Child bugtracker at laptop.org
Tue Aug 7 14:29:14 EDT 2007


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

 Pasting Richard Smith's email here:

 {{{
 Of the 2 units I modified and brought only 1 worked when I got here.  I
 spent a bit of time in the marvel lab reworking the splice but the
 wireless device still does not show up.

 The 2nd unit worked fine.  And we used it on the analyzer but it did not
 really tell us a lot as its hard to duplicate the problem on that unit.

 Marvell now has example of a working unit with the USB splice mods and
 I've discussed with Ronak how to make the mods ever more robust with any
 of the other units they modify.  They are going to try and fix the broken
 one I brought and rework the B4 that they previously modified.

 Marvell had other B4's and the first one we tried duplicated the problem
 nicely.  We then had that unit loaded with a wireless JTAG connector.
 We caused the failure and Javier inspected the state of the wireless
 firmware.

 The issues we are seeing do not appear to be the result of the firmware or
 the kernel doing bad things _directly_.  The firmware appears to be in the
 proper state waiting for a command from the host that never makes it.
 This jives with what we have seen so far on the USB analyzer.
 If its a software problem then its really subtle and sneaky.

 The error bit on the host controller seems to point to some sort of
 problem on the USB bus but so far nothing in any USB trace has shown
 errors.  It's very confusing because the EHCI spec indicates that these
 are all protocol errors.  Timing, CRC, or Pid.

 Today before my flight Ronak and I are going to spend a bit of time with
 the USB expert here at Marvell and repeat the failure on the B4 with the
 USB analyzer hooked up to it using Marcelo's infinite USB retry version.

 Yesterday we did not get to involve the USB expert because we had no clear
 failure case until very late in the day.

 Now that we have a much clearer idea of what the failure is and how to
 cause it we hope that we can get better data back from the analyzer.  If
   not then this problem must be looked at by a signal level analyzer and
 not just a protocol analyzer.  One that can directly tap onto the signals
 rather than having to go in line.
 }}}

-- 
Ticket URL: <https://dev.laptop.org/ticket/2621#comment:10>
One Laptop Per Child <http://laptop.org/>



More information about the Bugs mailing list