On 08.09.2016 17:38, Alan Stern wrote:
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.
I've been staring at the code for a while and I think xhci might need a bigger
rework in this area.
For example the XHCI_STATE_DYING flag was originally a flag meaning that a
watchdog function for a timed out stop endpoint command is running and all
URBs will be given back.
Since then this flag has been used when host is no longer responding.
The rework will take some time, I think I'll do a quick fix to just prevent the
deadlock. That fix could go in quicker and to stable while polishing the rework
-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
