Re: USB lockup

[Edgar Fuß <ef%math.uni-bonn.de@localhost>]

I looked into the usbhist now.

> is something being aborted?
Yes.

> I guess the E20 TD got written out with incorrect next_td, or some other
> error condition caused the mixup.
I think the only sane explanation absent a controller bug is that, at the 
time the HC finished E20, HcDoneHead was FA0 (41088FA0, really; note there 
are other TDs xxxFA0, which I ignore here). Since the "real" FA0 (which is 
the "tail" part of the transfer just initiated comes after E20, the HC must 
have finished a "different" FA0. As I added checks for a second TD being 
queued with the same physaddr that didn't fire, the HCD must have previously 
dequeued the FA0 TD. So my guess is that the HC and the HCD, prior before 
the E20->EE0->FA0->F40->0 chain is queued, disagree on whether FA0 is still 
active (i.e. under the HCs control) or not (i.e. under the HCDs control).

> The change I referred to was
Would you expect that change (maybe after some munging) to work with -8?

> In PR/22646 some TDs can be on the done queue when the abort start and,
If that "done queue" is in the HcDoneHead sense, not the HccaDoneHead sense, 
then, I guess, it would exactly fit what I think is going on.

> if this is the case, they need to processed after the WDH interrupt.
> Instead of waiting for WDH we release TDs that have been touched by the
> HC and replace them with new ones.  Once WDH happens the floating TDs
> will be returned to the free list.
I still need to understand how exactly that works. Could you give me a hint 
what these "referenced by" pointers are needed for?
My first idea would be to, when aborting, not to actually de-queue the std's, 
but just mark them as aborted (in the std outside the td, of course) and, 
when encountering such a std in the softint, just de-queue and otherwise 
skip them. I'm afraid I'm missing something and that won't work.