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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
