Created attachment 73356 [details] cpuinfo, modules, ioports, iomem, lspci, scsi info This is in a Vantec CB-ISATAU3, an IDE/SATA USB3.0 adapter. It works fine in USB 2.0 mode, but it does not work in USB 3.0. dmesg | tail gives: "[ 2956.564327] usb 9-2: Device not responding to set address. [ 2956.768312] usb 9-2: Device not responding to set address. [ 2956.972018] usb 9-2: device not accepting address 19, error -71 [ 2957.084328] usb 9-2: Device not responding to set address. [ 2957.288313] usb 9-2: Device not responding to set address. [ 2957.492021] usb 9-2: device not accepting address 20, error -71 [ 2957.604318] usb 9-2: Device not responding to set address. [ 2957.808313] usb 9-2: Device not responding to set address. [ 2958.012028] usb 9-2: device not accepting address 21, error -71 [ 2958.012040] hub 9-0:1.0: unable to enumerate USB device on port 2" lsusb doesn't list any new devices on USB 3.0 mode, but in USB 2.0 mode: "Bus 002 Device 005: ID 067b:2773 Prolific Technology, Inc." The controller seems to be Prolific Technology PL2773. lsb_release -rd: "Description: Ubuntu 12.04 LTS Release: 12.04" lsusb (usbutils) 005 Originally tested in kernel 3.2.0, also tested in 3.4.0, same results. Thank you.
Hi Mark, Can you reload the USB core with this modprobe command: sudo modprobe usbcore old_scheme_first=1 use_both_schemes=0 Then start capturing dmesg, and plug the device into your USB 2.0 port. I see you have an EHCI controller, so you should have some non-USB 3.0 ports. USB 3.0 ports are usually blue inside. I'm wondering if your device needs a Get Descriptor control transfer before it will accept a Set Address control transfer. That's the sequence that Windows uses, but under a Linux xHCI host controller, we always do a Set Address before a Get Descriptor. If your device does need a Get Descriptor control TX before it will respond to the Set Address command, I will need to create some new xHCI API to allow the USB core to request that a Set Address xHCI command not actually send the Set Address control transfer. I'll probably need to ask you to apply a patch and recompile your kernel. Are you comfortable with that? Thanks, Sarah Sharp
Thank you for responding Sarah! After executing sudo modprobe usbcore old_scheme_first=1 use_both_schemes=0 then plugging the device into a USB 2.0 port, dmesg reads: "[ 148.848044] usb 2-4: new high-speed USB device number 3 using ehci_hcd [ 148.988914] scsi8 : usb-storage 2-4:1.0 [ 149.988625] scsi 8:0:0:0: Direct-Access SAMSUNG SP2514N VF10 PQ: 0 ANSI: 0 [ 149.989168] sd 8:0:0:0: Attached scsi generic sg3 type 0 [ 149.991495] sd 8:0:0:0: [sdc] 488397168 512-byte logical blocks: (250 GB/232 GiB) [ 149.992234] sd 8:0:0:0: [sdc] Write Protect is off [ 149.992238] sd 8:0:0:0: [sdc] Mode Sense: 03 00 00 00 [ 149.992982] sd 8:0:0:0: [sdc] No Caching mode page present [ 149.992986] sd 8:0:0:0: [sdc] Assuming drive cache: write through [ 149.995240] sd 8:0:0:0: [sdc] No Caching mode page present [ 149.995243] sd 8:0:0:0: [sdc] Assuming drive cache: write through [ 150.002004] sdc: sdc1 [ 150.004874] sd 8:0:0:0: [sdc] No Caching mode page present [ 150.004877] sd 8:0:0:0: [sdc] Assuming drive cache: write through [ 150.004879] sd 8:0:0:0: [sdc] Attached SCSI disk [ 150.256267] EXT4-fs (sdc1): mounted filesystem with ordered data mode. Opts: (null) [ 150.259497] init: ureadahead-other main process (2914) terminated with status 2" The drive connected to this device mounts and seems to work as normal, albeit at USB 2.0 speeds. I don't have too much experience recompiling a kernel and none at all applying a patch, but I'll do some research. It may take me a few days to figure it all out. Thank you.
Mark reports this is a device issue, not an xHCI driver issue. "...now I have a way to get it to work consistently - plug it in, turn the power on, let it fail, remove and replug the USB cable." Greg, can you close this bug?
Now closed.
Hi Marc, maybe you could download the "MultiPort Configure Eep" utility from http://prolificusa.com/portfolio/pl-2773-usb3-0-esataii-to-sataii-bridge-controller/, click "EEPROM edit" (don't worry it won't write, it just opens a new window) and in the new window click "Read chip". Then maybe you can tell us the version of the firmware. Maybe you can try a firmware update but for me versions 20110114 (in USBto2xSATA) and 20110316 (in USBto1xSATA+1xIDE) worked fine for me. At least for the 2xSATA you need to enable SCSI MULTILUN device probing to access both devices. Maybe it helps you somehow. Martin
Hello Martin: I didn't see your comments because they occurred after the bug was closed. However I see them now - thank you! The device is now no longer working for me at all, even using my little workaround. It always fails on USB 3.0 and will only run once or twice on USB 2.0 before failing there as well. A reboot won't allow it to recover either. So rather than throw it out, I decided to take a look at the firmware as you suggest. The firmware was reported as 20110316. Using Prolific's EEPROM reader/writer I flashed the latest firmware (20120326) and it seemed to proceed fine but their tool still reports the old 20110316 firmware. There has been no change in operation unfortunately - I still can no longer get it to work at all in either USB 2.0 or USB 3.0. And now the drive no longer even spins up, I get nothing but the power light on USB 2.0, on USB 3.0 the USB 3.0 light flashes quickly but the drive doesn't spin up. I must have corrupted the firmware because the device is no longer detected on Linux or Windows. I'll be throwing it out and chalking it up to experience. Incidentally this is the USB to 1XSATA/1XIDE device. Thank you for your assistance, I wish it would have worked.
I can only recommend to buy this: http://www.manhattan-products.com/en-US/products/9235-superspeed-usb-to-sata-adapter (MANHATTAN SuperSpeed USB to SATA Adapter). I evaluated it to be the very best on the market last April and so far bought about 6pcs already. Ah, you need IDE. Hmm, I am so far happy with Initio 1530 -based controller providing USB2.0&FW1394 interfaces in one Akasa drive enclosure: http://www.akasa.com.tw/update.php?tpl=product/product.detail.tpl&no=181&type=Enclosures&type_sub=2.5 Enclosure&model=AK-ENP2CB-BL
Created attachment 109531 [details] New cpuinfo, modules, ioports, iomem, lspci, scsi info I almost forgot about all this - I never could get that adapter working and disposed of it recently. However I got a new, different device and the same problem popped up again. dmesg: "[246488.257409] usb 9-1: Device not responding to set address. [246488.461005] usb 9-1: Device not responding to set address. [246488.664304] usb 9-1: device not accepting address 6, error -71 [246488.720252] hub 9-0:1.0: unable to enumerate USB device on port 1" which does not repeat unlike the adapter. This device is totally different, a Kingston FCR-HS3 USB 3.0 card reader. It works fine in USB 2.0 - lsusb shows: "Bus 002 Device 003: ID 11b0:6348 ATECH FLASH TECHNOLOGY" lsb_release -rd "Description: Ubuntu 13.04 Release: 13.04" lsusb -V "lsusb (usbutils) 005" uname -a "Linux Sauron 3.8.0-30-generic #44-Ubuntu SMP Thu Aug 22 20:52:24 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux" Given that I get exactly the same behaviour from two completely different devices, I suspect it's the 3rd party USB 3.0 controller on the motherboard, an ASMedia 1040. It seems to be picky about devices, I have an ADATA 16 GB USB 3.0 flash drive that works perfectly with it and recently acquired a Western Digital Elements SE 500 GB USB 3.0 drive that also works fine. I'm not sure how to isolate the problem to the xHCI driver or the firmware in the controller.
Well it definitely seems to be the ASMedia 1040 controller that's at fault. Today I changed the motherboard for this and other reasons. The new motherboard has a VIA VL805 USB 3.0 controller, and that finnicky Kingston FCR-HS3 USB 3.0 card reader works perfectly every time (as do all my other USB 3.0 devices). Since I no longer have the original adapter I can't verify whether it works with the VIA VL805 but I have a strong feeling that it would. ASMedia's current USB 3.0 controller is the 1042 so it's doubtful whether the discontinued 1040 will ever see a firmware update that corrects this buggy behaviour. I've changed the bug status to "resolved" - "will not fix" because this behaviour seems clearly due to the host controller firmware.