On 23.12.2021 15.26, Wohl, Tobias wrote: > Hi all, Hi > > I noticed a strange beavior when unplugging USB3 sticks. I'm using a zynq ultrascale + platform and the problem > still occured when testing with 5.16-rc6 kernel. Does older kernels have the same issue? > > In some cases when unplugging the USB3 stick it takes aroung 10s until the disconnect is detected. > Moreover after unplugging the usb driver ends up in a endless loop of trying to perform "warm resets". > After replugging the USB stick, the loop stops and everything seems to be fine again. This only happens > with USB3 sticks. > There's been a couple reports like this. I saw you noticed the patch in usb-next that solves this by giving the link some time to notice the disconnect, and automatically go to RxDetect from inactive state, thus avoiding unnecessary warm reset of disconnected devices. Seems it works for some cases, but not all. > The kernel log looks as follows: > > [ 1831.312566] handle_port_status: xhci-hcd xhci-hcd.0.auto: Port change event, 2-1, id 2, portsc: 0x4012c1 > [ 1831.312583] handle_port_status: xhci-hcd xhci-hcd.0.auto: handle_port_status: starting port polling. > [ 1831.312853] hub_event: hub 2-0:1.0: state 7 ports 1 chg 0000 evt 0002 > [ 1831.312874] xhci_hub_control: xhci-hcd xhci-hcd.0.auto: Get port status 2-1 read: 0x4012c1, return 0x4002c1 > [ 1831.312899] port_event: usb usb2-port1: link state change > [ 1831.312912] xhci_clear_port_change_bit: xhci-hcd xhci-hcd.0.auto: clear port1 link state change, portsc: 0x12c1 12c1 = Connected, Disabled, Link:Inactive > [ 1831.312929] port_event: usb usb2-port1: do warm reset ... > [ 1831.379730] xhci_hub_control: xhci-hcd xhci-hcd.0.auto: Get port status 2-1 read: 0x12b1, return 0x2b1 12b1 = Connected, Disabled, reset asserted, Link: Rx Detect. (Link value is unreliable while reset is asserted) ... > [ 1831.447759] hub_port_wait_reset: usb usb2-port1: not warm reset yet, waiting 200ms > [ 1831.655731] xhci_hub_control: xhci-hcd xhci-hcd.0.auto: Get port status 2-1 read: 0x12f1, return 0x2f1 12f1 = Connected, Disabled, reset asserted, Link: Polling. (Link value is unreliable while reset is asserted) > [ 1831.863726] xhci_hub_control: xhci-hcd xhci-hcd.0.auto: Get port status 2-1 read: 0x2812e1, return 0x3002e1 Connected, Disabled, Link: Polling, Warm reset change, reset changed The odd thing here is that the "connected" bit remains set the whole time. Other reports had a bit different symptoms after not detecting disconnect, such as reset asserted bit being stuck forever. In xhci specs 4.19.1.2 "USB3 root hub port" Figure 4-27 it shows that when link goes to the Error "link:inactive" state it should drop the connected bit as well. http://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/extensible-host-controler-interface-usb-xhci.pdf (four bits in the figure are Port Power(PP), Current Connect status (CCS), Port Enabled/Disabled (PED), and Port Reset (PR). Those should be set to (1,0,0,0) once entering the Error "inactive" state. No idea why CCS bit is still set for you? Is the device connected to a USB-C port or a "A" port? Can there be some retimer/redriver mux or something else between port and xHCI that messes up disconnect detection? -Mathias
