Hub - No Solution Works..

[rgadsdon]

I have now tried several different hubs, and am already using a known/good power supply (Nokia) and have also tried a so-called known/good hub (Logik..) and still get constant failures.
I am running the very latest version of the kernel and firmware etc, from GitHub.
The Pi won't boot if the (powered) hub is connected, and the red led glows, even when the main power supply s disconnected. The system boots only if the power is _disconnected_ from the hub first, and then reconnected after boot.
If I am lucky, the hub will accept a keyboard and mouse, but if anything else is connected, then the system gives a whole series of errors, and the (usb) ethernet stops working:

ADDRCONF(NETDEV_UP): eth0: link is not ready
smsc95xx 1-1.1:1.0: eth0: kevent 4 may have been dropped
smsc95xx 1-1.1:1.0: eth0: kevent 4 may have been dropped
smsc95xx 1-1.1:1.0: eth0: kevent 4 may have been dropped
smsc95xx 1-1.1:1.0: eth0: kevent 4 may have been dropped
smsc95xx 1-1.1:1.0: eth0: kevent 4 may have been dropped
smsc95xx 1-1.1:1.0: eth0: kevent 4 may have been dropped
ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
smsc95xx 1-1.1:1.0: eth0: link up, 100Mbps, full-duplex, lpa 0xCDE1
smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000114
smsc95xx 1-1.1:1.0: eth0: MII is busy in smsc95xx_mdio_read
smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000114
smsc95xx 1-1.1:1.0: eth0: MII is busy in smsc95xx_mdio_read
eth0: no IPv6 routers present
smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000114
smsc95xx 1-1.1:1.0: eth0: MII is busy in smsc95xx_mdio_read
smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000114
smsc95xx 1-1.1:1.0: eth0: MII is busy in smsc95xx_mdio_read
smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000114
smsc95xx 1-1.1:1.0: eth0: MII is busy in smsc95xx_mdio_read
smsc95xx 1-1.1:1.0: eth0: link up, 100Mbps, full-duplex, lpa 0xCDE1

After disconnecting the hub, and reconnecting the mouse and keyboard directly, then everything works correctly (as it always has done..)

So - after trying all the 'suggested' solutions, I have to come to the reluctant conclusion that - on my Pi - a hub simply does not work, at present.

Hopefully there will eventually be a firmware/kernel/modules update that fixes this, but for the time being my system will only operate correctly _without_ a hub connected.

Robert Gadsdon.

[SN]

As always be suspicious of power to the pi. Whats your TP1/TP2 measurement.

Try powering the pi from the hub AND connect the USB a to b cable between the pi and hub. See if it will go then. This also solves the half powered thru hub issue. If that works, add your keyboard in on the hub and then the pi. It took me a few goes to get mine right.

[NickT]

I have the recommended Logik 4 port hub and as long as I don't want to use a wifi adapter, then I can get it to work over ethernet with a keyboard and mouse connected. I make sure that I power the Pi from the hub via the micro USB port. I wouldn't use a powered hub and a separate PSU at the same time.

I know from inspecting the PCB that the Logik hub connects the +5V rail directly to the pin on the connector (via the red wire). Unless I've read the schematic wrongly, then if the hub is powered on and the flying USB lead is connected to the Pi with nothing connected to to the PI's micro USB power input, then problems will result. In that case the hub will be trying to power the whole Pi through the polyfuse, which is not going to let more than 140mA through. The Pi needs more than that.

I would advise never to connect the hub's USB connector to the Pi unless the Pi is powered up, and preferably from the hub itself via the micro USB. I use the lead supplied with my mobile phone which is for the purpose of trickle charging it from a computer's USB socket.

[Insectecutor]

I've also seen a powered belkin hub providing ~100ma power to the pi through the USB ports. How is this even possible? Surely no power should be supplied through the upstream port of the hub...

[NickT]

I've also seen a powered belkin hub providing ~100ma power to the pi through the USB ports. How is this even possible? Surely no power should be supplied through the upstream port of the hub...

If there's +5V on the connector that's plugged into the Pi's USB, then there's only the polyfuse between the connector and the Pi's Vcc. I think that for revision 2 o f the PCB, they should provide a couple of pin headers that could be dis/connected with handbag jumpers depending on whether a powered hub or a plain USB device was to be used on the port.

[jbeale]

I've also seen a powered belkin hub providing ~100ma power to the pi through the USB ports. How is this even possible? Surely no power should be supplied through the upstream port of the hub...

It is a violation of the USB spec, but it is cheaper to do this and on a typical desktop or laptop, it will work, so they get away with it. As pointed, out, it can cause trouble on the Pi.

[marsman2020]

Others have already pointed out the hub-feeding-power-back-into-the-Pi issue.

