Hi Mark, Your device sounds really really flaky. There doesn't seem to be a consistent failure mode, and the errors aren't repeatable. I'd actually suggest you return the device and get a different brand. If the device fails to enumerate now like this, who knows how stable it will be in the future? Comments below: On Tue, Jun 12, 2012 at 12:02:03PM -0700, Mark Lanctot wrote: > Hi again Sarah: > > > I would like to clarify that the tests I was doing in our last e-mail (plugging two devices in at the same time) were both done on the USB 3.0 ports attached to the USB 3.0 controller/hub. It didn't matter if the second *device* was USB 2.0 or USB 3.0, I suppose it doesn't matter from an address assignment perspective. But I did not plug anything new into the USB 2.0 ports, I restricted all tests to the two USB 3.0 ports. > > I'll give it a shot and plug a USB device into a USB 2.0 port and see what happens...and the problematic device on the USB 3.0 port won't enumerate. > > OK so with two devices on the USB 3.0 ports and both of them enumerated, lsusb shows: > > "Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub > Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub > Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub > Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub > Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub > Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub > Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub > Bus 008 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub > Bus 009 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub > Bus 004 Device 002: ID 046d:c52b Logitech, Inc. Unifying Receiver > Bus 003 Device 002: ID 058f:6362 Alcor Micro Corp. Flash Card Reader/Writer > Bus 002 Device 004: ID 125f:c08a A-DATA Technology Co., Ltd. > Bus 009 Device 014: ID 067b:2773 Prolific Technology, Inc." > > Bus 4 device 2 and bus 3 device 2 are USB 2.0 devices normally plugged into USB 2.0 ports. Bus 2 device 4 is a USB 2.0 flash drive plugged into the USB 3.0 controller/port, and bus 9 device 14 is the problematic Prolific Technology device plugged into the other USB 3.0 port on the same USB 3.0 controller. I'm really puzzled as to why the USB 2.0 device you plugged into the USB 3.0 port ended up under an EHCI host instead of the xHCI host. The xHCI host is associated with this USB 2.0 and USB 3.0 bus: > Bus 008 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub > Bus 009 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub But you said your USB 2.0 flash drive that was plugged into the USB 3.0 port ended up on a different bus: > Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub > Bus 002 Device 004: ID 125f:c08a A-DATA Technology Co., Ltd. Are you running on an Intel Ivy Bridge system? What is your system configuration? > I observed more strange behaviour from the device - if I plug in another device onto the USB 3.0 port first then plug the problematic device in, it won't enumerate. The problematic device has to be on the USB 3.0 port *first*, then if I plug in a second device it will spontaneously enumerate. Once enumerated this way, it can be removed and reinserted again and again, even after the other device is removed. > > I see that the two devices have non-consecutive addresses, addresses 4 and 14. > > Interestingly I'm trying to get the problematic device to fail again and it isn't, it just keeps on accepting a new address, I see it's now at address 25. However I now see a sure-fire way to get it to stop enumerating - it has its own power adapter and it seems that keeping the power on and removing and reinserting the device works fine once it enumerated successfully. Cycling the power stops the device from enumerating again. dmesg: > > "[172630.480047] usb 9-2: USB disconnect, device number 25 > [172643.740329] usb 9-2: Device not responding to set address. > [172643.944305] usb 9-2: Device not responding to set address. > [172644.148033] usb 9-2: device not accepting address 26, error -71 > [172644.260320] usb 9-2: Device not responding to set address. > [172644.464312] usb 9-2: Device not responding to set address. > [172644.668033] usb 9-2: device not accepting address 27, error -71 > [172644.780321] usb 9-2: Device not responding to set address. > [172644.984312] usb 9-2: Device not responding to set address. > [172645.188030] usb 9-2: device not accepting address 28, error -71 > [172645.300331] usb 9-2: Device not responding to set address. > [172645.504306] usb 9-2: Device not responding to set address. > [172645.708033] usb 9-2: device not accepting address 29, error -71 > [172645.708048] hub 9-0:1.0: unable to enumerate USB device on port 2" Hmm, that sounds like some sort of internal device state problem then. I suppose what you could do is get the device in a state where it accepts the addresses, and then just always leave the power supply plugged in. If it truly is a device state issue, IMO, that is more proof that you really should get a different brand of USB 3.0 hard drive. > Device was at address 25, I disconnected it by turning off the power. Then when I powered it on again it wouldn't accept address 26, 27, 28 or 29 and failed. And as expected, in order to get it to work again I have to plug in another device into the other USB 3.0 port. The problematic device is now at address 30. It continues to behave properly, each unmount and remount increases the address by 1 and it will only stop enumerating once I power-cycle it. > > > OK, it's in the non-enumeration state and I'll turn off auto-suspend. Ugh, this is doing my head in, because it failed once...then worked with no other device on the USB 3.0 hub. Here's dmesg from the point I turned off auto-suspend, it failed, I waited a few seconds and tried again: Hmm, that could be related to the device state issue again. Does it fail consistently when you disable auto-suspend, but unplug and replug the power adapter in between tries? > "[173487.040332] usb 9-2: Device not responding to set address. > [173487.244310] usb 9-2: Device not responding to set address. > [173487.448032] usb 9-2: device not accepting address 38, error -71 > [173487.560327] usb 9-2: Device not responding to set address. > [173487.764309] usb 9-2: Device not responding to set address. > [173487.972037] usb 9-2: device not accepting address 39, error -71 > [173488.084330] usb 9-2: Device not responding to set address. > [173488.288306] usb 9-2: Device not responding to set address. > [173488.492033] usb 9-2: device not accepting address 40, error -71 > [173488.604328] usb 9-2: Device not responding to set address. > [173488.808307] usb 9-2: Device not responding to set address. > [173489.012028] usb 9-2: device not accepting address 41, error -71 > [173489.012042] hub 9-0:1.0: unable to enumerate USB device on port 2 > <turned off auto-suspend, waited and reinserted device> > [173556.124046] usb 2-1: new high-speed USB device number 9 using ehci_hcd > [173556.204051] hub 2-0:1.0: unable to enumerate USB device on port 1 > [173556.444327] usb 9-2: Device not responding to set address. > [173556.648316] usb 9-2: Device not responding to set address. > [173556.852024] usb 9-2: device not accepting address 42, error -71 > [173556.964330] usb 9-2: Device not responding to set address. > [173557.168395] usb 9-2: new SuperSpeed USB device number 43 using xhci_hcd > [173557.186514] scsi18 : usb-storage 9-2:1.0 > [173558.184370] scsi 18:0:0:0: Direct-Access SAMSUNG SP2514N VF10 PQ: 0 ANSI: 0" > > etc. > > Turning on auto-suspend - yup, I can't get it to enumerate again, dmesg shows it's trying addresses 44-51 in sequence with no success. Well, at least you have one way to get it working without needing any other USB devices. Can you send me the output of `sudo lspci -vvv` and `sudo lspci -n -vvv`? Perhaps this is a buggy xHCI host, and we need to disable auto-suspend support for it. I'm leaning towards the broken device hypothesis at this point, though. > Unfortunately I'm not able to make the kernel. I'm getting errors in xHCI: > > "[...normal make...] > LD drivers/watchdog/built-in.o > CC drivers/xen/features.o > CC drivers/usb/host/xhci-ring.o > CC drivers/xen/events.o > CC drivers/usb/mon/mon_bin.o > drivers/usb/host/xhci-ring.c: In function ‘handle_stopped_cmd_ring’: > drivers/usb/host/xhci-ring.c:1275:2: error: too many arguments to function ‘inc_deq’ > drivers/usb/host/xhci-ring.c:146:13: note: declared here > make[4]: *** [drivers/usb/host/xhci-ring.o] Error 1 > make[3]: *** [drivers/usb/host] Error 2 > make[3]: *** Waiting for unfinished jobs.... > CC drivers/xen/manage.o > CC drivers/xen/balloon.o > [...a few more normal make lines then exit with error status 2]" > > > I didn't play with the kernel configuration at all, I just left everything at default. Is there a particular kernel configuration setting beyond default I should set? Sorry if it's a newb error but I have no way to resolve it using generic help methods because it looks like the error is caused by the changes in xHCI caused by the patch. I assume the patch was already applied, patch indicates "reversed (or previously applied) patch detected" and errors out. Actually, looking more closely at your dmesg, I don't think you need that patch at all. Sorry for the frustration. :( -71 is -EPROTO, which means there was a transaction error on the Set Address command. Have you tried swapping the USB 3.0 cable for a new cable? Perhaps a bad cable is introducing noise in the first few transfers? Sarah Sharp > ________________________________ > From: Sarah Sharp <sarah.a.sharp@xxxxxxxxxxxxxxx> > To: Mark Lanctot <marklanctot@xxxxxxxx> > Sent: Monday, June 11, 2012 7:31:33 PM > Subject: Re: [Bug 43279] No USB 3.0 support for Prolific PL2773 > > On Fri, Jun 08, 2012 at 12:32:25PM -0700, Mark Lanctot wrote: > > Hello Sarah: > > Hi > Mark! > > > First of all, thank you for looking into this issue. > > No problem. :) > > > Other devices get enumerated and work perfectly when they're plugged > > into the same USB 3.0 port, including a USB 3.0 flash drive. > > > > Something very strange happened when I tried your other suggested > > test. I plugged another USB flash drive into the other port > > controlled by the USB 3.0 controller and not only did it enumerate, > > mount and work fine, but suddenly the problematic drive controller > > mounted as well and benchmarked at USB 3.0 speeds. I can unmount it > > and remount it fine after this until I unmount the other device. > > That's very strange... > > > Here's dmesg when it's working: > > > > "[14593.760329] usb 9-1: Device not responding to set address. > > [14593.964304] usb 9-1: Device not responding to set address. > > [14594.168028] usb 9-1: > device not accepting address 13, error -71 > > [14594.280325] usb 9-1: Device not responding to set address. > > [14594.484305] usb 9-1: Device not responding to set address. > > [14594.688026] usb 9-1: device not accepting address 14, error -71 > > [14594.800403] usb 9-1: new SuperSpeed USB device number 15 using xhci_hcd > > [14594.818502] scsi11 : usb-storage 9-1:1.0 > > [14595.816374] scsi 11:0:0:0: Direct-Access SAMSUNG SP2514N VF10 PQ: 0 ANSI: 0 > > [14595.816813] sd 11:0:0:0: Attached scsi generic sg7 type 0 > > [14595.817271] sd 11:0:0:0: [sdg] 488397168 512-byte logical blocks: (250 GB/232 GiB) > > [14595.818821] sd 11:0:0:0: [sdg] Write Protect is off > > [14595.818824] sd 11:0:0:0: [sdg] Mode Sense: 03 00 00 00 > > [14595.819344] sd 11:0:0:0: [sdg] No Caching mode page present > > [14595.819348] sd 11:0:0:0: > [sdg] Assuming drive cache: write through > > [14595.820695] sd 11:0:0:0: [sdg] No Caching mode page present > > [14595.820698] sd 11:0:0:0: [sdg] Assuming drive cache: write through > > [14595.827621] sdg: sdg1 > > [14595.829068] sd 11:0:0:0: [sdg] No Caching mode page present > > [14595.829071] sd 11:0:0:0: [sdg] Assuming drive cache: write through > > [14595.829073] sd 11:0:0:0: [sdg] Attached SCSI disk > > [14596.056804] EXT4-fs (sdg1): mounted filesystem with ordered data mode. Opts: (null)" > > > > I'm no expert, but it looks like it's about to fail with addresses 13 and 14, then the system hits upon a magic working address and everything's fine. > > When both devices have enumerated, can you run the command `lsusb`? > That will show you what device addresses have been selected for the two > devices. For example, on my system the keyboard has device address 002: > > sarah@xanatos:~$ > lsusb > Bus 001 Device 002: ID 045e:0750 Microsoft Corp. Wired Keyboard 600 > Bus 002 Device 002: ID 08ff:2810 AuthenTec, Inc. AES2810 > Bus 006 Device 008: ID 046d:c018 Logitech, Inc. Optical Wheel Mouse > > What I think is happening is the device continues to not enumerate, you > plug in a second device, which takes address 15, and the first device is > enumerated with address 16. > > Note that the USB core does not select the USB device address under > xHCI. The xHCI hardware selects the device address, and we just let the > USB core think it selected the address. AFAICT, the xHC will offer the > first address (address 1) over and over again to a device that doesn't > enumerate. This is different from the USB core behavior that tries to > increment the address on each failure. So it's possible the USB 3.0 > device doesn't like the first device address it gives it, but works > after the USB 3.0 flash drive > grabs the first address. > > There's no way to change which address the xHCI host picks from > software. So if that's really the root cause, I guess you just can't > use the USB 3.0 device unless another USB 3.0 device is plugged in > first. But let's see if we can solve it another way. > > > It will fail to enumerate again after I remove both devices, with a similar dmesg to before: > > > > "[14877.508329] usb 9-2: Device not responding to set address. > > [14877.712311] usb 9-2: Device not responding to set address. > > [14877.916031] usb 9-2: device not accepting address 28, error -71 > > [14878.028317] usb 9-2: Device not responding to set address. > > [14878.232314] usb 9-2: Device not responding to set address. > > [14878.436019] usb 9-2: device not accepting address 29, error -71 > > [14878.548320] usb 9-2: Device not responding to set address. > > [14878.752308] usb 9-2: Device not > responding to set address. > > [14878.956030] usb 9-2: device not accepting address 30, error -71 > > [14878.956043] hub 9-0:1.0: unable to enumerate USB device on port 2" > > > > Odd. So as long as another device is attached to the controller, this > > device works fine. It doesn't matter if this other device is USB 2.0 > > or 3.0. It won't enumerate if it's the only device on the controller > > though. > > Oh, so the USB 3.0 device will enumerate if a USB 2.0 device is plugged > in first? The USB 3.0 bus and USB 2.0 bus are electrically separated, > and the xHCI host should be able to use the same USB device address on > both buses to address different devices. So I'm not sure why this would > help... > > The only thing I can think of is that the USB bus would remain in an > active state (not suspended) when another device was plugged in. Does > the USB 3.0 device work if you > plug in a USB 2.0 hub, wait at least five > seconds, and then plug in the USB 3.0 device into the other port? The > USB bus will be suspended after 2 seconds of inactivity with a USB 2.0 > hub, but may remain active for other types of devices like USB mass > storage, mice, or keyboards. > > You can also disable USB auto-suspend for your roothub by changing into > the /sys/bus/usb/devices/ directory, finding the usbN directory for your > USB 3.0 host controller (it should be the same number as the bus number > that lsusb lists), and running this command as root: > > echo on > usbN/power/control > > Then try plugging in your USB 3.0 device. After you've run that > experiment, please turn back on USB auto-suspend by running this > command: > > echo auto > usbN/power/control > > > The controller on the motherboard is a ASMedia ASM 1042. It's > > probably not the controller since my other USB 3.0 device > works fine > > with or without other devices on the controller. > > > > > > Regarding the kernel patch, is this intended for a specific kernel? I tried to patch 3.4.1 and 3.5-rc1 and got the same errors: > > > > "/usr/src/linux# patch -p1 < usb_patch --dry-run > > patching file drivers/usb/host/xhci-mem.c > > Hunk #1 FAILED at 1685. > > Hunk #2 succeeded at 1822 (offset 111 lines). > > Hunk #3 succeeded at 2371 with fuzz 1 (offset 128 lines). > > 1 out of 3 hunks FAILED -- saving rejects to file drivers/usb/host/xhci-mem.c.rej > > patching file drivers/usb/host/xhci-ring.c > > Hunk #1 succeeded at 272 (offset -20 lines). > > Hunk #2 succeeded at 1169 (offset 17 lines). > > Hunk #3 succeeded at 1315 (offset 17 lines). > > patching file drivers/usb/host/xhci.c > > Hunk #2 FAILED at 104. > > Hunk #3 succeeded at 484 (offset 11 lines). > > Hunk #4 succeeded at 3556 > (offset 13 lines). > > 1 out of 4 hunks FAILED -- saving rejects to file drivers/usb/host/xhci.c.rej > > patching file drivers/usb/host/xhci.h > > Hunk #1 succeeded at 1252 (offset 5 lines). > > Hunk #2 succeeded at 1425 (offset 23 lines). > > Hunk #3 succeeded at 1704 (offset 41 lines). > > Hunk #4 succeeded at 1796 (offset 41 lines)." > > > > 2 of the 4 files patched fine, 2 failed. Please pardon me if it's an > > error on my part, but I can't help but think it's for a specific > > kernel which I haven't attempted to patch yet. > > Ok, I've cleaned up the conflicts and created a separate branch based on > 3.5-rc1: > > http://git.kernel.org/?p=linux/kernel/git/sarah/xhci.git;a=shortlog;h=refs/heads/cancel-command-fix > > To download it, install the "git" package and > run this command: > > git clone -b cancel-command-fix git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git > > Then make and install. Let me know if this branch fixes your issues > with the device. The patch needs some re-work, but it should be fine > for your particular case. > > Sarah Sharp -- 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
