On Thu, 29 May 2014, Dan Williams wrote: > Resuming a powered down port sometimes results in the port state being > stuck in the training sequence. > > hub 3-0:1.0: debounce: port 1: total 2000ms stable 0ms status 0x2e0 > port1: can't get reconnection after setting port power on, status -110 > hub 3-0:1.0: port 1 status 0000.02e0 after resume, -19 > usb 3-1: can't resume, status -19 > hub 3-0:1.0: logical disconnect on port 1 > > In the case above we wait for the port re-connect timeout of 2 seconds > and observe that the port status is USB_SS_PORT_LS_POLLING (although it > is likely toggling between this state and USB_SS_PORT_LS_RX_DETECT). > This is indicative of a case where the device is failing to progress the > link training state machine. > > It is resolved by issuing a warm reset to get the hub and device link > state machines back in sync. > > hub 3-0:1.0: debounce: port 1: total 2000ms stable 0ms status 0x2e0 > usb usb3: port1 usb_port_runtime_resume requires warm reset > hub 3-0:1.0: port 1 not warm reset yet, waiting 50ms > usb 3-1: reset SuperSpeed USB device number 2 using xhci_hcd > > After a reconnect timeout when we expect the device to be present, force > a warm reset of the device. Note that we can not simply look at the > link status to determine if a warm reset is required as any of the > training states USB_SS_PORT_LS_POLLING, USB_SS_PORT_LS_RX_DETECT, or > USB_SS_PORT_LS_COMP_MOD are valid states that do not indicate the need > for warm reset by themselves. Acked-by: Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> -- 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