As far as the kevent 4 errors once you have booted the Pi and connected the hub after booting - some people have resolved this by trying a different power supply, but there may be a software issue with attaching hubs to the Pi as well that causes the Ethernet to drop out.

See https://github.com/raspberrypi/linux/issues/29 for the troubleshooting I have done. I borrowed an oscilloscope to rule out it being a power issue.

And yes, if I attach my mouse/keyboard directly to my Pi, everything works fine, and attaching them to a powered hub breaks the Ethernet.

I'd appreciate more comments on the github issue so it gets addressed.

[fromagique]

Please forgive my ignorance if this is a dumb question, but... is there such a thing as a data-only USB cable? That is, could one use a cable that provides no connection at all to the VCC line, and would this solve the hub power problem?

Just thinking out loud, so to speak...

[jbeale]

Please forgive my ignorance if this is a dumb question, but... is there such a thing as a data-only USB cable? That is, could one use a cable that provides no connection at all to the VCC line, and would this solve the hub power problem?

I've never heard of being able to buy such a cable, but you can make one, either by
1) placing a small piece of tape over the USB +5V power pin inside the connector to prevent contact, or
2) cutting open the cable and cutting the red wire (leaving the other three intact)

[abishur]

I've also heard of people being able to remove the +5 pin from the usb plug without cutting up the cord. Make sure to leave the ground intact or else you'll loose data as well as power

[shirro]

The best thing I have done for the Pi in the last few days is remove the powered hub and remove a lot of weird behaviour and kernel messages.

Down to a single unified wireless mouse/keyboard dongle that pretty much works except for occasional lost packets (which were much worse when the hub was involved). Unusable for long term use so have ssh for that. It is a bit frustrating.

[mahjongg]

Either remove the USB polyfuse for the port connected to the hub (F1 is for the top port), or disconnect the 5V wire in the USB cable to the hub:
OR
Power the RPI from the same hub as is used to connect to the RPI port.

The reason is that otherwise there is a chance the hub tries to power the RPI ftrough the upstream cable (the cable between the hub and the RPI), and that current is limited through the 140mA polyfuse, which means the PI is partially powered. When a device like the RPI is partially powered it can behave erratically, and when it then receives full power many devices won't get a reset signal, and also crystal oscillators may not start under such conditions.

[siriusfox]

Either remove the USB polyfuse for the port connected to the hub (F1 is for the top port), or disconnect the 5V wire in the USB cable to the hub:
OR
Power the RPI from the same hub as is used to connect to the RPI port.

The reason is that otherwise there is a chance the hub tries to power the RPI ftrough the upstream cable (the cable between the hub and the RPI), and that current is limited through the 140mA polyfuse, which means the PI is partially powered. When a device like the RPI is partially powered it can behave erratically, and when it then receives full power many devices won't get a reset signal, and also crystal oscillators may not start under such conditions.

Has anyone actually tested this to see if this works? I've got no problem gutting a usb cable for this kind of fix, but I don't have any extras sitting around if it doesn't work.

On a side note, wouldn't this kind of upstream power problem violate the USB spec in some way?

[stevep]

I have the same Logic 4 port hub. I don't have a wi-fi dongle, but currently plugged in are a mouse, keyboard, network cable and a usb gps dongle. Power is supplied by the hub itself, and I have disconnected the red +5v line on the flying lead (by opening up the hub and snipping the red wire. I have had the Pi running for extended periods in this configuration - at least 5 hours yesterday, and around 6 hours so far today, running FoxtrotGPS most of that time, with absolutely no problems.
As I've said in another post, it may be that you have an unlucky combination of peripherals - others may have had each of them running fine with their particular setup, but you may have a different combination. I would try snipping the red wire first, then maybe go for another k/b or mouse from the Verified Peripherals Wiki.

[Montala]

Sorry, but I am getting a bit confused by all this, and realise that no two set-ups are probably identical, but I was getting the impression that if the Pi is being supplied directly from one (or two) of the USB ports on a powered hub,(as Mahjongg mentions as an option above) then it wasn't necessary to cut the red 5v wire... or is that not in fact the case?

Obviously there will also be another USB 'data' cable from the Pi to the hub.

[marsman2020]

Either remove the USB polyfuse for the port connected to the hub (F1 is for the top port), or disconnect the 5V wire in the USB cable to the hub:
OR
Power the RPI from the same hub as is used to connect to the RPI port.

The reason is that otherwise there is a chance the hub tries to power the RPI ftrough the upstream cable (the cable between the hub and the RPI), and that current is limited through the 140mA polyfuse, which means the PI is partially powered. When a device like the RPI is partially powered it can behave erratically, and when it then receives full power many devices won't get a reset signal, and also crystal oscillators may not start under such conditions.

I wouldn't be recommending that users of varying electronics ability permanently modify their Pi at this point.

