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
