On Fri, 1 Jan 2021 20:13:02 +0000 Mikolaj Kucharski <[email protected]> wrote:
> On Fri, Jan 01, 2021 at 06:56:21PM +0100, Marcus Glocker wrote: > > It looks like with xhci(4) for some reason the bulk endpoints are > > stalling after some operations, which isn't happening with ehci(4). > > I currently can't see why this happens only with xhci(4). That's > > why on your second attempt you see the timeouts happening, because > > the bulk endpoints still are in a stalled state. > > > > Using usbd_clear_endpoint_stall() at the pipe closing routine simply > > resets all the endpoints, which is why on the next attempt the > > transfers are working fine again. That's probably why this was > > called a workaround, because we should understand why the endpoints > > are getting stalled in a first line with xhci(4). > > > > I can't tell why the issue disappears on your end when you use > > debugging printfs in xhci_device_generic_start(). Looks like a > > timing thing. If you like you can share your xhci(4) debugging > > diff, and I'll check if I can see the same effect here. > > > In function xhci_device_generic_start() there are three printfs marked > with `XXX slow XXX` comment and in blow diff only last one is > commented out and that one is enough to make the problem go away. I > think any of those tree `slow` printf() instances makes the problem > go away. > > Please bare in mind `if (MMM_endpt == 0x88)` which narrow some printfs > only to this specific endpoint. > > Hope that helps. If you need any more info, please let me know. Thanks for the diff. On my side it makes no difference when I run with the whole diff, also in-commenting all printfs. Therefore I don't think this is a timing issue as such. Why it makes a difference on your side I can't tell ...
