Hi, Thank you for the review. Michał Pecio <michal.pecio@xxxxxxxxx> 於 2024年10月28日 週一 下午5:54寫道： > > Hi, > > That's a bug I'm familiar with. > > > Unplugging a USB3.0 webcam while streaming results in errors > > like this > > Not only unplugging but also any random error due to EMI or bad cable. > > > If an error is detected while processing an one-TRB isoc TD, > > the Etron xHC generates two transfer events for the TRB that > > the error was detected on. The first event is "USB Transcation > > Error", and the second event is "Success". > > IIRC, it wasn't just Transaction Errors but any sort of error, like > Babble or Bandwidth Overrun. But not sure about Missed Service, etc. > > And IIRC I confirmed that it was *not* the case on Short Packet. Yes, it is not. > > Also, I'm 99% sure the problem is not limited to one-TRB TDs, but > it occurs every time there is an error on the last TRB of any TD. Yes, this can happen, I didn't account for this scenario. > > > As a solution, we can set the flag after the first error event > > and don't print the error message after the second event if the > > flag is set. > > Yes, but I think it would be better to use error_mid_td instead of > last_td_was_short, so that the TD is only freed on the final event, > not on the first one. > > The spec is clear that we should only free TRBs when the xHC is done > with them. Maybe it wouldn't be a problem in this case, and it surely > wouldn't be worse than what happens with Etron today, but IMO it could > be a real (even if rare) problem in other cases when this flag is used, > so I would rather remove the flag and handle short packets as per spec. Thank you for the explanation and suggestion. Maybe I should start trying to use error_mid_td to solve this problem. > > Regards, > Michal Thanks, Kuangyi Chiang
