> But yes, if the last TD in a URB is a multi TRB isoc TD, and it has > an error MID TD then its stuck until timeout. If there are timeouts to deal with hosts failing to respond then that's good enough for me. It should be a rare case anyway. I just don't like when stuff locks up forever and requires reconnection or reboot to clean up. > > Would it be possible to retire the TD right after the first failed > > TRB? > > Probably not as a normal error handling routine. > We have the same "Transfer event TRB DMA ptr not part of current TD" > issue for hosts that do issue an event for the last TRB. Obviously it would require keeping some information about the retired TD to detect subsequent completions and to prevent freeing of its remaining TRBs. Probably much more effort than the current approach. > But for that special case where there are no more TDs queued it might > make sense Wouldn't it still require remembering not to free the TRBs too fast? (It seems to have worked in the early days, but feels dodgy). > + xhci_dbg(xhci, "Missing completion event after mid TD error\n"); On second thought, this could also print ep_trb_dma to be useful in debugging "TRB not part of current TD" issues. Although anyone able to compile the kernel with DYNAMIC_DEBUG could also edit as necessary...
