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 > 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
