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
I need to do some more reading and investigating stillon this still.
-Mathias
I'm not sure whether the problem is a non compliant USB-Sata bridge
(probably a JMicron) or bad timing, bad FSM implementation or something
else, but I would like to determine the cause to either solve the
problem or steer away from this vendor in the future. Please note the
this issue is not distribution specific and is affecting a lot of people
and other manufacturers as well, e.g.:
https://bugzilla.novell.com/show_bug.cgi?id=922634
https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/792085
https://bugzilla.redhat.com/show_bug.cgi?id=1278944
Here you can find a few captures with Wireshark on both Ubuntu Linux
(3.13.0 & 4.4.0) and Windows 10:
https://drive.google.com/open?id=0B2tgr9hETOtgbVFvdExQZkpTQmc
However USBPcap for Windows cannot capture a bunch of relevant messages,
so there is almost nothing to see when detaching. Under Linux, USB 3.0
seems to be chattier than 2.0 after the SCSI START STOP UNIT command.
Any suggestion on how to investigate the issue is very welcome.
Thank you,
Regards
--
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
--
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
