I do have a setup: 2.5" disks connected to the powered USB 3.0 hub. The power adapter is 10A.

If I do start rsync copy from one disk to another after a while I'm getting the error:

rsync error: error in file IO (code 11) at receiver.c(393) [receiver=3.1.2]

All disks disappired. There is no way to return them back, only reboot helps.

 

In dmesg I could find that device jsut stopped and disappired:

[ 2342.927583] usb 5-1.1: USB disconnect, device number 3
[ 2342.931057] usb 4-1: USB disconnect, device number 2
[ 2342.931975] usb 5-1: USB disconnect, device number 2
[ 2345.629932] usb 5-1.3: USB disconnect, device number 4
[ 2345.663838] usb 5-1.4: USB disconnect, device number 5

[ 2342.904003] xhci-hcd xhci-hcd.9.auto: xHCI host not responding to stop endpoint command.
[ 2342.904016] xhci-hcd xhci-hcd.9.auto: Assuming host is dying, halting host.
[ 2342.927380] xhci-hcd xhci-hcd.9.auto: Host not halted after 16000 microseconds.
[ 2342.927400] xhci-hcd xhci-hcd.9.auto: Non-responsive xHCI host is not halting.
[ 2342.927416] xhci-hcd xhci-hcd.9.auto: Completing active URBs anyway.
[ 2342.927502] xhci-hcd xhci-hcd.9.auto: HC died; cleaning up
[ 2342.927543] xhci-hcd xhci-hcd.9.auto: xHCI host not responding to stop endpoint command.
[ 2342.927552] xhci-hcd xhci-hcd.9.auto: Assuming host is dying, halting host.
[ 2342.930928] xhci-hcd xhci-hcd.9.auto: HC died; cleaning up

Any ideas? How to find the reason of this crash?

9 hours ago, Redwid said:

The power adapter is 10A

 

The usual underpowering syndrome is undervoltage so amperage ratings are most of the time pretty useless. Almost all those USB3 host controllers in ARM SoCs are somewhat limited (e.g. count of maximum endpoints) and putting an USB hub between disk and host is something I would try to avoid.

Is it possible to prove that? Let's say log voltage or measure something during copy operation? Is there any threshold before which usb host goes off?

4 hours ago, Redwid said:

Is it possible to prove that?

 

With Rock64 and especially in such a scenario with an external USB hub only by measuring voltages at the drive's side.

 

And please keep in mind what I've written above about USB3 controller limitations with ARM SoCs. I consider USB storage 'unreliable storage' by definition and as soon as an USB hub is in between host and drives as 'utterly unreliable storage'.

 

The only thing I would put in between a Rock64's USB3 port and 2 disks is this JMS561 thing mentioned here: https://forum.openmediavault.org/index.php/Thread/19871-Which-energy-efficient-ARM-platform-to-choose/?postID=169303#post169303 (but exactly that. Hardkernel sells something called 'Cloudshell 2' for their ODROID-XU4 which is also based on JMS561 but their device suffers/sufferend from serious firmware issues)

Thanks tkaiser, as usual you provide a quite valubale answer.

 

Do you believe that disconnects issue could be related to this one: https://github.com/rockchip-linux/kernel/issues/34

59 minutes ago, Redwid said:

Do you believe that disconnects issue could be related to this one: https://github.com/rockchip-linux/kernel/issues/34

 

All the affected people in the referenced issue are using USB hubs. I never use USB hubs in between host and disk and just get the usual xhci error once I connect a SuperSpeed disk to Rock64 and besides that everything is fine.

 

If I would want to connect two fast disks to an SBC I choose an appropriate SBC or maybe would test such a JMS561 thing (but in my personal opinion USB attached storage is a bit too unreliable so I try to avoid it where possible)