On Tue, 31 May 2016, Mathias Nyman wrote: > On 30.05.2016 19:39, Alan Stern wrote: > > On Sun, 29 May 2016, Marco Chiappero wrote: > > > >> Hello, > >> > >> I'm experiencing a problem I'm not able to troubleshoot. > >> > >> I own a WD Elements Portable USB 3.0 HDD (WDBU6Y0020BBK) containing a > >> drive model WD20NMVW-11AV3S3. When connected to a USB 3.0 port the drive > >> works perfectly fine until I try to stop and detach the drive from the > >> system, either with gnome-disk-utility or udisksctl: it stops spinning > >> but it restarts soon after and reattaches itself to the system again. > >> The problem does not occur when using a USB 2.0 port and does not occur > >> under Windows 10 with both USB 2.0 and 3.0, spinning down and modifying > >> the led activity accordingly, as expected. > > > > This looks like a problem in the USB-3 link-state management. > > > > Mathias, usb_remove_device() calls hub_port_logical_disconnect(), which > > calls hub_port_disable(), which calls hub_usb3_port_disable(). That > > routine sets the link state to SS_DISABLED, waits for the port to > > enter that state, and then sets the state to RX_DETECT. Next the hub > > is suspended, but about 40 ms later it wakes up again because of a > > connect-change event on the port. You can see all this in the > > Wireshark capture log (the wd_elements-usb3-linux_4.4.0.pcapng file). > > > > This isn't supposed to happen. The intention is that the port will > > remain disabled until the device is unplugged and something is plugged > > back in. But apparently being in the RX_DETECT state causes the port > > to get a connect-change event even though the cable has remained > > plugged into the port the whole time. > > > > So the question is, how do we prevent the port from re-enabling itself > > until the cable has been unplugged? Maybe the port should not be in > > RX_DETECT at all? But then how do we tell when the cable is unplugged? > > > > Alan Stern > > xhci specs say that port will move from Disconnected (PLS = RX_DETECT) to > Polling if "SuperSpeed far-end receiver terminations are detected" > > From power-off state (PP=0) the connect status changes are only reported > if OCA is set so it seems that is not an option. > > I'm looking at the capture log and if I understand it correcty, in frame > 49 SET FEATURE, PLS = ss.disabled (xhci will write PORT_PED bit) > 59 SET FEATURE, PLS = RxDetect (xhci will set pls=RxDetect) > .. get_port_status, nothing set, no changes reported (several of these) > 73 SET FEATURE -> Port remote wake mask > .. get_port status reports Connected, enabled and port status change event > > Could it be that setting the port remote wake mask somehow triggers the > connect status change event? It's the first time we write to PORTSC for > this port after setting link state to rx.detect It's possible, but I doubt it. More likely it just takes a few hundred ms for the RxDetect link training to realize there is a connection. Marco, you can check whether this is true by doing (as root): echo on >/sys/bus/usb/devices/usb4/power/control before starting your test. Alan Stern -- 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
