Hi, Felipe Balbi <felipe.ba...@linux.intel.com> writes: > Hi Mathias, > > So the problem I found with v4.10-rc1 doesn't appear to be a > regression. I can't, however, trigger it with Broadwell, only Skylake > and Kabylake. > > According to tracepoints, our Reset Device Command sometimes completes > with "Context State Error", which tells us that we're issuing Reset > Device Command when we shouldn't. > > Another thing I noticed is that we're clearing PortFeature(PortReset) > less than 20ms after setting it. Full tracepoint data attached (slot 28
actually, this is not a problem. Reset is supposed to be 10ms minimum. >> device-reset-2819 [002] d..1 154.868782: xhci_queue_trb: CMD: Reset >> Device Command: slot 28 flags C >> <idle>-0 [003] d.h2 154.868832: xhci_handle_event: EVENT: TRB >> 00000001be2b2e60 status 'Context State Error' len 0 slot 28 ep 0 type >> 'Command Completion Event' flags e:C > > And here's xHCI telling us that slot 28's Context was is invalid status. I traced this down to Slot being in Default state. According to Figure 10 Slot State Diagram, Reset Device is only allow from Configured or Addressed. Any other states, Reset Device is invalid and shouldn't be issued. Now I'm wondering whether we should hide this fact from USB Core, or do we have a bigger problem with USB Core itself. Alan, Mathias; any ideas? -- balbi
signature.asc
Description: PGP signature
