USB 3.0 hub fails to pass through USB 2.0 devices (ID 2109:3431) #64
Comments
|
I should have added the kernel messages from my amd64 system for comparison: [266584.352254] usb 2-3.3: new low-speed USB device number 5 using ehci_hcd |
|
"error -71" is a protocol error, every time I've seen that in the logs, it's been from low power. Your USB device is trying to draw over 140mA from the USB host, which is fuse protected to not allow more. Use a powered USB hub to power the extra devices. |
|
That sounds bizarre - I can't understand how it could be true in this case. The devices work fine when attached to the Pi directly (they're a keyboard and an infrared detector), but they don't work when connected to this USB3 powered hub! Also, they work OK on a different machine; would that also have a power protection? |
|
Can you try this again with the latest kernel, the messages are similar to the ones that we were seeing without microframe scheduling... |
ghost
assigned 
|
Same here. I am using wheezy 2012-08-16. |
|
Same problem here, any news for this? |
|
As in 23.10.2012 with Linux raspberrypi 3.2.27+ #160 PREEMPT Mon Sep 17 23:18:42 BST 2012 armv6l GNU/Linux symptoms are same. |
|
After having the device descriptor error with my keyboard. I decided to take the advice of GriffenJBS and purchase a powered usb hub. But I still receive the same error. |
|
Exact same issue here - USB3 hub is powered, USB laser mouse blinks on and then goes off. |
|
Same here: |
|
Try fiq_split branch |
|
@ghollingworth |
|
Just do a sudo BRANCH=fiq_split rpi-update Gordon Director of Engineering, Raspberry Pi (Trading) Limited From: camillo777 <[email protected]mailto:[email protected]> @ghollingworthhttps://github.com/ghollingworth Reply to this email directly or view it on GitHubhttps://github.com//issues/64#issuecomment-19897123. |
|
@ghollingworth |
|
Don't know what you've done, but this has never been seen before... Are you running NOOBs? Just wondering whether it's an incompatibility with that? Might need to switch to an image first... Gordon Director of Engineering, Raspberry Pi (Trading) Limited From: camillo777 <[email protected]mailto:[email protected]> @ghollingworthhttps://github.com/ghollingworth Reply to this email directly or view it on GitHubhttps://github.com//issues/64#issuecomment-19899842. |
|
Yes I am using latest NOOB and latest Raspbian. 100%[===========================================================>] 6,386 --.-K/s in 0.001s 2013-06-23 17:37:35 (4.44 MB/s) - `/usr/bin/rpi-update.tmp' saved [6386/6386] *** Relaunching after update |
|
Looks like it ran out of disk space or network broke or something, didn't really get very far Gordon |
|
I successfully ran a 'BRANCH=fiq_split /root/rpi-update' on my Arch Linux RPi. The rpi-update "downgraded" me from the BRANCH=next version I was running (3.9.7+ kernel), but other than that, no problems have (as yet) been encountered. In case camillo's problem was related to insufficient free space, here's my 'df -h' output: |
|
Tried another time; this time the upgrade seems fine: pi@raspberrypi ~ $ lsusb -t |
|
Not really sure why it would start disconnecting... Might be worth running through a powered hub to check if it's just a power issue (that's the kind of thing you'd expect, the USB power drops out when you enable the mouse). Can't make any assumptions about the power based on power supply since there is a polyfuse on the PCB which could make enough of a difference, also you'll not see the short term reduction in the power supply Gordon |
|
Here's the USB details with the 'BRANCH=fiq_split" kernel & firmware: dmesg output: The repeats of the UPS devices occur until the NUT (Network UPS Tools) drivers and server services start up. |
|
Tried with more stable power on branch fiq_split, but with same result: pi@raspberrypi ~ $ lsusb -t pi@raspberrypi ~ $ /opt/vc/bin/vcgencmd version && uname -vmr Any more ideas? |
|
Same issue here: |
|
I just received one of these: I sometimes see these "device descriptor read/64, error -71" error messages (like the ones above) but only when the PI is "back power" from the HUB via a USB to MicroUSB cable on USB hub 10, ports 1, 2 and 3 on the HUB seem to be fine. No matter what I try I can't get the PI to recognize ports 4 to 10 on the hub When I do a "lsusb" it reports a device name of "2109:2812". I tried the "fiq_split" but it seemed to crash during boot. I'm happy to help run any diags etc. Any ideas? |
|
Seeing same behavior here... Aug 2 2013 11:53:50 The hub itself seems to ID properly and come up: But plugging my devices into the hub results in the same outcome every time: Regardless of port on the hub, it always tries to assign two addresses, and then blows up with the unable to enumerate.
I'm away for a couple of days, but will try any debug or trial and error suggestions that anyone wants to throw out there. ;) |
|
Can you tell us the model / product ID for the hub and we'll go buy one! Thanks Gordon |
|
Here's the fun part (I have to laugh, or I'll cry)... I bought mine July 19th from Amazon, they listed it as "Anker Uspeed USB 3.0 10-Port Hub with 12V 4A Power Adapter [Apple Style Aluminum Hub]" for $57. It's no longer on the site. If I go into my order history, it's still there, but clicking the item takes me to http://www.amazon.com/gp/product/B007ZWFKX8/ref=oh_details_o01_s00_i00?ie=UTF8&psc=1, but the 10port listed there appears to be different. The anker website doesn't seem to list it as a currently sold item anymore either, so I believe they've replaced it with the "9 port + 1 super mega charging port" version. :/ http://www.ianker.com/support-c11-g186.html is the exact device I have, but their tech specs leave much to be desired. :/ That said, I believe the device is OEM'd elsewhere, and I've seen it with multiple vendor names attached elsewhere (Aitech, Orico), but some seem to have the VL811 chipset, whereas what I have ID's as 2109:0812 seems to be a VIA VL812 chip from what I've been able to dig up online... (I believe the VL811 is an older variant)... I did spy a firmware update for the VL812 that one provider is shopping around, I may plug this hub into my windows box and try that, see what happens... I hate to risk nuking a $60 hub, but if I can't use it the way I hoped (those devices, + the pi), then I'll be off to find a new solution anyway. ;) |
|
Where are you based, maybe you could send it to us at PiTowers and we'll send it back once we understand the issue... Thanks Gordon |
|
I have a problem with a prolite t2735msc touchscreen monitor that seems similar to this thread pb. The monitor includes a touchscreen device and a webcam connected through a USB3 hub (inside the monitor). Web cam is well recognized but not the touchscreen device. When I set "dwc_otg.speed=1" in "cmdline.txt", it works fine (see dmesg :) the problem is that I need to use USB2 device simultaneously with this touchscreen. Do you know how I can solve my problem? |
|
The touchscreen is a full-speed device. See #64 (comment) for why it does not work. |
|
Sorry, but there is something I don't understand. In this case, I can't connect the touchscreen interface on a USB2 hub because it's done internally in the monitor. So where is the bug? A configuration in the kernel or something the RPI chip cannot do? |
|
Internally to the monitor, you have a USB3.0 hub with a number of non-removable peripherals connected - namely the touchscreen controller and the webcam. As you said, the webcam enumerates properly because USB3.0 hubs behave much the same as USB2.0 hubs when plugged into a USB2.0 bus. The same principle applies for issuing split transactions to talk to a low- or full-speed device connected to a USB3.0 hub. As stated in my comment, we transmit a USB2.0-compliant request (verified using a protocol analyzer) to the hub to issue a split transaction to the low-speed device connected. It is ignored by the hub and it does not respond to the request at all. Given that virtually every USB2.0 hub out there responds correctly to our requests, the bug is within the VIA chipset. |
|
Thank you for your answer. |
|
Only USB2.0 high-speed traffic is allowed on any USB2.0 bus. If you set dwc_otg.speed=1, the entire bus speed is dropped to USB1.1 full-speed which all USB2.0 devices (and by implication USB3.0 hubs) must support. The issue of asking the USB3.0 hub to perform split transactions goes away in this mode: The Pi simply talks directly to the device. Annoyingly the maximum bandwidth in speed=1 mode is 12mbit/s - which dramatically limits the resolution that most webcams will operate at. |
|
Hi everyone. |
I just encountered the same problem as several people here and I still don't understand why the very same hub, with the very same set of devices plugged into it, doesn't exhibit the problem with any other computer. With the Pi - error -71... |
|
@SpiRaiL is the man. This worked for me instantly. Thanks |
|
@silverdr The only difference (and we've checked) is timing, we send it with a slightly longer delay (although still within the USB 2.0 spec). That is the only difference, and that's why it's a bug in the VIA chipset Gordon |
|
@ghollingworth I see. But if we know how to work this bug around, wouldn't it be more.. productive to have it worked around. I might be missing something though. |
|
Quoting myself: Since then, I've confirmed that it is indeed a bug with the VIA chipset (by substituting a different USB3.0 hub chip). The workaround is to purchase a USB3.0 hub that integrates silicon from a different chip vendor, or get VIA to admit their spec noncompliance (no prizes for guessing which will be easier). SMSC/Microchip based USB3.0 hub IP works with the OTG port on the Pi, I have yet to see any other vendor USB3.0 hub silicon in interoperability tests with the Pi. |
|
Quoting ghollingworth "we send it with a slightly longer delay". I understand the word "we" as a keyword here. If "we" can send it with longer delay, can't "we" send it with a shorter delay? Unless there are hardware limitations in the game here, of course. |
|
No, the delay is a delay in hardware not software |
|
That explains, thank you. |
|
As P33M has stated before, the main issue appears to be a bug in the hub firmware. I currently have an older Anker 7-port usb 3.0 hub (purchased July 2013) as specified in one of my earlier posts and have confirmed that a combination of a firmware upgrade on the hub and the raspberry pi (rpi-update) fixed the USB -71 issue. I no longer have usb 1.1, 2.0, or 3.0 errors. I can use any usb device all day long without troubles and have been doing so for almost a year. If you have purchased one of these USB hubs with the VIA 812 chipsets on or after October 2013 you should be in the clear. Otherwise attempt to install new firmware on your hub from this site: http://plugable.com/2013/10/30/plugable-usb-3-0-hub-firmware-upgrades2 |
|
I have an Anker 7-port USB3.0 hub using VIA812 chipsets. I tried both the Anker and Plugable update programs and they either crashed or didn't find the hub at all ... headdesk. I shall retry on a different machine with a different xHCI controller. The firmware revision on my hub is 9801. It appears that unless you have a VIA812-B2 chipset then this firmware change is required - the firmware shipped by the Anker updater appears to be 8591. The Plugable updater appears to be 8581. |
|
Just bought a Anker 7-port with VIA812-B2 chipset. |
|
For reference, can you post the output of |
|
Sure, here it is (with dwc_otg.speed=1 to /boot/cmdline.txt hack and NO plugged device): lsusb -vThe LED for USB PORT1 of the hub keeps blinking (I guess it is to say the hub is connected to a USB 2.0 port and not working at full speed).
When I plug a device (device is NOT working):
When I plug a device (device is working): Model is Anker® AH221 USB 3.0 7-Port Hub. I haven't tried to plug USB 1.1 to it. |
|
Hi everyone, Using the dwc_otg.speed=1 hack my Anker® AH221 USB 3.0 7-Port Hub device works well. But I'm having a new issue now. I now have two of this Anker USB Hub, on which I have plugged 8 USB 2.0 devices in total. No matter how I arrange those 8 devices on those two hubs, I am not able to make my devices work together. It seems that the limit is 6 devices at the same time (if I plug one or two more, then all the already plugged devices stop working properly, by that I mean they connect/disconnect one after the other to keep a total of 6 simultaneous units working at the same time). I have verified that this issue is not related to power usage, since this is not happening on my OSX system when I have those 2 Ankers and 8 devices connected to them (they work perfectly well on OSX). Any idea why the Raspberry Pi cannot handle more than 6 simultaneous connected USB devices? Edit: Sounds like this is the issue
|
|
Hi! I'm having the same issues with a Raspberry Pi B+ running OpenELEC 5.0.0 (kernel Linux 3.17.7) with Kodi 14.0 and the CoolBox 7 ports Hub USB, it has 4 ports 3.0 and 3 ports 2.0, but it fail to deliver consistent compatibility even with 2.0 devices...
It can uses a WiFi dongle via a USB 2.0 hub port (but does not work in any 3.0 ports), but this hub does not work with an external HDD, nor with a wireless keyboard by USB. This USB hub also connects fine a usb memory stick at USB 2.0 and 3.0 ports. I suspect it is because it uses chipset with famous ID 2109:2812... USB devices conected right now are: OpenELEC:/ # lsusb Branches for USB devices are: OpenELEC:/ # lsusb -t And lsusb -v gives for this device this information just in case it helps: Bus 001 Device 010: ID 2109:2812 Recap: I just wrote to CoolBox support giving all this information, let's see what they can do... If you have any idea please don't hesitate to tell me. Thanks! ;-) Kind regards, |
|
Does anyone know if the new Pi 2 will still have this issue? |
|
The USB phy is identical between BCM2835 and BCM2836. |
|
@SpiRaiL, yes same issue with the Pi 2. :( |
|
I've just tried to put a USB 2.0 hub in-between the USB 3.0 hub and the Raspberry Pi. Result is exactly the same as if there were no USB 2.0 hub. Still stuck with these "device descriptor read/64, error -71" error if dwc_otg.speed=1 is not set. But I really want to use my USB 3.0 hub at high speed... |
|
Desperate bump... |
|
There is no fix that can be applied to the Pi (save for the dwc_otg.speed=1 sledgehammer) that will allow the use of full- and low-speed devices behind USB3.0 hubs with the ViA chipset without a firmware upgrade/fix from the silicon vendor, as explained multiple times previously. |
and others
I have attached a powered USB Hub to my Raspberry Pi. It shows up with lsusb:
Bus 001 Device 005: ID 2109:3431
When I attach this device to my Linux amd64 machine, running Linux 3.2.20, it is able to also show connected (USB 2.0?) devices to the machine, for example:
Bus 002 Device 004: ID 0458:002e KYE Systems Corp. (Mouse Systems)
However, when I connect it to the Pi, it does not show the attached devices, which is rather unfortunate.
I imagine that this might be the same bug as in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/783097 but then again, maybe not.
On connecting the USB device to the hub, the following messages appear in dmesg (and also in /var/log/kern.log):
[ 1113.345672] usb 1-1.2.1: new low speed USB device number 10 using dwc_otg
[ 1113.425796] usb 1-1.2.1: device descriptor read/64, error -71
[ 1113.615712] usb 1-1.2.1: device descriptor read/64, error -71
[ 1113.805702] usb 1-1.2.1: new low speed USB device number 11 using dwc_otg
[ 1113.885695] usb 1-1.2.1: device descriptor read/64, error -71
[ 1114.075687] usb 1-1.2.1: device descriptor read/64, error -71
[ 1114.265688] usb 1-1.2.1: new low speed USB device number 12 using dwc_otg
[ 1114.685460] usb 1-1.2.1: device not accepting address 12, error -71
[ 1114.765669] usb 1-1.2.1: new low speed USB device number 13 using dwc_otg
[ 1115.185455] usb 1-1.2.1: device not accepting address 13, error -71
[ 1115.185811] hub 1-1.2:1.0: unable to enumerate USB device on port 1
Any clues?
Thanks!
Julian
The text was updated successfully, but these errors were encountered: