On Sat, Jul 29, 2023 at 06:55:07AM +0000, Xu Yang wrote: > Many thanks for your comments and suggestions. > > Yes, there is a "live" variable in scan_isoc() to handle the case where > root hub has stopped periodic schedule. I have rechecked the root cause > of the issue , that is the USB controller has disabled the port (PE cleared) > and asserted USBERRINT when frame babble is detected, but PEC is not > asserted. Therefore, the SW didn't aware that port has been disabled. > The periodic schedule keeps running at this moment. Then the SW keeps > sending packets to this port, but all of the transfers will fail. But periodic > schedule will also be disabled after a period of time. Finally, all of the linked > itds are penging there. The code can't enter into scan_isoc() if only USBERRINT > is asserted. That's not true. The io_watchdog timer continues to fire periodically (at 100 ms intervals) as long as isoc_count > 0. The timer's handler is ehci_work(), which calls scan_isoc() if isoc_count > 0. > For this issue, I think the SW needs to aware that the port has been disabled > although PEC not asserted by HW. I will send another patch to fix this issue > later. Yes, that sounds like a nasty problem. The kernel wouldn't realize that the device had disconnected. Alan Stern
