USB and LAN randomly disconnects. any help? or ideas to replicate it?

[xAda]

to recap:

• Tinkerboard (rev 1?) has 2 USB devices (from RK3288's internal ports), one for the Realtek HD audio, and one for the 4 USB ports (Genesys 4-port USB hub). 
  • while i have no info for the HD audio, the hub is powered via the 5V lines (noted as V5 pin in the datasheet). my mistake would be not checking if all the 5V power lines are shorted, or it's just connected to the hub. there's an option to NC the pin if using an external regulator (say, the RK808 power management chip?)
• The LAN is separated to the hub and instead directly connected to the RK3288
  • At least the datasheet for RK3288 says. no pinouts whatsoever so i think this is all inside the chip

I noticed this strange behavior across unique setups (LAN connected, 1x keyboard-usb combo, and even 1x-3x USB SATA devices (power separated since these are 3.5 inch drives))

• Sometimes the USB hub disconnects for no particular reason while turned on
  • "disconnects", i mean, when SSH over the device the `lsusb` appears nothing but the Realtek devices. the Genesys hub isnt listed.
  • i wouldnt associate it with power considering that the whole board only consumes 0.7A Max (on all those setups) when connected to an ammeter
  • this carries over across reboots and wont reset until power was disconnected off the wall.
    • i need to rest the board for a while (like several minutes) without power and peripherals. probably a polyfuse triggering and resetting?
  • this also happens on occasions when i plugged failing drives. 
    • i was thinking if it has to do with `usb 1-1 disconnected` where the kernel restarts the USB devices on General Failure on the SATA commands. but it's a weird behavior that it restarts the whole hub rather than the device itself. 
• Sometimes the LAN disconnects as well simultaneously
  • cant SSH over the LAN, only via WiFi.
  • this can be resetted via a reboot, unlike the USB hub.

any help would be appreciated, or tips to recreate this. i was thinking of using USB load testers as a stress test. a limitation of mine is also me not providing /var/log/syslogs on these events considering i cant access the device when this happened.

[crr]

I'm using Tinkerboard with  USB connected SATA HDD for 5 years as 24/7 server and had no similar issues with powering.

The device is powered by dual USB socket power supply (1x USB to power TB, 1xUSB to power HDD via Y-USB cable).

I would start with metering voltage or plugging cheap voltage monitor between power supply and TB.

Try also USB power supply providing 5.2V instead of 5.0V

It should also work when power is only provided to TB USB output (from external powered USB hub)

 

I had similar issues with Raspberry Pi 3B - with similar configuration (USB 1xHDD 2,5") and main indicator of failure was undervoltage - (vgencmd indicated ) and changing power supply did not help.

The only solution I've found for it was to programatically power cycle Raspberry Pi built-in USB hub every time when HDD was not available.

 

 

[Ikesankom]

Hello. I've same problem in ethernet and WIFI interfaces. The "fix" I made is a process which runs at system start and ping throung end0 interface (ethernet) every five minutes to the gateway and reestablish connection when it is down. It also makes a file which shows the last down time.

 

If you want, I can share the code.

[xAda]

@crr
sorry if it took this late, i dont usually read the forums that much. also i downtimed my media box for other reasons (cleanup, transferring files, diagnostics)

with that said.

Quote

I would start with metering voltage or plugging cheap voltage monitor between power supply and TB.

 

yeah i should try that in the future honestly. but for now i just ignored this because this happened spontaneously, with only same thing being there's failing HDDs. i removed the offending HDDs and that worked.

the power supply has an ammeter and voltmeter on it. it stays under 0.7A to 1.4A whenever i use it on my usual usecase. problem persists.
 

Quote

Try also USB power supply providing 5.2V instead of 5.0V

oh right i forgot to mention, i use a boost down converter here with adjustable current and voltage. checking back i use 5.7V @ 3.0A. should i increase it to 6v? tinkerboard can handle up to 6.2V, everything else is regulated.

Quote

It should also work when power is only provided to TB USB output (from external powered USB hub)

i dunno if this is valid, but i used an ATX PSU on this because i can separate the SATA power lines of my internal SATA. so the current running through the USB lines is all just for powering the SATA-USB hub. problem persists even if i only connect a single (failing) drive
 

Quote

The only solution I've found for it was to programatically power cycle Raspberry Pi built-in USB hub every time when HDD was not available.

i wonder if there's like this on tinkerboard? thanks

[xAda]

@Ikesankom

sorry for the late replies.

wait can you share us the code for that? i probably might need it for checking on stuff.

also i get weird SSH timeouts whenever i overload the board for some reason. thanks!

[Ikesankom]

@xAda

 

##recuperaRed.sh##

#!/bin/bash
__dir="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
nombreInterfaz="end0"
puertaEnlace="172.16.5.1"
    if ping -I $nombreInterfaz -c 1 $puertaEnlace &> /dev/null
    then
        echo "La interfaz $nombreInterfaz está activa."
        echo "Última comprobación interfaz $nombreInterfaz: $(date)" > ${__dir}/recuperaRed.log
    else
        echo "La interfaz $nombreInterfaz está caída. Reiniciando..."
        ifdown $nombreInterfaz && ifup $nombreInterfaz
        echo "Última caída de $nombreInterfaz: $(date)" > ${__dir}/ultimacaida.log
    fi

The variables are in Spanish (change the names if you want). It makes two files:

• A file which shows last  interface check (recuperaRed.log)
• And other file which shows last down (ultimacaida.log)

Both are overwriten every time.

 

In crontab -e (use root crontab) add this entry:

 

*/5 * * * * /pathToFile/recuperaRed.sh >/dev/null 2>&1

I have put 5 minutes. Change the runtime you want.