On Thu, May 12, 2016 at 02:07:41PM +0300, Mathias Nyman wrote: > If commands timeout we mark them for abortion, then stop the command > ring, and turn the commands to no-ops and finally restart the command > ring. > > If the host is working properly the no-op commands will finish and > pending completions are called. > If we notice the host is failing driver clears the command ring and > completes, deletes and frees all pending commands. > > There are two separate cases reported where host is believed to work > properly but is not. In the first case we successfully stop the ring > but no abort or stop commnand ring event is ever sent and host locks up. > > The second case is if a host is removed, command times out and driver > believes the ring is stopped, and assumes it be restarted, but actually > ends up timing out on the same command forever. > If one of the pending commands has the xhci->mutex held it will block > xhci_stop() in the remove codepath which otherwise would cleanup pending > commands. > > Add a check that clears all pending commands in case host is removed, > or we are stuck timeouting on the same command. Also restart the > command timeout timer when stopping the command ring to ensure we > recive an ring stop/abort event. > > Cc: stable <stable@xxxxxxxxxxxxxxx> > Signed-off-by: Mathias Nyman <mathias.nyman@xxxxxxxxxxxxxxx> Any reason why you just sent this to stable@ and not linux-usb@? -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html