#1752 BLOC Trial-2: USB wireless suspend/resume failure at setup phase

[Zarro Boogs per Child]

#1752: USB wireless suspend/resume failure at setup phase
-----------------------+----------------------------------------------------
  Reporter:  marcelo   |       Owner:  marcelo
      Type:  defect    |      Status:  new    
  Priority:  blocker   |   Milestone:  Trial-2
 Component:  wireless  |     Version:         
Resolution:            |    Keywords:         
  Verified:  0         |  
-----------------------+----------------------------------------------------
Changes (by jg):

  * priority:  normal => blocker
  * milestone:  Untriaged => Trial-2

Old description:

> Failure at different "commands" of the SETUP phase, such as SetAddress,
> GetDescriptor(Device), GetDescriptor(Configuration).
>
> By analyzing USB traces, we can see that the SETUP transaction for
> these commands is usually successful, but subsequent steps (such as IN
> transactions in response to SETUP, or PING transactions in response to
> OUT) continue to happen for a while and then stop.
>
> 3ms after the last IN or PING transaction is seen, the device is
> supposed to enter suspended state (and the analyzer indicates that with
> "SUSPENDED (IDLE)"). The USB software then receives errors from the EHCI
> controller for these commands.
>
> For the successful case, we see that the host controller has issued
> "non-stop" IN or PING transactions until it got an ACK from the device,
> which prevents the suspended state.
>
> So from my understand of the USB protocol the host controller is at
> fault here, it should issue IN/PING until an ACK is received.
>
> At http://dev.laptop.org/~marcelo/debug/ you can find:
>
> success_2622-rc4.ufo: successfull suspend/resume cycle
>
> set_address_2_failure.ufo: failure at the SetAddress(2) stage.
>
> USB Explorer 200 Windows software available at http://www.ellisys.com
> is necessary to decode the traces.

New description:

 Failure at different "commands" of the SETUP phase, such as !SetAddress,
 GetDescriptor(Device), GetDescriptor(Configuration).

 By analyzing USB traces, we can see that the SETUP transaction for
 these commands is usually successful, but subsequent steps (such as IN
 transactions in response to SETUP, or PING transactions in response to
 OUT) continue to happen for a while and then stop.

 3ms after the last IN or PING transaction is seen, the device is
 supposed to enter suspended state (and the analyzer indicates that with
 "SUSPENDED (IDLE)"). The USB software then receives errors from the EHCI
 controller for these commands.

 For the successful case, we see that the host controller has issued
 "non-stop" IN or PING transactions until it got an ACK from the device,
 which prevents the suspended state.

 So from my understand of the USB protocol the host controller is at
 fault here, it should issue IN/PING until an ACK is received.

 At http://dev.laptop.org/~marcelo/debug/ you can find:

 success_2622-rc4.ufo: successfull suspend/resume cycle

 set_address_2_failure.ufo: failure at the SetAddress(2) stage.

 USB Explorer 200 Windows software available at http://www.ellisys.com
 is necessary to decode the traces.

-- 
Ticket URL: <http://dev.laptop.org/ticket/1752#comment:4>
One Laptop Per Child <http://laptop.org/>