Re: [RFC RESEND PATCH 0/1] USB EHCI: repeated resets on full and low speed devices
From: Alan Stern
Date: Tue Sep 01 2020 - 12:19:54 EST
On Tue, Sep 01, 2020 at 08:51:14AM -0700, Khalid Aziz wrote:
> >> At the time of failure, when we reach this conditional, token is
> >> either 0x80408d46 or 0x408d46 which means following bits are set:
> >>
> >> QTD_STS_STS, QTD_STS_MMF, QTD_STS_HALT, QTD_IOC, QTD_TOGGLE
> >>
> >> and
> >>
> >> QTD_PID = 1
> >> QTD_CERR = 3
> >> QTD_LENGTH = 0x40 (64)
> >>
> >> This causes the branch "(token & QTD_STS_MMF) && (QTD_PID(token) ==
> >> PID_CODE_IN" to be taken and qtd_copy_status() returns EPROTO. This
> >> return value in qh_completions() results in ehci_clear_tt_buffer()
> >> being called:
I didn't mention this before, but that combination of events doesn't
make sense. The MMF bit is supposed to get set only for queue heads in
the periodic list, that is, only for interrupt transactions. But
ehci_clear_tt_buffer() doesn't do anything for interrupt endpoints; it
tests specifically for that right at the start.
Maybe your EHCI controller is setting the MMF bit when it shouldn't.
The usbmon output will help clear this up.
Or maybe the hubs you are testing don't work right. That's the only
reason I can think of for the failures you see with the USB-3
controller; the way it operates is very different from the way EHCI
does.
Alan Stern