On Tue, 2020-06-30 at 17:27 +0300, Mathias Nyman wrote: > On 30.6.2020 16.08, Rik van Riel wrote: > > I misread the code, it's not a bitfield, so state 1 means an > > endpoint marked with running state. The next urb is never getting a > > response, though. > > > > However, the xhci spec says an endpoint is halted upon a babble > > error. > > I was looking at the same, so according to specs this state shouldn't > be possible. The PCM2903B chip, and potentially the hub it is behind, are USB2 devices, though. Does USB2 know about halted endpoints? > > The code right above the babble handling case adds halted into the > > endpoint state itself. Does the code handling the babble error need > > to do something similar to trigger cleanup elsewhere? > > It's a flag to prevent ringing the doorbell for a halted endpoint. > Anyway, reset endpoint is meant to recover an endpoint in a halted > state. > Resetting non-halted endpoints will just lead to a context state > error, and > besides, isoc endpoints shouldn't halt. > > Anyways, I haven't got any better idea at the moment. > You can try and see what a forced reset does with: So close. Looks like something in the XHCI/USB stack isn't doing the reset because something is in an unexpected state? [ 51.706798] xhci_hcd 0000:00:14.0: WARN Set TR Deq Ptr cmd failed due to incorrect slot or ep state. [ 51.706802] got overflow, ep->flags = 2 [ 51.932550] usb 3-9.7.5: reset high-speed USB device number 18 using xhci_hcd [ 68.830396] xhci_hcd 0000:00:14.0: WARN Set TR Deq Ptr cmd failed due to incorrect slot or ep state. [ 68.830409] got overflow, ep->flags = 2 [ 70.077981] rfkill: input handler disabled [ 157.992374] got overflow, ep->flags = 2 [ 157.992406] xhci_hcd 0000:00:14.0: WARN Set TR Deq Ptr cmd failed due to incorrect slot or ep state. > diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci- > ring.c > index 2c255d0620b0..d79aca0df6d4 100644 > --- a/drivers/usb/host/xhci-ring.c > +++ b/drivers/usb/host/xhci-ring.c > @@ -1900,8 +1900,7 @@ static int > xhci_requires_manual_halt_cleanup(struct xhci_hcd *xhci, > * endpoint anyway. Check if a babble halted the > * endpoint. > */ > - if (GET_EP_CTX_STATE(ep_ctx) == EP_STATE_HALTED) > - return 1; > + return 1; > > return 0; > } > > Traces also showed thet endpoint doorbell was rang after th babble > error, so > we know that didn't help restarting the endpoint. > > -Mathias > -- All Rights Reversed.
Attachment:
signature.asc
Description: This is a digitally signed message part
