Re: USB lockup

[Nick Hudson <nick.hudson%gmx.co.uk@localhost>]

On 26/11/2020 20:35, Edgar Fuß wrote:
> > Add a check to ohci_softintr to see if the list goes circular and enter
> > ddb / dump usbhist when it does...
> I already did add a panic and it fired.
>
> I'm still trying to find out how that happens.
>
> What I'm seeing (dumped by device_ctrl_start()) is a chain of four TDs
> (named here after their addresses' three least significant nybbles):
> 	E20->EE0->FA0->F40->0
> which are linked in that sense by both nexttd and td.td_nexttd.
>
> Then, in ohci_softint(), the done queue is (as linked by td.nexttd):
> 	FA0->EE0->E20->FA0->...
> and, as expected, the nexttd links are as before.
> Absent the E20->FA0 link, that's exactly what one would expect if the first
> three TDs have been handled (the done list is most recently done first);
> the big question is where that additinal link comes from.
>
> I've added code to ohci_hash_add_td() to catch a TD being added with a
> physical address already present in the hash list, but that didn't fire.


Really hard to help without seeing the full ohcidebug usbhist log. I
guess the E20 TD got written out with incorrect next_td, or some other
error condition caused the mixup.

The change I referred to was

Revision 1.254.2.76 / (download) - annotate - [select for diffs], Mon
May 30 06:46:50 2016 UTC (4 years, 5 months ago) by skrll
Branch: nick-nhusb
Changes since 1.254.2.75: +181 -48 lines
Diff to previous 1.254.2.75 (colored) to branchpoint 1.254 (colored)

Restructure the abort code for TD based transfers (ctrl, bulk, intr).

In PR/22646 some TDs can be on the done queue when the abort start and,
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.


is something being aborted?

Nick