On Thu, 8 Sep 2016, Mathias Nyman wrote: > > ehci-hcd includes checks in several places for ehci->rh_state == > > RH_STATE_RUNNING. The removal pathway sets ehci->rh_state to > > RH_STATE_HALTED. As a result, the driver avoids waiting for things > > that will never happen. > > > > Yes, seems that there are two things that need to be done for xhci here. > > First part is doing the similar thing to xhci_urb_dequeue as ehci does, make sure > host is alive before queuing any stop endpoint commands. It does check if PCI reads return > 0xffffffff or host is XHCI_STATE_DYING, but we could detect a remove a lot earlier. There's a big difference between a removal and the host controller dying, because removal can be clean. So as long as the controller is still running okay, you shouldn't skip any steps -- just refuse to accept new URB submissions. But if the controller is gone or dead, then absolutely avoid queuing any new commands. Alan Stern > Second part is to make sure that the canceled URB is given back if the stop endpoint command > times out. > Currently the xhci_stop_endpoint_command_watchdog() function may return without > giving back canceled urbs, causing usb_kill_urb() to wait on wait_event(usb_kill_urb_queue, ..) forever with > locks held, blocking the pci remove thread. > > I'll start writing a patch > > -Mathias > > -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
