I am working on a project that involves Raspberry Pis which run 24/7, periodically fetch data from a server and display it on a screen.

We have a problem with the USB ports - they appear to stop working after about a week of uptime. This happens on five different units. Normally, the only device plugged into each RPi is a 3G/WiFi dongle through a powered USB hub.

I looked at server logs and found that a certain unit has stopped updating the data.
After driving to see the device, it was still running and looping the data on the screen but I couldn't connect a keyboard. I assumed that the USB controller or something related to it stopped working.
When I restarted the unit, everything was fine.

The Raspberry Pi is revision 000e (v1 model B, 512MB, PCB rev. 2).

I am in the process of updating the operating system image from Wheezy to Jessie.
It is possible that this problem was fixed in some kernel update or a similar thing.
With two extra units, I'd just do rpi-update on one and leave it
for a week while working on the upgrade using the other device.

It is possible that when I finish the new image and try running it for a few weeks, it works.
However I would appreciate any information about the cause of this problem
because a week is a long time to wait and I could find it still broken then.

EDIT: Unfortunately I couldn't allocate time for the testing. In the meantime I've worked around the issue by restarting the devices nightly during a quiet period.

  • 1
    Have you checked /var/log/syslog for errors or other information about this?
    – goldilocks
    Commented Mar 16, 2016 at 14:46
  • @goldilocks I haven't yet. It just happens that one of the devices stopped working again. I asked my friend to swap out the card and get the crashed on to me. I'll look if there's anything in the logs
    – varesa
    Commented Mar 16, 2016 at 15:01
  • I have a similar issue with my USB TV tuners. They sometimes work but don't work reliably as time goes on - until I do a hard reboot (soft reboot doesn't work). Often they will appear as if they're off.
    – modeset
    Commented Jan 25, 2020 at 23:45

3 Answers 3


Here's a method about controlling the power to ports on a USB hub,
using software - the hub-ctrl.c app from a question that another
post above links to.
It can be used to wake up the USB ports (at a regular interval, a cron-job script
or over a SSH connection if only some devices attached to the bus have stopped).

Some useful information from a forum thread on the Raspberry Pi website:

mahjongg wrote:
the Pi model B+ has no hardware in place to disconnect power on the USB ports!

it can detect a short (USB power Fault) and then the USB power controller (P2553W6) will
automatically block the USB power, but it can't switch off the power to USB using software.
What it can do is bring the LAN9514 into sleep mode, but that doesn't turn the power off!

reply from a moderator & RPi engineer:
Yes it can. Issuing a USB Hub class request (CLEAR_FEATURE PORT_POWER) to port 2
on the LAN9514 will deactivate the USB output power switch.

There's an app for that:

For the above application, the command you can use is sudo ./hub-ctrl -h 3 -P 1 -p 0
- h is the hub, P is the port, and p is to switch power on (1) or off (0).

The hub and port values for a device can be found with lsusb.

Some other details (from a 2016 reply, lsusb data could be more accurate):

Just tested this with the Pi 3 [...] The USB port numbering from the picture posted above:

Hub:Port -- Controlled port(s) 
0:1 -- Controls the Ethernet port
0:2 -- Controls all four USB ports (not the Ethernet)
0:3 -- Controls USB Port 4
0:4 -- Controls USB Port 2
0:5 -- Controls USB Port 3

As best I can tell, USB Port 1 cannot be controlled individually.

Edit: if you find the app doesn't work on your RPi
and you need to switch a USB WiFi device
back on, you could try:
• restart the WiFi connection or reboot your Raspberry Pi

• switch the Wireless LAN network interface on with a command like sudo ifup wlan0
When it stops working (goes to sleep) regularly, do that in a cron script as described above.

  • In my case I don't think the issue is with a single port. The whole bus goes dead. The part about the P2553W6 USB power fault seems interesting. In the meantime I've "solved" this issue by automatically restarting the devices nightly during a quiet time
    – varesa
    Commented Dec 31, 2017 at 20:25
  • @varesa useful to know, thanks. I think this method could probably be used to restart the bus as well as individual ports but if you've found another way, that's good.
    – Edward
    Commented Dec 31, 2017 at 20:30
  • I've investigated this for another project looking at USB Hub power control uhubctl Issue 35 and the port 2 control switches the power for all the USB ports as they are all ganged on that line, the remaining power controls from 3 upwards can be set in software but they are not connected to anything and are ineffective. This is on RPi models 1B+ and later, and the port 1 control does have an effect on the Wired Ethernet port but that can be awkward if you are sshing into the RPi on that connection when you switch it off!
    – SlySven
    Commented Dec 31, 2017 at 23:40
  • Okay, I don't know much about the subject or that other project. Thanks for stating that the 3+ ports on built-in hub 0 probably don't work on newer RPi models. Also, there's a note that the port numbering from that forum post could be less accurate so use a command to check it.
    – Edward
    Commented Jan 1, 2018 at 16:38
  • I tested this on a model B+ (rev 1.2, Linux kernel 4.4, Debian wheezy/7.11) Raspberry Pi and it didn't work using either the hub and port numbers (0 2 for built-in hub, all 4 ports) or device and bus id numbers (bus 001, device 004 for my USB-2.0 4-port hub with a wireless LAN adapter). I think the built-in USB hub 0 was more likely to work. Another idea I have for waking up a USB WiFi device is to restart the connection or switch the network interface back on with something like ifup.
    – Edward
    Commented Jan 3, 2018 at 19:17

have similar problems with our set up. Some times the usb port stops without any reason. This is with our WIFI adapter. Just pressing enter on an attached keyboard or resetting the wifi adapter makes it work again (without resetting the Raspberry). Looks like the usb-port or controller goes to standby or to sleep.

  • In my case everything including keyboards stops working so that I don't have any other means of accessing the device but a power cycle
    – varesa
    Commented Jun 9, 2016 at 19:53

Here is something that may help. It is an app, called hub-ctrl, that allows you to turn individual USB ports of the Pi on and off.

If your Pi's are accessible through the internet or from your server, you can SSH into them and use this app to power-cycle the USB ports instead of power-cycling the entire device.

If your Pi's aren't accessible from the internet or your server, you will have to install this locally, and you could then setup a cron job to power-cycle the USB ports on a schedule that seems reasonable to you, possibly when you have a known quiet time where the Pi won't have any data to log.

  • 1
    It is not really possible to connect the Pi to internet without USB. The ethernet controller is on the USB bus, wifi dongles, 3g dongles, everything is on the USB bus. Pretty much the only way to connect left is the serial port on the headers. Cron-job could work though
    – varesa
    Commented Jul 9, 2016 at 20:52
  • @varesa You are correct that the ethernet is on the USB bus, but these devices are only crapping-out after a week of uptime. If the devices are remotely accessible while they are up, the OP can deploy this package to them remotely instead of driving out to their physical location. :)
    – tlhIngan
    Commented Jul 9, 2016 at 21:58
  • Ah right, it might work as a pre-emptive measure instead of regular reboots. I was just thinking about fixing already crashed systems. :)
    – varesa
    Commented Jul 9, 2016 at 22:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.