At any rate, snipping the flying lead back from the hub might work in some cases, but for other users it has *not* worked - http://www.raspberrypi.org/phpBB3/viewt ... =25#p93112

I believe the issue is that in addition to the power supply/hardware issues, there is a a software issue affecting some USB devices (even ones on the Verified list in some combinations).

No one has responded to my github issue on this, and I haven't been able to get any other users here on the forum to take the time to post their results on github either. So it seems unlikely at this point that this will be solved unless other folks are willing to contribute.

[NickT]

Either remove the USB polyfuse for the port connected to the hub (F1 is for the top port), or disconnect the 5V wire in the USB cable to the hub:
OR
Power the RPI from the same hub as is used to connect to the RPI port.

The reason is that otherwise there is a chance the hub tries to power the RPI ftrough the upstream cable (the cable between the hub and the RPI), and that current is limited through the 140mA polyfuse, which means the PI is partially powered. When a device like the RPI is partially powered it can behave erratically, and when it then receives full power many devices won't get a reset signal, and also crystal oscillators may not start under such conditions.

I wouldn't be recommending that users of varying electronics ability permanently modify their Pi at this point.

At any rate, snipping the flying lead back from the hub might work in some cases, but for other users it has *not* worked - http://www.raspberrypi.org/phpBB3/viewt ... =25#p93112

I believe the issue is that in addition to the power supply/hardware issues, there is a a software issue affecting some USB devices (even ones on the Verified list in some combinations).

No one has responded to my github issue on this, and I haven't been able to get any other users here on the forum to take the time to post their results on github either. So it seems unlikely at this point that this will be solved unless other folks are willing to contribute.

It's still worth cutting the lead from a hardware viewpoint, as it eliminates the possibility of trying to supply the Pi though the polyfuse if there is nothing connected to the main micro USB power connector.

P.S. I have added my support to your github issue under my alter ego NIckBT, (NickT was spoken for by someone else apparently)

[kmfs69]

I have the same problem even without X-windows.

I use an Apple keyboard with the following specifications :
Product ID: 0x0221
Vendor ID: 0x05ac (Apple Inc.)
Version: 0.69
Speed: Up to 1.5 Mb/sec
Manufacturer: Apple, Inc
Location ID: 0xfd520000 / 4
Current Available (mA): 100
Current Required (mA): 20
A picture can be found on http://store.apple.com/us/product/MB110LL/B?

The problems start when I have my wireless Logitech M510 mouse connected. This mouse uses the Logitech unifiing receiver. See http://www.logitech.com/en-gb/promotions/6072
Product ID: 0xc52b
Vendor ID: 0x046d (Logitech Inc.)
Version: 12.01
Speed: Up to 12 Mb/sec
Manufacturer: Logitech
Location ID: 0xfd530000 / 5
Current Available (mA): 100
Current Required (mA): 98

If I plug the receiver in the USB port of the keyboard the problem start, when I unplug the receiver the problem goes away.
If I plug the receiver direct in the Pi USB port the problem also starts and goes away when I remove the receiver.

[clickykbd]

Here is a "fun" variation on this theme.

I have two hubs to test with (both powered). They both seem to work fine with basic devices (keyboard mouse etc). But I have a high quality audio USB/DAC I am trying to get to function stable.

I've encountered this in both wheezy and squeeze. Both hubs will generate these smsc95xx read index kernel errors, and cause the system to respond extremely slow (but under different circumstances).

No Hub: When direct, without hubs, I get these errors, I kernel panic eventually, which was where i started with this problem before adding the hubs to test other configurations.

Hub1: ioGear 5 port + card readers. (generates these errors immediately upon recognition of the USB audio device. This is true of both a data-only cable and a +5v cable to the DAC. Strangely this is true regardless of if the DAC is plugged into the hub or the RasPi, immediate errors if the hub is present.

Hub2: a generic miMicro powered 4-port. Does not generate these immediately, but waits until you actually attempt to play audio to the device, during playback the symptoms are identical to no hub at all.

I've also tested powering the RasPi alternatively with my 1A iphone charger, and internally through the hubs (>1A adapters). No change.

In all cases eventually these errors in combination with perhaps others during playback causes a panic (1 or two tracks in usually). Playback however is impossible with the data-only cable because the DAC apparently checks for that in some part of it's auto-input selection logic, but I was able to rule out power backflow from the DAC being the sole culprit.

I feel like the DAC is the problem and not the hubs, BUT the fact it is behaving differently depending on the hub has me a bit confused though and thinking other usb and driver/architecture problems perhaps?

I can still try to remove the +5v on the hub upstream ports, I only tested via hub-powering the Pi. Any troubleshooting thoughts or suggestions?

If I get totally frustrated i might try recompiling with smsc95xx as a module... and just rmmod it when I really want good audio and no internet. Maybe my pico-wifi will work better and give me access to tunes eventually. That is my next device to tinker with.