Hi Mathias, On Fri, Dec 16, 2022 at 12:13:23PM +0200, Mathias Nyman wrote: > On 15.12.2022 18.12, Ladislav Michl wrote: > > +Cc Mathias as he last touched this code path and may know more :) > > > > On Tue, Dec 06, 2022 at 02:17:08PM +0100, Ladislav Michl wrote: > > > On Mon, Dec 05, 2022 at 10:27:57PM +0100, Ladislav Michl wrote: > > > > I'm running current linux.git on custom Marvell OCTEON III CN7020 > > > > based board. USB devices like FTDI (idVendor=0403, idProduct=6001, > > > > bcdDevice= 6.00) Realtek WiFi dongle (idVendor=0bda, idProduct=8179, > > > > bcdDevice= 0.00) works without issues, while Ralink WiFi dongle > > > > (idVendor=148f, idProduct=5370, bcdDevice= 1.01) kills the host on > > > > disconnect: > > > > xhci-hcd xhci-hcd.0.auto: xHCI host not responding to stop endpoint command > > > > xhci-hcd xhci-hcd.0.auto: xHCI host controller not responding, assume dead > > > > xhci-hcd xhci-hcd.0.auto: HC died; cleaning up > > > > > > > > Unfortunately I do not have a datasheet for CN7020 SoC, so it is hard > > > > to tell if there is any errata :/ In case anyone see a clue in debug > > > > logs bellow, I'll happily give it a try. > > > > > > So I do have datasheet now. As a wild guess I tried to use dlmc_ref_clk0 > > > instead of dlmc_ref_clk1 as a refclk-type-ss and it fixed unplug death. > > > I have no clue why, but anyway - sorry for the noise :) Perhaps Octeon's > > > clock init is worth to be verified... > > > > After all whenever xhci dies with "xHCI host not responding to stop endpoint > > command" depends also on temperature, so there seems to be race somewhere. > > > > As a quick and dirty verification, whenever xhci really died, following patch > > was tested and it fixed issue. It just treats ep as if stop endpoint command > > succeeded. Any clues? I'll happily provide more traces. > > It's possible the controller did complete the stop endpoint command but driver > didn't get the interrupt for the event for some reason. Hmm, event did not complete for device directly connected to the xHCI port. However for the same device connected to the HUB, everything works as expected no matter if device is disconnected from the HUB or the HUB with device is disconnected altogether. > I wrote some patches that checks the event ring for this event during > timeout. In case device is plugged back before timeout kills xHCI, controller is still working reliably. > code is in a stop_endpoint_fixes branch in my tree: > > git://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git stop_endpoint_fixes > https://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git/log/?h=stop_endpoint_fixes > > Another thing would be checking command and event rings for this stop endpoint command. > So Instead of killing host at timeout, do nothing, and check sysfs after the disconnect: > > cat /sys/kernel/debug/usb/xhci/<address>/event-ring/trbs > cat /sys/kernel/debug/usb/xhci/<address>/command-ring/trbs > > -Mathias
