Hi Alan, > 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. Yes, the io_watchdog timer will cleanup the isoc periodically as long as isoc_count > 0. I did see all of the linked itds are pending there in my case at the end. After my debug, I found the chipidea/host.c had set ehci->need_io_watchdog to 0 which will have impact on turn_on_io_watchdog(). The host has enabled 1 intr endpoint and 2 isoc endpoints from USB camera. Therefore, ehci->intr_count is always 1 and ehci->isoc_count is changing from time to time during camera is running. When PE is cleared by HW, isoc_count may be decreased to 0 after scan_isoc(). When turn_on_io_watchdog() is called, EHCI_HRTIMER_IO_WATCHDOG event will not be enabled due to isoc_count=0 and need_io_watchdog=0 too. When isoc urb is submited again, enable_periodic() will still not enable EHCI_HRTIMER_IO_WATCHDOG event due to periodic_count>0. Then, the linked itds are pending there as long as intr urb has not been completed. Thanks, Xu Yang > > > 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
