Raspberry Pi 3 USB Ports no longer operating

@dchenson, shabaz and balearicdynamics

I found this thread.....

https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=110164

and this one

https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=162103

It might help....

I have 3 RPi 3's none of them has this issue.

Yunus.

Correct Yunus.

As a matter of fact I think that me and shabaz too considered de facto these or some other test as the initial assertion is that the USB is no longer working. Anyway if not yet tested this is a good way to check via software if all the USB are not working. In the case these are instead working well maybe something wrong to the attached peripherals. The first thing I think is that some sort of short circuit happens to one of the USB (that makes all working bad or not working at all) or an unexpected too high current absorbed by one of the attached peripherals.

Enrico

My thoughts exactly!

Now maybe a good idea that Guest just say something

It does seem strange that there have been a few other reports of all ports not functioning, I too was wondering the same as you, if maybe it was due to accidental shorting of some of the USB socket pins on the underside of the Pi's PCB during experimentation etc, causing a temporary issue until the board is rebooted.

I'm not knowledgeable enough to know what happens if/when that on-board USB hub (LAN9514) goes nuts, does the driver try to reset it. There is no easy way to externally reset it either, and even if a user did manage to do that, the driver might not initialize it again until the entire Pi is rebooted.

It would be good if there was some logging or script that could periodically check the USB hub circuit, and send some information to syslog, so that people could check afterwards to try and find the root cause if they did have to reboot the board.

Hello Shabaz,

I can confirm that - especially when there is current overcharge - the ports stop working (I suppose a sort of protection). Normally resetting the entire PI (power off / power on) will solve the problem.

I have not yet experienced any USB strange behaviour on the PI but Debian, as well as most of the other Linux distributions, will write USB problems in the /var/log/... folder

As far as I know there is no way to reset externally the USB because it is the USB kernel module unloaded to avoid data corruption to other services. This happens with Mac (linux-like), Ubuntu, Debian desktop and many other.

Enrico

Hi Enrico,

I see... thanks for investigating!! It sounds like one option could be if someone developed an optional monitor process that if it detects that USB has failed, then it reboots the board if it cannot reset and reconfigure it. But it wouldn't suit everyone, because some may prefer to keep the Pi running.

It's almost a limitation of Linux if there is no easy way for it to reload the USB kernel module while the rest of Linux is still running, but perhaps that is a security risk or something.. I'm sure there is good reason.

Hi Shabaz,

as far as I know this is the "normal" behaviour of Linux that is usually oriented to save the computer. In most of the cases it is also possible to unload and reload the Kernel but USB is not just "USB", it is an almost complex protocol. By one side the USB is used to connect devices like printers so it manages the protocol as a standard serial (despite that USB itself stays for Universal Serial Bus). But it can also be used - for example - to manage audio on a different layer.

Then there is a sort of exception that is where USB is used to interface HID (human Interface Device), typically keyboard and mouse. The USB HID driver is low level and it is always present, one of the first modules loaded by the kernel as it should provide the minimal essential interface support to communicate with the computer. Different instead while you have a printer or - more generically - a serial interface of the type ttyUsb. In this case the module can be reloaded and the service stopped as well with the kernel running. It is also the case of the Audio interface, serial over USB and other devices.

In a general view all those devices that requires some sort of driver to be loaded as service or kernel module after the first boot level can be unloaded or stopped if the physical hardware can be harmful for the computer.

But without a clear scenario of what is loaded and what is not, it is almost impossible to theorise a right solution or at least a correct troubleshooting.

Enrico

Hi Shabaz,

as far as I know this is the "normal" behaviour of Linux that is usually oriented to save the computer. In most of the cases it is also possible to unload and reload the Kernel but USB is not just "USB", it is an almost complex protocol. By one side the USB is used to connect devices like printers so it manages the protocol as a standard serial (despite that USB itself stays for Universal Serial Bus). But it can also be used - for example - to manage audio on a different layer.

Then there is a sort of exception that is where USB is used to interface HID (human Interface Device), typically keyboard and mouse. The USB HID driver is low level and it is always present, one of the first modules loaded by the kernel as it should provide the minimal essential interface support to communicate with the computer. Different instead while you have a printer or - more generically - a serial interface of the type ttyUsb. In this case the module can be reloaded and the service stopped as well with the kernel running. It is also the case of the Audio interface, serial over USB and other devices.

In a general view all those devices that requires some sort of driver to be loaded as service or kernel module after the first boot level can be unloaded or stopped if the physical hardware can be harmful for the computer.

But without a clear scenario of what is loaded and what is not, it is almost impossible to theorise a right solution or at least a correct troubleshooting.

Enrico