Re: "Transfer event TRB DMA ptr not part of current TD" spam after USB disconnection

["Michał Pecio" <michal.pecio@gmail.com>]

Thanks for looking at this.

I recognize that the situation is tricky and simply reverting
d104d0152a97f is not a permanent option if other hosts need it.

Yes, I have set up a test machine to debug this and I can use it to
try potential solutions. If you have your own NEC uPD720200 specimen
you could reproduce it yourself, all it takes is unplugging any UVC
isochronous camera while recording with any software. This driver
queues plenty of buffers, so chances of hitting a split TD are good.


Regarding the spec, section 4.10.2 only states that an error shall
generate _a_ Transfer Event on current TRB regargdless of its flags
and that an error may occur on any TRB of a TD.

I think more relevant and useful is the final note in section 4.9.1:

> If an error is detected while processing a multi-TRB TD, the xHC shall
> generate a Transfer Event for the TRB that the error was detected on
> with the appropriate error Condition Code, then may advance to the next
> TD. If in the process of advancing to the next TD, a Transfer TRB is
> encountered with its IOC flag set, then the Condition Code of the
> Transfer Event generated for that Transfer TRB should be Success,
> because there was no error actually associated with the TRB that
> generated the Event. However, an xHC implementation may redundantly 
> assert the original error Condition Code.

To me it looks like the host is expected to skip the remaining TRBs
(section 4.10.2 also mentions continuing to the next ESIT on isoch EPs),
but subsequent text seems to assume that IOC flags will nevertheless be
honored by the xHC (NEC fails here). It is noteworthy that the host is
encouraged to respond "success", so the driver must remember earlier
errors anyway while waiting till the end of the TD.


Regards,
Michal