USB connection stability
Junichi Chiba
Note that each device I have can work fine alone. They are recognized well and operates well over STF:7100 when only that one (or a few others) is present in the host.
usbfs: USBDEVFS_CONTROL failed cmd adb rqt 128 rq 6 len 256 ret -71
On Mac the problem is the same. Connecting 11th device will fail.
We decided that something around USB driver is blocking recognition of a new device.
Simo Kinnunen
--
You received this message because you are subscribed to the Google Groups "OpenSTF" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openstf+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openstf/5d6aa25e-59ca-4bcc-9727-fa59481c885c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Junichi Chiba
(the 10th port allowing connection)
Ah, now I found a similar Anker (the 10th port being charging only) is listed in Readme with a score 2/10, which is not recommended.
Irek Dziwis
On Thursday, July 23, 2015 at 7:21:24 AM UTC+2, Simo Kinnunen wrote:
Sounds like you're running into a problem with Intel processors (or the chipset, possibly). I'm not sure about your 4-core Core 2, but many recent Intel processors are only able to support about 8-12 phones simultaneously, even with USB hubs. This is mentioned in our README: https://github.com/openstf/stf#i-plugged-in-a-new-device-but-its-not-showing-up-in-the-list.
Basically you need a PCIe USB extension card with onboard controllers. We give some recommendations in the README.
Simo Kinnunen
--
You received this message because you are subscribed to the Google Groups "OpenSTF" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openstf+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openstf/c4cf66bb-b80c-498f-a4f4-2b2c813f9c3c%40googlegroups.com.
Irek Dziwis
Simo Kinnunen
--
You received this message because you are subscribed to the Google Groups "OpenSTF" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openstf+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openstf/00975a66-b28f-40a6-81cc-6b67a83ef61b%40googlegroups.com.
Chris Hessing
If I may throw in my $0.02 here. I've found that in most cases, the random disconnects that we have seen have had less to do with the USB host chipset, and *MUCH* more to do with the device itself. Worse, I've seen poorly behaved devices completely destabilize the entire USB bus they are connected to. (Won't name names on that one, but we had one device that we had to put on its own USB bus or else it caused all the other devices to completely disconnect within an hour or two of getting them all up and working.) At the same time, I currently have a device that refuses to stay connected no matter which chipset I use it with, and no matter if I am using USB 2 or USB 3. (I may have to dig out an old USB 1 hub and see if it is happy with that!)
My point is, don't automatically assume that if there is a problem it is necessarily the host chipset. Even if the problem is causing all of the devices connected to act up. From my experience, a single "glitchy" device can cause havoc on the USB bus!
As far as using USB 2 versus USB 3 controllers, I would actually
argue that using USB 3 controllers is the right thing to do, even
if you are only connecting USB 2.0 devices. The reason is pretty
simple. USB 3 cards are more likely to support the higher current
requirements of devices, and to recognize the goofy wiring those
devices use to signal that they want more current. As I have
also seen devices misbehave when they get less power than they
want, making sure they get all that they want is another way to
help stabilize the bus. If you are using a USB 2 card, and run
in to the low power problem, you might be able to work around it
using one of the USB "y" cables that can allow you to use two
power sources to feed a single device. But, be aware that all of
that type of cable that I have ever seen lacks the diodes needed
to prevent the two power sources from feeding power in to the
other, which could potentially cause problems with poorly designed
host buses. (That said, I would *HOPE* that most USB controllers
have some kind of feedback circuit in them. But, who knows!)
Troubleshooting USB problems can also be a massive pain. So far, the best method I have found is to look in dmesg and see which device disconnects first. I then disconnect that device, and see if everything else stabilizes. (I've also found that disconnecting power from the host device for 10-30 seconds, then powering it back up gives you the "best" chance at really figuring out if things have stabilized or not.) If everything stabilizes, then the device you unplugged probably is the issue. If not, try the next device at the top of the list when the disconnects happen. Then, if everything stabilizes, add back the first device.
For the device that you ultimately find misbehaving, you will probably want to try to hook it to it's own bus. (Note, in a lot of cases multiple ports on a single device are actually on the same bus, just through a hub. So, you will need to dig in to figure out which ports on the host device are ACTUALLY on their own host.) You can use the "lspci" and "lsusb" commands in Linux to help figure out how many USB buses are in the machine, and which bus different devices are on. Or, put another add-in card in, and only hook the flakey device to that add-in card.
Now, what would be *REALLY* cool is something like a thunderbolt->USB device where each port on the device was its own bus! Would someone please get on that!? ;)
Hope this helps someone out there!
To view this discussion on the web visit https://groups.google.com/d/msgid/openstf/CACKPMnNC6Wbs74fTeZMY45GhKROVOVJDE2U03GnzudX8vRXbKw%40mail.gmail.com.
Simo Kinnunen
To unsubscribe from this group and stop receiving emails from it, send an email to openstf+unsubscribe@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openstf/00975a66-b28f-40a6-81cc-6b67a83ef61b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "OpenSTF" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openstf+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openstf/CACKPMnNC6Wbs74fTeZMY45GhKROVOVJDE2U03GnzudX8vRXbKw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "OpenSTF" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openstf+unsubscribe@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openstf/b316bce7-ce80-01e8-ee9e-ae0925100af3%40gmail.com.