On Sat, Mar 15, 2014 at 08:31:29AM +1100, Benjamin Herrenschmidt wrote: > On Fri, 2014-03-14 at 18:16 -0300, Thadeu Lima de Souza Cascardo wrote: > > What seems to happen for the TI chip is that while the HID device is > > still connected (ie, we still have pending URBs on the queue), halting > > is not a great idea. And as described above, what is done right now > > is: > > Can you tell us more about what "not a great idea" means ? :-) > > IE, we have experienced actual errors, hangs and/or kexec failures > right ? You should describe them so people like Sarah can understand > better what's going on and why it's a problem. > Right, I forgot about that. And it should probably be in the commit log. As far as I know, we don't get system hangs. What we get are probe failures for the PCI adapter. Since the halt will be executed during remove/shutdown, that can happen for kexec, rmmod or simply unbind. During remove/shutdown, the halt fails as follows: [ 825.368410] xhci_hcd 0003:03:00.0: remove, state 4 [ 825.368606] xHCI xhci_drop_endpoint called for root hub [ 825.368609] xHCI xhci_check_bandwidth called for root hub [ 825.402070] xhci_hcd 0003:03:00.0: Host not halted after 16000 microseconds. [ 825.402098] xhci_hcd 0003:03:00.0: USB bus 2 deregistered [ 825.402486] xhci_hcd 0003:03:00.0: remove, state 1 [ 830.407500] xhci_hcd 0003:03:00.0: xHCI host not responding to stop endpoint command. [ 830.407505] xhci_hcd 0003:03:00.0: Assuming host is dying, halting host. [ 830.440823] xhci_hcd 0003:03:00.0: Host not halted after 16000 microseconds. [ 830.440830] xhci_hcd 0003:03:00.0: Non-responsive xHCI host is not halting. [ 830.440833] xhci_hcd 0003:03:00.0: Completing active URBs anyway. [ 830.440851] xhci_hcd 0003:03:00.0: HC died; cleaning up [ 830.768535] xHCI xhci_drop_endpoint called for root hub [ 830.768539] xHCI xhci_check_bandwidth called for root hub [ 830.801749] xhci_hcd 0003:03:00.0: Host not halted after 16000 microseconds. [ 830.801753] xhci_hcd 0003:03:00.0: Host controller not halted, aborting reset. [ 830.801960] xhci_hcd 0003:03:00.0: USB bus 1 deregistered After that, probe will either get us an EEH, or the following: [ 877.080018] xhci_hcd 0003:03:00.0: xHCI Host Controller [ 877.080463] xhci_hcd 0003:03:00.0: new USB bus registered, assigned bus number 1 [ 877.112931] xhci_hcd 0003:03:00.0: Host not halted after 16000 microseconds. [ 877.112935] xhci_hcd 0003:03:00.0: can't setup [ 877.112941] xhci_hcd 0003:03:00.0: USB bus 1 deregistered [ 877.113203] xhci_hcd 0003:03:00.0: init 0003:03:00.0 fail, -110 [ 877.113221] xhci_hcd: probe of 0003:03:00.0 failed with error -110 Regards. Cascardo. > > 1) disconnect USB 3.0 devices > > 2) halt > > 3) disconnect USB 2.0 devices > > 4) halt and cleanup > > > > What I do is avoid halting before we disconnect the USB 2.0 devices. > > > > We know that xhci_only_stop_hcd is only called for the secondary for > > which there is a primary with the same xhci. Much of that information > > is > > on the xhci driver itself, so we are not working around the upper > > layer > > more than the driver already is. > > > > One option we have to be too much invasive here with other chipsets is > > skip the halt only for the TI host card, by using a new quirk. > > Cheers, > Ben. > > -- 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
