I have monitored CPU temperature and load average, both pretty low.
I have tried to blacklist UAS, connect to Usb2 port, connect to powered USB3 Hub, but nothing worked.
I have also done some iperf (100MB and 1 GB files), memtester and sbc bench testing on it, all showing good results.
But still when using it for high IO loads (Storj), it crashes frequently.
Just for comparison, when I'm running the same IO load, using the disk and adapter connected to my Odroid XU4, its working perfectly for days now...
The Rock64 is really disappointing in this matter. It is pretty useless for NAS or other disk uses.
Now I'm running CPU intensive loads (crunching BOINC) on it without problems or hangs for days.

This is very long thread. I had some occurrences being able to reproduce it, but I'm unable to do it anymore.
I wonder what is the factor that makes it unstable. I plan to set up Rock Transformer with some SATA HDD and run some payload for a few days to reproduce the error. I don't think that this is HW problem, rather this is that we did not configure something properly, or there are too many commands enqueued and maybe it requires some quirks. The usual problem is really underpowering. This tells that we likely have some underpower issue somewhere, just we need to figure out what.
I recently discovered underpower for PCIE/SDIO for RockPro64. The setting was different than what was written in docs, but this greatly improved stability (no problem anymore). I guess we have similar issue here too. Maybe, some regulator instead of 3.3V runs on 1.8V, tec.

Thanks a lot for all the contributions! I've tried to keep some kind of summary at Pine64's forums that also include links to some of my dmesg outputs just before crashing (it is worth noticing that there are some messages at boot related to power regulation) as well as some info at Armbian's. Other rk3399 boards have the same problems. I've also contacted Pine64's support asking if there is at least one known setup that works in a stable way (hoping they could also have a look at the issue).
@ayufan By the way, I could not find any DTB for your precompiled kernels, so I keep on relying on Armbian's 4.4.174 dtb. Is this right or could it be a reason for such issues?

These boot messages are mostly harmless.
Everything is here: https://github.com/ayufan-rock64/linux-kernel/ and here https://github.com/ayufan-rock64/linux-kernel/blob/release-4.4/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts.

@ayufan what do you mean exactly by underpower?
I can reproduce the issue using a powered USB hub  and externally powered USB drives (I mean 3.5in hard drives with external power source).
Would you say that the latest kernels might fix the issue? Last time I tried to upgrade my system it didn't even boot,so I might have to go through a clean setup

Underpower of some parts of SoC, not disk itself, but also disk.

I finally managed to understand why neither pine64 nor you (@ayufan ) could reproduce this bug: this has to do with usb autosuspend. On a freshly booted system, USB3 works perfectly fine. On a system that has been idle for a day (so the USB had time to suspend), the problem is back with tons of error messages as soon as I try to copy a few hundred Mb. This was also mentioned in this thread.

Wow. This is amazing find. I will add the autosuspend=-1 to default
config.
On Thu, Jun 13, 2019 at 5:22 PM Mathias Bavay<EMAIL_ADDRESS>wrote:

I finally managed to understand why neither pine64 nor you (@ayufan
https://github.com/ayufan ) could reproduce this bug: this has to do
with usb autosuspend. On a freshly booted system, USB3 works perfectly
fine. On a system that has been idle for a day (so the USB had time to
suspend), the problem is back with tons of error messages as soon as I try
to copy a few hundred Mb. This was also mentioned in this thread
https://forum.pine64.org/showthread.php?tid=5557&page=2.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ayufan-rock64/linux-build/issues/112?email_source=notifications&email_token=AASOSQLUE4KMID34OF5EWC3P2JQ43A5CNFSM4ESNUMY2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXUBV3I#issuecomment-501750509,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AASOSQKAJIS5ZAUKZVJR6C3P2JQ43ANCNFSM4ESNUMYQ
.

I wonder what is the factor that makes it unstable

@klerai mentions 'a powered USB 3 hub'
@Linux-cpp-lisp mentions 'an unpowered hub'
@PeterPlatt doesn't mention whether he uses a hub or not
@marcosscriven mentions 'another hub'
@stevefan1999-personal doesn't mention whether he uses a hub or not
@Redwid mentions 'usb 3.0 powered hub'
@ShapeShifter499 mentions 'powered USB 3.0 hub from Amazon' and later 'Anker 10 Port 60W Data Hub with 7 USB 3.0 Ports and 3 PowerIQ Charging Ports'
@h31 mentions 'an externally-powered USB 3.0 hub'
@mikescandy mentions 'hub anker'
@rrcoons implies by 'connect new/more disks' also using a hub
@Lakewell doesn't mention whether he uses a hub or not
@dkimmortal mentions 'new USB Hub with Realtek controller'
@D4rkSl4ve doesn't mention whether he uses a hub or not
@ibeleski doesn't mention whether he uses a hub or not
@bavay doesn't mention whether he uses a hub or not
@rlking doesn't mention whether he uses a hub or not
@skeks mentions 'an usb 3 hub'
@whirm mentions an external multi bay enclosure either containing an USB3 hub or a port multiplier and later implies he was using an USB hub by 'tried with a powered USB3 device in between'
@meetyg mentions 'powered USB3 Hub'

In my personal opinion using any kind if hub between USB host controller and USB storage is simply asking for trouble. Rock64 is fine for one single USB3 disk when powering is sufficient and the USB-to-SATA bridge doesn't suck.

Other rk3399 boards have the same problems

@bavay that's NanoPi M4 where everything connected to one of the 4 USB ports is behind an internal USB3 hub. Everything as expected I would say...

For all those affected by similar problems without an USB hub in between please remember that it always can be an underpowering problem even if you think you would power your disk externally and sufficiently: https://forum.openmediavault.org/index.php/Thread/27556-System-partition-full-newbie/?postID=206272#post206272

@ThomasKaiser I have never used any hub, always direct connection: RK3399 -> JMS578 -> Sata Samsung SSD. As I have now seen, playing around on a freshly booted system works perfectly fine. Not problems at all. But once the system has been idle for a while (so most probably the usb has been in sleep mode), there is no way of reading or writing any significant amount of data from/to the usb3 (see my dmesg higher up). The usb-to-Sata bridge works flawlessly on my laptop (Debian Testing) with a very high transfer rates (my JSM578 has the patched firmware from HardKernel) and for the power supply, I even tried a 6A one, nothing helped.
I have now tried to set usb 'autosuspend=-1' on a freshly booted system (the exact same hardware as the last few months, using the stock 3A power supply), no problems anymore, everything works like a charm, high transfer rate and not a single message in /var/log/messages.
@ayufan Is there a simple way to set this kernel parameter at boot without recompiling the kernel? It would take me half a minute on a "normal" Linux system, but without my grub, I'm kind of lost!

@ThomasKaiser I had both used it (and tested with external-power then tried not so as well) and not used it (directly plugging the appliance into the USB port of my Rock64), both of which lead to the same USB hangup observation and caused production data loss (luckily it is for my personal use).

now tried to set usb 'autosuspend=-1'

@bavay what should change here? I've a rather old @ayufan build on my RockPro64 without any tweaks:
root@RockPro64:/# uname -a
Linux RockPro64 4.4.132-1075-rockchip-ayufan-ga83beded8524 #1 SMP Thu Jul 26 08:22:22 UTC 2018 aarch64 GNU/Linux

root@RockPro64:/# lsusb
Bus 004 Device 002: ID 174c:55aa ASMedia Technology Inc. ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

root@RockPro64:/# dmesg | grep 55aa
[    2.671779] usb 4-1: New USB device found, idVendor=174c, idProduct=55aa

root@RockPro64:/# cat /sys/bus/usb/devices/4-1/power/control
on

It's already on and not auto. How should setting autosuspend=-1 change anything here?

@ThomasKaiser it should instead turn off auto suspension of the USB subsystem that is more or less high related to the problem we're facing.

If you use my images, edit /etc/default/extlinux.
This https://github.com/ayufan-rock64/linux-kernel/releases/tag/4.4.167-1206-rockchip-ayufan has autosuspend=-1 by default.

@ayufan I wonder where is the mainline kernel for R64? Is Linux 5.x ready for R64?

@stevefan1999-personal It is very useable, maybe not GPU yet (it should change with 5.2 and 5.3), but for headless it works very well.
I'm not testing that very often, but you can try:
https://github.com/ayufan-rock64/linux-mainline-kernel/releases

@ThomasKaiser It sets it for the whole usbcore, not on a per-device basis. Now, I have:
cat /sys/module/usbcore/parameters/autosuspend -> -1
and cat /sys/bus/usb/devices/4-1/power/control -> on
@ayufan I am using Armbian and I've just found that it should consists (if I understood everything) in adding the following to  /boot/armbianEnv.txt :
extraargs=usbcore.autosuspend=-1
I still need to reboot and check if it got properly set though...

@stevefan1999-personal It is very useable, maybe not GPU yet (it should change with 5.2 and 5.3), but for headless it works very well.
I'm not testing that very often, but you can try:
ayufan-rock64/linux-mainline-kernel/releases

Cool. Will test autosuspend=-1 on mainline to see if it happens as well.

@thomaskaiser I didn‘t use any hub, I directly connected an Alpha Wifi dongle and only in USB3 mode xhci will die under heavy load
@stevefan1999-personal I‘m on vanilla 5.1.x and it works flawlessly with rock64, I recommend ayufans dts though

cat /sys/module/usbcore/parameters/autosuspend -> -1
and cat /sys/bus/usb/devices/4-1/power/control -> on

Please, tell me what has changed exactly:
root@RockPro64:~# cat /sys/module/usbcore/parameters/autosuspend
2
root@RockPro64:~# cat /sys/bus/usb/devices/4-1/power/control
on

This is my setup. With an unaltered ayufan build from long time ago. Autosuspend is off for the device in question. Now you make a change to still set it off. What has changed here?

Quoting this kernel document:

power/control

	This file contains one of two words: "on" or "auto".
	You can write those words to the file to change the
	device's setting.

	"on" means that the device should be resumed and
	autosuspend is not allowed.  (Of course, system
	suspends are still allowed.)

	"auto" is the normal state in which the kernel is
	allowed to autosuspend and autoresume the device.

So please tell me whether this is set to on or auto in your install without fiddling around with kernel cmdline. Please also look at the default /sys/module/usbcore/parameters/autosuspend which is 2. That's 2 seconds and not hours or days and as such I don't understand how this should be related to the idea USB autosuspend would affect behavior 'once the system has been idle for a while (so most probably the usb has been in sleep mode)' quoting @bavay.

@ayufan why don't you encourage users to provide output from rock64_diagnostics.sh -u when they want to open issues here? The tool is there to provide insights such as 'is the device behind a hub?' and also collecting relevant dmesg output. It's so easy for users to provide real information not garnished with interpretations and wild guesses:
root@RockPro64:~# rock64_diagnostics.sh -u
Generating diagnostic logs...

IP obfuscated log uploaded to http://ix.io/1LKy
Please post the above URL on the forum where you've been asked for it.

In my personal opinion using any kind of hub between USB host controller and USB storage on host controllers with limited endpoint support is simply asking for trouble. Rock64 is fine for one single USB3 disk when powering is sufficient and the USB-to-SATA bridge doesn't suck.

So Rock64 should just say "the system doesn't support usb3 hubs". I would be happy with that. Anything else is nonsense. If the system states that they support USB3, it implies that it works with USB3 hubs. Power issues should be manageable with powered hubs or powered enclosures.

@ThomasKaiser on my system (running kernel 5.1.0-1111-ayufan-g626fd74bbb54 but it was exactly the same with all Armbian's kernel, 4.4, 4.20 or 5.0), AFTER  doing:
echo -1 > /sys/module/usbcore/parameters/autosuspend
(ie not using kernel command line parameters) I now have (in this setup, my usb3 works flawlessly):
root@rockpro64:/boot» cat /sys/module/usbcore/parameters/autosuspend
-1
root@rockpro64:/boot» cat /sys/bus/usb/devices/4-1/power/control
on

To clarify my previous post : on a default system (ie NOT tweaking autosuspend), if I start the system (with my ssd already connected to the usb3 at boot) and copy a large file to the ssd as soon as I could ssh to my rockpro, everything works. If I wait (I've waited at least one hour, trying it again after lunch break), and then copy the same large file to the same sshd, I get loads of error messages in my /var/log/messages (see posts above). If I keep transferring data over usb3, at some point I get filesystem corruption and/or kernel crash (at least for kernels 4.4).
I then did another test: fresh boot and as soon as possible tweaking autosuspend (without editing the kernel command line parameters, just through the sys interface). Then I waited a while (again, more than an hour) and tried to copy the same large file to the same ssd. And everything worked flawlessly! I've tried it again the next day, everything works (I never managed to have it work in the last several weeks).
I can provide another copy of my dmesg now (ie the version where usb3 works), but there is nothing to see, beside the normal boot I don't get any other messages... I hope it is now clearer.

f the system states that they support USB3, it implies that it works with USB3 hubs

Which obviously is not the case, see also https://forum.armbian.com/topic/7740-rock64-usb-30-host-controller-crashes-when-accessing-2-disks-simultaneously/?do=findComment&comment=58371
I remember having discussed this with @xalius maybe 2 years ago but forgot about the details. But the xHCI controller on RK (same in RK3328 and RK3399 BTW) has some limitations that affect operation with SuperSpeed hubs. With xHCI and streams data transfers are entirely different compared what USB 2.0 allowed.
And if it's not a hub issue there's always still the lovely USB3-A receptacle crappiness (the contacts for the 5Gbps SuperSpeed connection are laughable tiny while those contacts for old and slow Hi-Speed with just 480Mbps are huge) and all those underpowering problems non-engineers seem not be able to understand since it's most of the time (under)voltage due to cable/contact resistance and not related to any amperage ratings of PSUs or powered hubs at all.

I hope it is now clearer

Not at all since you made a modification that will result in /sys/bus/usb/devices/4-1/power/control --> on while without this modification it would be the same.
Please revert back to no autosuspend modification whatsoever , reboot and post output of cat /sys/bus/usb/devices/4-1/power/control. If it's also on then autosuspend is off anyway. What should have changed here?
If behavior changes after some time of inactivity I could imagine an influence of the drive behind the USB-to-SATA bridge going into standby/sleep state and something related to that. But how should this be related to USB autosuspend where the default value is 2 seconds anyway and at least on my system autosuspend is disabled too?

BTW: Even if I try to enable autosuspend it simply doesn't work at all:
root@RockPro64:~# echo auto > /sys/bus/usb/devices/4-1/power/control
root@RockPro64:~# cat /sys/bus/usb/devices/4-1/power/autosuspend_delay_ms
2000
root@RockPro64:~# sleep 5 ; cat /sys/bus/usb/devices/4-1/power/runtime_suspended_time
0
root@RockPro64:~# hdparm -y /dev/sda

/dev/sda:
 issuing standby command
root@RockPro64:~# sleep 5 ; hdparm -C /dev/sda

/dev/sda:
 drive state is:  standby
root@RockPro64:~# sleep 5 ; cat /sys/bus/usb/devices/4-1/power/runtime_suspended_time
0
root@RockPro64:~# cat /sys/bus/usb/devices/4-1/power/control
auto

Manually enabled autosuspend for the device in question, checked that suspend should be activated after 2000ms (2 seconds -- the default), even sending the SSD to sleep. Still 0 seconds in suspended state. To me this seems autosuspend simply doesn't work on my RockPro64 with a connected USB3 SSD.

@ThomasKaiser I will try to reboot and post the output of /sys/bus/usb/devices/4-1/power/control this evening.
Other than that, I have no clue what it does or does not, but what is absolutely certain is that on a default system (Armbian with kernel 5.1.0-1111-ayufan-g626fd74bbb54), I can not read/write data on USB3 (hdparm always worked, what I mean is a real amount of data, let's say 1Gb), I get corrupted data and tons of error messages. If I do 'echo -1 > /sys/module/usbcore/parameters/autosuspend' after boot (I haven't tried to wait a little, so "something" could go to sleep before submitting this command), I can read/write data on USB3 with the exact same setup even hours after boot. And again, I have no usb hub, and if I do the test seconds after boot, it works in both cases but if I wait a little, this is where it makes a difference (you're right, it is most probably the ssd going to sleep, then it would mean that without "autosuspend=-1" it does not wake up properly). I have no clue what goes wrong in the background, but at least this is a test scenario that shows how to reproduce the bug or how to avoid the bug. Before this "magic option' I could not use my rockpro as a NAS, now I can... I know it is frustrating when a bug does not make sense, but at least we now have a starting point.

you're right, it is most probably the ssd going to sleep, then it would mean that without "autosuspend=-1" it does not wake up properly

Absolutely not. This is just another wild guess. This whole 'USB3 with SBC' sh*t show consists of different and independent ingredients:

with USB3/xHCI USB3 hubs become a problem with more than one device behind the hub accessed in parallel due to endpoint limitations of the Rockchip xHCI controller implementation.
USB cables between host and device are mostly the root cause for undervoltage drama due to tiny cable diameters and long cables (see [1] below). The power brick in question isn't that important at least with RockPro64 since here the voltage drops between board and disk.
 Simply look inside (see [2] below]. Those contacts for the old 480Mbps signal rates are huge and it's close to impossible to ever get any connection problems with Hi-Speed (USB2). Those laughable tiny SuperSpeed contacts for the data traveling at a 5000Mbps signal rate are prone to contact issues.  See the very same problem, one time with UAS enabled, then with UAS disabled -- exactly same problem, just error messages differ)

So while it's great that you are now able to transfer data between RockPro64 and an USB3 connected SSD this is nothing special as long as

no USB3 hub is involved,
no underpowering happens,
no cable/contact issues are involved and
the USB-to-SATA bridge in question is not crap

The idea that 'something went to sleep' sounds nice but to nail a problem down a more scientific approach is IMO better. The commands posted above should help identifying what's going on and please instead of posting dmesg excerpts always and only provide results from rock64_diagnostics.sh -u. Only this contains valuable information about the specific setup (for example with cascading hubs the whole connection might be established just with USB2/Hi-Speed any more and as such xHCI endpoint limitations aren't an issue).
[1] voltage drop depending on AWG rating, consumption drawn and cable length:

[2] USB3-A receptacle:

So while it's great that you are now able to transfer data between RockPro64 and an USB3 connected SSD this is nothing special as long as [...]

I think you've missed the point: the exact same setup could not transfer data, now it can (and although I can not promise anything for under-power issues, the same setup with the same 15cm long cable always worked flawlessly on my laptop). I know I should refrain from wild guesses, but since a software change (not even touching the hardware setup in between) makes it now able to work, I would rule out the usb3-A receptacle as well as the cable.
By the way, I am NOT running Ayufan's distribution, so I did not have rock64_diagnostics.sh (I am running Armbian). I've now downloaded a copy of rock64_diagnostics.sh but the "-u" option failed to work ((52) Empty reply from server), so I've copied its output to pasbin for the version where "autosuspend=-1". I will copy this evening the version where no "autosuspend" tweak has been done (and after a reboot).

By the way, I am NOT running Ayufan's distribution, so I did not have rock64_diagnostics.sh

Even better, please use armbianmonitor -u then (will work on ayufan images as well since we made it a symlink there to rock64_diagnostics.sh).
And no, I don't miss your point. I'm fully aware that something that didn't worked before now seems to work and that you blame a specific change somewhere for this (why I don't believe that could be the culprit I already outlined above. Posting output of grep . /sys/bus/usb/devices/*/power/control after a reboot will reveal whether autosuspend is enabled or not).
Please note that I've several RK3328 and RK3399 devices with USB3 attached storage. I use no USB3 hubs, had to send one USB3 cable to the bin, had to improve powering in a few setups and everything just works fine there except these two cosmetical messages that appear in dmesg at every boot or when an USB3 device is attached the first time:
xhci-hcd xhci-hcd.6.auto: ERROR Transfer event for disabled endpoint or incorrect stream ring
xhci-hcd xhci-hcd.6.auto: @00000000f005de30 00000000 00000000 1b000000 01038000

So, I've rebooted, no options are set for autosuspend (ie this is the system default, no kernel cmd line parameters nor manually setting things through the sys interface). My diagnostics can be found here. Here are other relevant outputs:
root@rockpro64:/root» cat /sys/module/usbcore/parameters/autosuspend
2
root@rockpro64:/root» cat /sys/bus/usb/devices/4-1/power/control
on

My diagnostics can be found here.

As already suggested: please use 'armbianmonitor -u' instead (way more information when running on Armbian).
Asides that no USB autosuspend active... please report back within 24 hours whether you're still suffering from USB3 storage hassles or not. I will post tomorrow some benchmark numbers from my RockPro64 with an USB3 attached SSD just to show that there's nothing special with USB3 storage as long as

no USB3 hub is involved,
no underpowering happens,
no cable/contact issues are involved and
the USB-to-SATA bridge in question is not crap

This is now the output of armbianmonitor without any special autosuspend stuff and after the system suffered again from the same usb3 issues: http://ix.io/1LPv

I let RockPro64 with an USB3 connected EVO750 rest for approximately 20 hours. I manually enabled USB autosuspend though it's not working anyway as already said.
root@RockPro64:/mnt/sda/userhomes# cat /sys/module/usbcore/parameters/autosuspend
2

root@RockPro64:/mnt/sda/userhomes# cat /sys/bus/usb/devices/4-1/power/control
auto

root@RockPro64:/mnt/sda/userhomes# cat /sys/bus/usb/devices/4-1/power/runtime_suspended_time
0

root@RockPro64:/mnt/sda/userhomes# uptime
 12:43:53 up 1 day,  1:33,  1 user,  load average: 0.00, 0.00, 0.00

root@RockPro64:/mnt/sda/userhomes# iozone -e -I -a -s 1000M -r 4k -r 128k -r 1024k -r 16384k -i 0 -i 1 -i 2
	Iozone: Performance Test of File I/O
	        Version $Revision: 3.429 $
		Compiled for 32 bit mode.
		Build: linux

	Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins
	             Al Slater, Scott Rhine, Mike Wisner, Ken Goss
	             Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR,
	             Randy Dunlap, Mark Montague, Dan Million, Gavin Brebner,
	             Jean-Marc Zucconi, Jeff Blomberg, Benny Halevy, Dave Boone,
	             Erik Habbinga, Kris Strecker, Walter Wong, Joshua Root,
	             Fabrice Bacchella, Zhenghua Xue, Qin Li, Darren Sawyer,
	             Vangel Bojaxhi, Ben England, Vikentsi Lapa.

	Run began: Sat Jun 15 12:44:26 2019

	Include fsync in write timing
	O_DIRECT feature enabled
	Auto Mode
	File size set to 1024000 kB
	Record Size 4 kB
	Record Size 128 kB
	Record Size 1024 kB
	Record Size 16384 kB
	Command line used: iozone -e -I -a -s 1000M -r 4k -r 128k -r 1024k -r 16384k -i 0 -i 1 -i 2
	Output is in kBytes/sec
	Time Resolution = 0.000001 seconds.
	Processor cache size set to 1024 kBytes.
	Processor cache line size set to 32 bytes.
	File stride size set to 17 * record size.
                                                              random    random     bkwd    record    stride
              kB  reclen    write  rewrite    read    reread    read     write     read   rewrite      read   fwrite frewrite    fread  freread
         1024000       4     9853     4687    25040    24944    16201     4601
         1024000     128   135045   131001   120678   120602   104026   121352
         1024000    1024   144351   131628   133321   132378   126601   142508
         1024000   16384   395767   179551   355769   359237   355410   345219

iozone test complete.

root@RockPro64:/mnt/sda/userhomes# armbianmonitor -u
Generating diagnostic logs...

IP obfuscated log uploaded to http://ix.io/1LQi
Please post the above URL on the forum where you've been asked for it.

Works just as it did the last 2 years regardless whether I used an ASM1153 like here, a JMS567 or a JMS578.

@bavay ZRAM is not working which is something you might want to report over at Armbian. Most probably the module needs other parameters with kernel 5.x

BTW: all the USB3 hub users reporting xHCI host not responding to stop endpoint command occurrences when having more than one USB3 device active behind the hub (applies to @klerai, @Redwid, @ShapeShifter499 and @mikescandy above) are not alone.
Same happens on ODROID XU4 (Exynos 5422 with internal GL3521, on ODROID N2 (S922X with internal GL3523) and NanoPi M4 (RK3399 with internal VL817):

https://www.google.com/search?q=xHCI+host+not+responding+to+stop+endpoint+command+site:forum.odroid.com
https://forum.armbian.com/topic/8828-rsync-between-two-external-hdds-caused-rootfs-vanished/?tab=comments#comment-66895

I would assume all those ARM SoCs rely on the same USB3 IP block (Synopsys DesignWare) and suffer from the same limitation (limited endpoint issue). Maybe a software fix is possible.

@ThomasKaiser First, thanks for pointing out the zram problem. I will report it! Thanks also for your iozone command line and output. I've now ran the exact same command line, here are my results:
iozone -e -I -a -s 1000M -r 4k -r 128k -r 1024k -r 16384k -i 0 -i 1 -i 2
        Iozone: Performance Test of File I/O
                Version $Revision: 3.429 $
                Compiled for 64 bit mode.
                Build: linux

        Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins
                     Al Slater, Scott Rhine, Mike Wisner, Ken Goss
                     Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR,
                     Randy Dunlap, Mark Montague, Dan Million, Gavin Brebner,
                     Jean-Marc Zucconi, Jeff Blomberg, Benny Halevy, Dave Boone,
                     Erik Habbinga, Kris Strecker, Walter Wong, Joshua Root,
                     Fabrice Bacchella, Zhenghua Xue, Qin Li, Darren Sawyer,
                     Vangel Bojaxhi, Ben England, Vikentsi Lapa.

        Run began: Mon Jun 17 09:40:14 2019

        Include fsync in write timing
        O_DIRECT feature enabled
        Auto Mode
        File size set to 1024000 kB
        Record Size 4 kB
        Record Size 128 kB
        Record Size 1024 kB
        Record Size 16384 kB
        Command line used: iozone -e -I -a -s 1000M -r 4k -r 128k -r 1024k -r 16384k -i 0 -i 1 -i 2
        Output is in kBytes/sec
        Time Resolution = 0.000001 seconds.
        Processor cache size set to 1024 kBytes.
        Processor cache line size set to 32 bytes.
        File stride size set to 17 * record size.
                                                              random    random     bkwd    record    stride
              kB  reclen    write  rewrite    read    reread    read     write     read   rewrite      read   fwrite frewrite    fread  freread
         1024000       4    34656    39388    49732    49485    22563    35783
         1024000     128   231009   238778   260702   256941   223424   243448
         1024000    1024   313740   304556   308905   308408   296177   301161
         1024000   16384   357077   358535   382018   381052   377740   356692

iozone test complete.

For completeness, I've also tried with iozone -e -I -a -s 10000M -r 4k -r 128k -r 1024k -r 16384k -i 0 -i 1 -i 2 (since for the last few days, I had trouble seeing the bug with too small data transfers). No problems at all, everything runs very smoothly (as you can see in the above output). I have not copied here the outputs for the 10G test, they look close enough to the 1G case enough (at least to my untrained eyes).
Now, I've tried a copy of my nextcloud folder (sitting on the sdcard) to the usb3 disk (the said folder is slightly over 80G big, it contains lots of pictures and mp3s). After a few seconds (I'm sorry, I did not time it, I would say it was for sure less than a minute, so not a huge amount of data since the sdcard is quite slow, the copied folder is now 919M) -> a full page of usb3 error messages. I could not get armbianMonitor -u to work (same "Empty reply from server" error), so I've copied the output of rock64_diagnostics.sh. I'll keep my system untouched for the moment, so if you can tell me how to dump armbianMonitor's output to a file, I can provide it to you.

I could not get armbianMonitor -u to work (same "Empty reply from server" error)

That's always just a temporary problem with the ix.io server, in that case armbianmonitor -U outputs to stdout. But not necessary to provide this output this time (since dmesg output already captured and containing almost all relevant information). It would be more interesting to get output from
cat /sys/module/usbcore/parameters/autosuspend
cat /sys/bus/usb/devices/4-1/power/control
cat /sys/bus/usb/devices/4-1/power/autosuspend_delay_ms
cat /sys/bus/usb/devices/4-1/power/runtime_suspended_time
iostat

Here are the first 4:
root@rockpro64:/root» cat /sys/module/usbcore/parameters/autosuspend
-1
root@rockpro64:/root» cat /sys/bus/usb/devices/4-1/power/control
on
root@rockpro64:/root» cat /sys/bus/usb/devices/4-1/power/autosuspend_delay_ms
-1000
root@rockpro64:/root» cat /sys/bus/usb/devices/4-1/power/runtime_suspended_time
0

And here is iostat:
Linux 5.1.0-1111-ayufan-g626fd74bbb54 (rockpro64)       06/17/19        _aarch64_       (6 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.39    0.00    0.23    0.18    0.00   99.19

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
mtdblock0         0.00         0.00         0.00        108          0
mtdblock1         0.00         0.00         0.00         20          0
mtdblock2         0.00         0.00         0.00         36          0
mmcblk1           1.56         4.83        46.08     642781    6132820
mmcblk1boot1      0.00         0.00         0.00        216          0
mmcblk1boot0      0.00         0.00         0.00        216          0
mmcblk0           0.44        16.71         1.73    2223748     229624
sda             132.94      1016.08      1022.58  135229293  136093896

(I killed the copy as soon as I got the error messages to avoid filesystem corruption as well as to keep my system in a good enough state for further diagnostics)

root@rockpro64:/root» cat /sys/bus/usb/devices/4-1/power/control
on
root@rockpro64:/root» cat /sys/bus/usb/devices/4-1/power/runtime_suspended_time
0

This means USB autosuspend is off. Just as on my system (and most probably every other RK3399 device out there regardless what's written to /sys/module/usbcore/parameters/autosuspend -- unfortunately other thread contributors do not collaborate on nailing this problem down -- looking at runtime_suspended_time clearly reveals whether USB autosuspend ever kicked in or not --> 0).

to avoid filesystem corruption

Your filesystem was already corrupted, see the previous dmesg output. Unmounting and running an fsck is highly recommended. And I still see zero evidence for anything related to /sys/module/usbcore/parameters/autosuspend since USB autosuspend doesn't work anyway here and the reasons for USB3 device resets are mostly hardware related.

Just for clarity, the test I posted 1 hour ago (there) was done on a system that has been booted Saturday evening and saw no intensive usage (basically idle the whole time with no usb3 activity for the whole duration) until performing the iozone tests. Of course, it is now corrupted but I can still do ls on the usb3 disk without getting caught in a never ending kind of loop, so it is still reasonably usable in order to gather diagnostics info :-)
Now the interesting thing is that if I take the same usb3 disk (is same enclosure, same usb3 cable and same ssd), plug it in my laptop usb3 port, take the sdcard in my laptop and do the copy on my laptop, everything works (on my laptop it is used in "uas" mode by lsusb with a bandwidth of 5000M, so I guess this means it is indeed used as usb3?). If you want me do do some tests or gather some diagnostics on my laptop, please let me know (it runs Debian Buster).

if I take the same usb3 disk (is same enclosure, same usb3 cable and same ssd), plug it in my laptop usb3 port, take the sdcard in my laptop and do the copy on my laptop, everything works

Then most probably your issue is called undervoltage. To know for sure you need to measure (just like this other undervoltage victim). And you need to measure under load since this is the problem with Ohm's law: only when consumption is high the voltage will drop if there's too much cable/contact resistance.
On Rock64 situation is different since here already a drop in supply voltage (DC-IN) is possible and as such Rock64 users might experience undervoltage at an USB3 disk device when Rock64 itself consumes more (on RockPro64 with 12V input voltage and DC-DC circuitry to generate the 5V Vbus voltage this is not an issue).
And then of course all strange things can happen due to the USB3 host controllers on our SBC maybe being a bit quirky (see this explanation) which is why I seriously want to get rid of this USB3 mess on SBC and want an affordable SBC variant with PCIe attached SATA :)

Of course, it is now corrupted

The filesystem was already corrupted at boot:
[   44.109229] EXT4-fs warning (device sda1): ext4_clear_journal_err:4997: Filesystem error recorded from previous mount: IO failure
[   44.109236] EXT4-fs warning (device sda1): ext4_clear_journal_err:4998: Marking fs in need of filesystem check.
[   44.130112] EXT4-fs (sda1): warning: mounting fs with errors, running e2fsck is recommended
[   44.159883] EXT4-fs (sda1): recovery complete
[   44.166337] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: commit=600,errors=remount-ro

And the next occurrence in your dmesg output is just one single thing: between<PHONE_NUMBER>22 and<PHONE_NUMBER>38 (that's 0.2716 milliseconds) there are occurrences of uas_eh_abort_handler for uas tags 1 to 30 and then the driver initiates a device reset which successfully finished at<PHONE_NUMBER>88 (that's 17.5866 milliseconds later). Without UAS the same would've happened just with different dmesg output due to usb-storage driver in use.
Wrt your laptop. There are two things different:

powering (my laptops are all MacBook Pro and known for providing stable 5.xV even when devices draw the maximum 1100mA here, most probably the same applies to other laptops even if they limit max amperage to 950mA while most SBC, especially those powered by 5V either deliver 950mA or 5.xV on an USB3 port)
different USB3 host controller (lspci will tell). Most probably the RockPro64 users affected by the USB3 hub issues could be happy by using an ASM1042A controller in the PCIe slot (less than 10 bucks on Aliexpress -- though makes no sense of course to buy an USB3 controller for a board that has been bought for its USB3 capabilities).

Just to clarify, @ThomasKaiser I mentioned USB3 hub, but just tried it to see if it fixes problems that I had without it.
Anyways, I disabled auto suspend (shows up as -1 when I run cat on the module) but still it didn't solve my problem.
The JMICRON is connected directly to the USB3 port. After a few hours of some IO load, the system froze again (as usual), requiring me to pull the power on it.
BTW, I also connected a USB meter between the JMICRON and the usb3 port, and its not an underpower issue. I'm getting above 5v when load is running, and it uses up to 260 miliamps, which is far from usb3 limits.
Its driving me crazy!
When I connect the JMICRON and disk to my Odroid Xu4, it runs for days with the same load as on the Rock64, without problems.
Other than that I have no stability issues with the Rock64, such as when running high cpu loads.

I disabled auto suspend (shows up as -1 when I run cat on the module) but still it didn't solve my problem

You can't switch something that's already off to 'more' off. USB autosuspend isn't active anyway as everybody can figure out by querying the respective runtime_suspended_time sysfs node.
The problems with failing USB3 equipment are manyfold as I already tried to explain. With USB3 hubs it's supposed to fail anyway (one potential fix might be to disable streams), then slightly bending the USB cable might result in the same as when undervoltage under load happens.
Your above report is special since you report 'crashing' (whatever that means) even with an USB2 connected disk. Unfortunately you're using DietPi (which is just a crippled down ayufan Stretch image) where diagnostic tools are removed. Are you able to provide output from rock64_diagnostics.sh -u?
To be able to diagnose a problem diagnostic output is needed.

I also connected a USB meter between the JMICRON and the usb3 port

At which end of the cable? You need to measure not at the board but at the disk since the voltage drop happens inside the cable. But you're reporting crashes/freezes and not USB device resets which is something different.

I've performed more tests, now using an externally powered usb3 <-> sata adapter (ie NOT bus powered, this is the Inatech UA2001 USB 3.0 to IDE/ SATA Adapter). Then, I could copy 19G from the sdcard to the usb3 ssd without any problems.
So, to summarize:

I was using a JMicron enclosure with a Samsung ssd inside;
Everything has always worked perfectly when connected to my laptop;
Once connected to my Rockpro64, I can run iozone benchmarks without any problems;
Once connected to my Rockpro64, I can not copy large volume (several Gb) of data from the sdcard to the usb3 ssd (same applies with scp to the usb3 ssd). No matter which power supply powers the rockpro, there are always data transfer problems quite fast (leading to filesystem corruption);
I have tried several usb3 cables, several power supplies, nothing helped;
If using an externally powered enclosure for the ssd (ie it takes its power from the grid), then everything works perfectly.

I have no idea if the PCIe 4X of the rockpro with the NVMe interface card and an NVMe ssd would be a working solution (is it reliable or is it the same kind of mess on a different interface?)...

JMicron enclosure with a Samsung ssd inside

Can you please link to the device in question? I could imagine this being a combination of unstable powering by RockPro64 and inappropriate power paths inside this enclosure. The only reasonable place to measure for undervoltage occurrences in such a situation is inside the enclosure at the SATA power connector where the disk is attached since only the voltage available here directly at the disk is important and all the power path ingredients in between can be responsible for voltage drops.
No, I don't know how to measure at this place since being an electronics noob with two left hands if it's about hardware.

If using an externally powered enclosure for the ssd (ie it takes its power from the grid), then everything works perfectly.

So in your case it was 'just' the 'usual' USB 5V undervoltage drama we face with most SBC. As @ayufan already hinted to maybe there is something configurable wrt the 5V Vbus supply but most probably that's something we should ask TL Lim. Anyway: this doesn't change a bit that users with USB3 hubs still won't be happy and the usual USB3-A cable/connector hassles can result in absolutely identical symptoms as yours.
Wrt NVMe @ayufan hinted to an underpowering problem affecting SDIO and PCIe which is resolved with his latest kernel/dts. But let's focus on the USB3 issues here and move this over to Pine64's IRC and there the #Rock64 channel.
@bavay since you spread the word about the potential USB autosuspend issue here and there it would also be great if you can correct this with a link to the conclusion of this Github issue.

The enclosure is the an Inatech FE2005, based around JMicron JMS578 chipset (with Hardkernel patches for uas). I have tried to measure the voltage within the enclosure, but I was not successful (my voltmeter probes are too big).
Anyway, I'll post links to this thread around...

more feedback. I had the same issue that commented with a Connexant USB to SATA adapter. After reading this thread and testing the autosuspend=-1 flag , as it didn´t work for me, and as i was in a hurry, i bought the "Fideco docking station" at Amazon, and now it is working wit my Rock64 like a charm. Problem solved.
I know it is not the desired solution, but at least for people without free time it will work.
Regards.

testing the autosuspend=-1 flag , as it didn´t work for me

It can't work. If something's off you can't turn it 'more off'. So your approach for stable USB3 support on Rock64 (or RockPro64?) was again solving undervoltage problems by buying an externally powered Docking station?

testing the autosuspend=-1 flag , as it didn´t work for me

It can't work. If something's off you can't turn it 'more off'. So your approach for stable USB3 support on Rock64 was again solving undervoltage problems by buying an externally powered Docking station?

Yes, but i was also using another externally powered adapter (exactly a very old Conceptronic C05-144). This hardware has been working fine with the Rock64 for half year at least, and these weeks stoped working (freezing the rock64 when i plugged it). Now with the new externally powered docking station (Fideco) Rock64 works perfectly, but summarizing... it is the same hardware with different chipset probably.
My conclusions and hypothesis is that there has been an update last two months which has brought instability to Rock64 with some devices externally powered adapter USB to SATE devices. Power shouldn´t be the problem as i have been using this hardware for a long time, but a power management problem based on a software issue of the new Kernel may be related.

Power shouldn´t be the problem as i have been using this hardware for a long time

So why not accepting that every hardware will eventually die?  It's never an if but only a when question.
We use a lot of mini servers based on Allwinner A20 which allow for full UPS mode due to a power management IC (PMIC) companion and battery support. The PMIC allows for monitoring the input voltages (both DC-IN as well as battery) and with such a setup you can then simply watch el cheapo power bricks slowly dying: https://forum.armbian.com/topic/5699-how-to-provide-and-interpret-debug-output/?do=findComment&comment=44210
In my situation with our cool little lime2 servers dropping input voltage wasn't a problem as long as still the battery got powered. I had to replace this failing PSU only when input voltage fell below 4.0V.
Now imagine the same PSU connected to a Rock64. The PSU providing 5.xV in the beginning after some time only provides 4.xV any more. Not a problem for Rock64 itself since here DC-DC circuitry converts to the internal voltages like 3.3V, 1.8V and so on. But connected USB consumers needing 5V  are of course affected since they now start to fail.
I know, the theory that @ayufan or someone else screwed up some software settings sounds more interesting than accepting that powering boards with 5V simply sucks for the simple reason that aging power bricks will result in lowered input voltage over time which then results in connected USB disks behaving weird or the board even freezing :)

Thanks @ThomasKaiser for amount of time you are spending with this issue.
Is that possible to monitor consumption for rock64 (from software or hardware) to prove that we all here has power issue and not some software settings mis-configuration?

possible to monitor consumption for rock64

AFAIK not. Or at least I don't know. The situation with the aforementioned A20 boards where the AXP209 PMIC can be queried via I2C is nice in such situations and for obvious reasons I added those voltage readouts to armbianmonitor -u output on boards with PMIC that provide this feature. Since if input voltage is dropping a lot below 5.0V you know what's going on.
On boards without PMIC or the necessary ADC converters for internal voltage measurements all you can do is grab a multimeter and measure yourself on testpoints or -- what makes matters really worse -- inside of an attached USB disk enclosure where you're usually not able to measure. At the SATA power connector of the disk in question.

we all here has power issue

With your situation IMO nothing has changed compared to last year. It's the 'concurrent access to two or more disks behind USB3 hub' issue, right?

Just for the record and this 'it must be a software thing!' obsession. The OMV images I created for RK3328 based Rock64 and Renegade have been downloaded several thousand times. I bet @ayufan can report similar download numbers for his OMV images. I also bet that majority of those users is using single disk USB3 storage. Being fine with this (at least the OMV forum is not full of complaints).
Repeating myself: There's nothing special with USB3 storage and RK3328/RK3399 as long as

no USB3 hub is involved,
no underpowering happens,
no cable/contact issues are involved and
the USB-to-SATA bridge in question is not crap

That's the prerequisites. And the longer the setup runs powered by the same 5V power brick the more likely 'underpowering' will happen. At least with USB disks powered by Rock64.

With your situation IMO nothing has changed compared to last year. It's the 'concurrent access to
two or more disks behind USB3 hub' issue, right?

I have one disk connected to usb 3.0, and hub connected to usb 2.0 (with multiple disks on it). Working fine, no crashes. Only transfer speed is an issue there.

But in my case, the old USB-SATA adapter (the one that has suddenly stopped working with Rock64, after working with it for half year...) works perfectly in other PCs (in this moment i´m using it with my laptop).

 Hint: it might be less than you think and as it delivered when it was new.
I already explained above what's different when connecting an host powered disk to a 'laptop' compared to a primitive SBC. The laptop is powered by something real and contains DC-DC circuitry to provide stable 5V on its USB3 ports even if a device wants to draw up to 900mA. On SBC with el cheapo power bricks there are either 5.xV at the USB3 connector or 900mA but not both at the same time. There is no DC-DC circuitry to get a stable 5V out of a higher input voltage and as such if the input voltage starts to drop the USB Vbus voltage drops even more and USB consumers start to fail and later even the board will freeze when connecting USB peripherals due to their initial peak consumption.

I have one disk connected to usb 3.0, and hub connected to usb 2.0 (with multiple disks on it). Working fine, no crashes

So what's the matter then? I already tried to explain in this issue what's different comparing USB Hi-Speed (called 'usb 2.0') and USB SuperSpeed (called 'usb 3.0'). SuperSpeed uses a totally different concept to transfer data (web search for 'superspeed streams' might be sufficient to get the idea) so once you downgrade to Hi-Speed the issues are gone. I also hinted here to disable streams maybe workarounding the whole issue.

I really hope some board manufacturer stops this sh*t show and comes up with a 12V powered inexpensive board with PCIe attached SATA.

@ThomasKaiser In your experience, what would be a good choice of unpowered usb3 <-> sata adapter that could be used to connect an ssd to our SBCs? I had already found a list of working and non-working implementations of uas per chipset, but I've never seen a list related to adapter with/without power delivery issues...

In your experience, what would be a good choice of unpowered usb3 <-> sata adapter

Ok, it seems really hard to accept the simple basics: If an SBC like Rock64 is connected to a PSU not providing +5.0V (any more) and this PSU is unstable then no matter which host powered USB enclosure you attach to this SBC you will suffer from undervoltage. And yeah, it's undervoltage most of the times and not undercurrent.
No matter which external host powered USB enclosure you take it will suffer from these basic electronics issues once input power is low and/or unstable (often caused by aging or cheap PSUs). Further resistance in the power path (USB cable, PCB inside the USB enclosure) adds to this mess.
The situation with the same enclosure connected to a desktop PC or a laptop is entirely different since there on the USB ports there is a stable 5.xV voltage present no matter how much the external disk enclosure consumes. That's what you get from a large PSU with +200W or the DC-DC circuitry on laptops with step-up converters and everything stabilized by a battery.
Wrt RockPro64 and the situation there I had yesterday a short chat with TL Lim (Pine64 founder): http://irc.pine64.uk/?date=2019-06-21T08:48:00.000Z (switch then to #Rock64 channel in the upper left).
I personally use several host powered JMS567 enclosures and one ASM1153 enclosure without any hassles on my RockPro64 (I bought all the enclosure by searching for the chipset in question and ended up buying all of them from CSL Computer as I found out only later)). Also no issues with a JMS578 and a VIA716 (with the latter I had to throw two USB-C cables away since only the third and very short one didn't trigger USB resets that are usually confused with 'UAS issues'). But my RockPro64 is from the very first batch of developer samples where not even PCIe worked without removing one resistor so this is of no meaning for the production batches.

I don't have a hard time to accept anything related to the PSU, but you mentioned that I should stop looking at the PSU because it could not be the problem. So now I'm totally lost. I have a pine64 provided PSU (and I have tried other PSUs as well), a pine64 RockPro64, a short USB3 cable (I've tried several cables), an enclosure based on a chipset that is the same as the pine64 adapter and an ssd (Samsung) and in the end, this does not work. And I have no clue what could be a way forward (beside using an externally powered enclosure)...

I don't have a hard time to accept anything related to the PSU

But others have -- see @cgacimartin answer above -- and I answered in general since you asked in a 'thread' with a bunch of contributors. There is no 'appropriate' host powered USB disk enclosure for SBC as long as the SBC issues are not resolved. And those issues are

with Rock64 (and all the other SBC that need to be powered with 5V except those Olimex boards with battery support that generate USB Vbus differently) voltage drops along the power path between PSU and disk result in lost connections, USB resets, as a result of this also fs corruption and so on (and if UAS is enabled then this smells like 'UAS is the issue' in the logs while it's not)
With (your) RockPro64 there's obviously unstable 5V on the board's USB3 port which should not happen but obviously does if using an externally powered USB enclosure resolves it and your host powered disk enclosure + USB cable works flawlessly when used at a PC/laptop. How to resolve this? Don't know and that's why I mentioned TL Lim
In addition with both boards it's always possible that contact hassles at the tiny SuperSpeed contacts inside the USB receptacle result in similar symptoms as undervoltage: USB resets, corrupted filesystems and so on

Unrelated to the above you'll almost always run into troubles when using an USB3 hub in between SBC and USB disks and have concurrent disk access for the reasons outlined above (and one more time the hint that disabling streams might resolve the issue). The majority of people complaining here in this issue have been affected by this and not undervoltage like you, @cgacimartin and few others.

Funnily on Raspberry Pi 4 which is on sale since today the 2 USB3 ports are behind a VIA Labs VL805 USB3 host controller (PCIe attached) so most probably the RPi 4 now provides a much much better USB3 experience than majority of other ARM boards.

I've made some more tests during the week end, trying HDDs into my enclosure (out of desperation). And this worked! So my ssd is the problem, somehow it generates spikes of power consumption (I still don't understand exactly under which circumstances) that go beyond what even an HDD would draw. So I've ordered another ssd (making sure in the specs that it won't require too much power), hoping for the best!

 With this SSD majority of 5V powered SBC I tested with simply brown-out when I connected the SSD regardless of the enclosure. Only when providing additional power to my JMS567 enclosures with another 5V power brick the SSD wasn't a problem any more :)
As such good luck!

Mine is a Samsung Evo 860. Only with the Rock64 it goves me trouble.

I have a RPi 4 lying on my desk for 24 hours now. The 'bad' news at least for Rock64 owners: RPi 4 USB3 storage performance is slightly better than Rock64.
The 'good' news: utilizing more than one USB3 disk at the same time is the same sh*t show as everywhere else in SBC land: https://www.cnx-software.com/2019/06/24/raspberry-pi-4-benchmarks-mini-review/#comment-564128

OK, so I have an interesting update:
First, I found out that Dietpi is no longer using ayufans kernel, but Armbian (Debian).
Second, it turns out that my problem wasn't with the USB3 at all!
My problem was the NIC that was getting "stuck", and therfore I had no access to the device.
After following the suggestion here:
https://forum.armbian.com/topic/9812-rock64-random-nic-failure/
Its been working for about a week without problems!
USB3 is being used with UAS (directly connected).
I hope this helps other somehow.

@meetyg You scared me with your "Mine is an EVO 860 1Tb" since this is exactly the model I've ordered... My only hope was that the actual hardware would change during the commercial lifetime of such a product. I've received mine a few days ago, and after many tries (ie hammering on the disk to make it consume as much power as possible), everything works without any trouble. Copying large amounts of data (so its internal cache can not contain everything and it has to really write the data it has received) while reading some other data on the disk works without any problems. The funny thing is, on the "specifications" page that I've looked at before buying, it says that it consumes max. 4 W (under 5 Volts, that means 800mA). When I received the ssd, on its back it says "max current: 1.2A" (which would be 4 W under 3.3V).

People in this thread seem to be discussing a wide range of USB issues in this, but I'd like to talk about the starting point: USB hard disks connected via powered USB3 hub.
I'm also running into this USB3 (xhci, dwc3?) bug. I first encountered it about a year ago when I purchased the RockPro64 and attached multiple disks to a powered USB hub. It only occurred when transferring between two of them. After a bit of fiddling I gave up on this and favored the stability of USB2 for the hub. [single disk on USB3 works perfectly fine, zero usb related crashes for a year]
This is the kernel error encountered when running multiple disks over a USB hub, which seems to be the same as OP:
[  361.385724] xhci-hcd xhci-hcd.4.auto: xHCI host not responding to stop endpoint command.                        [  361.399307] xhci-hcd xhci-hcd.4.auto: xHCI host controller not responding, assume dead [  361.399317] xhci-hcd xhci-hcd.4.auto: xHCI host not responding to stop endpoint command.                         [  361.399456] xhci-hcd xhci-hcd.4.auto: HC died; cleaning up
It's kinda frustrating that this doesn't seem to have been fixed after a year, so I started fiddling with it again to try to get it to work. Troubleshooting steps taken:

Installed newest kernel: linux-5.3-rc4
tried different PSUs for the RockPro64 (12V/3A and 12V/5A)
tried two different powered USB3 hubs
tried different types of bitmasks for xhci_hcd.quirks kernel boot parameter. This involved lots and lots of guesswork and reboots. No luck there. I was hoping something like XHCI_LIMIT_ENDPOINT_INTERVAL_7 would help, but I didn't see a difference.

Researching this issue also points towards threads in other forums related to DMA, but I'm not sure whether that could be the culprit here (https://e2e.ti.com/support/processors/f/791/t/550846?USB-3-port-file-copy-leads-to-kernel-Panic-with-Processor-SDK#).
Is there any hope for this to be fixed in the foreseeable. future (maybe upstream?) or do we have just broken hardware here?

So Rock64 should just say "the system doesn't support usb3 hubs"

dito. I feel mildly duped. Any advice for a different board? How's the Raspi 4 in regards to USB3?

I would assume all those ARM SoCs rely on the same USB3 IP block (Synopsys DesignWare) and suffer from the same limitation (limited endpoint issue). Maybe a software fix is possible.

Thanks for posting this. This patch seems to be from 2015 though. It doesn't seem to have been adapted to mainline (xhc_late_csc doesn't exist in my sources), but maybe I can apply it to the recent kernel somehow (gotta change the quirk bit at the very least). Are we even sure this addresses the same issue though?

Seems this issue is also affecting the Roshambo SNES case with its SSD cartridge:
Aug 20 15:20:50 Debian-Desktop kernel: [ 4182.615113] sd 0:0:0:0: [sda] tag#3 data cmplt err -71 uas-tag 4 inflight: CMD
Aug 20 15:20:50 Debian-Desktop kernel: [ 4182.615133] sd 0:0:0:0: [sda] tag#3 CDB: opcode=0x2a 2a 00 0d f9 44 00 00 04 00 00

Everytime this happens, the SSD resets:
Aug 20 15:21:20 Debian-Desktop kernel: [ 4212.863393] sd 0:0:0:0: tag#0 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD
Aug 20 15:21:20 Debian-Desktop kernel: [ 4212.863435] sd 0:0:0:0: tag#0 CDB: opcode=0x0 00 00 00 00 00 00
Aug 20 15:21:20 Debian-Desktop kernel: [ 4212.863478] sd 0:0:0:0: [sda] tag#3 uas_eh_abort_handler 0 uas-tag 4 inflight: CMD
Aug 20 15:21:20 Debian-Desktop kernel: [ 4212.863506] sd 0:0:0:0: [sda] tag#3 CDB: opcode=0x2a 2a 00 0d f9 44 00 00 04 00 00
Aug 20 15:21:20 Debian-Desktop kernel: [ 4212.863585] scsi host0: uas_eh_bus_reset_handler start
Aug 20 15:21:20 Debian-Desktop kernel: [ 4212.863655] xhci-hcd xhci-hcd.8.auto: ERROR Transfer event for disabled endpoint or incorrect stream ring
Aug 20 15:21:20 Debian-Desktop kernel: [ 4212.863683] xhci-hcd xhci-hcd.8.auto: @00000000f157bad0 00000000 00000000 1b000000 01058000
Aug 20 15:21:20 Debian-Desktop kernel: [ 4212.863805] xhci-hcd xhci-hcd.8.auto: ERROR Transfer event for disabled endpoint or incorrect stream ring
Aug 20 15:21:20 Debian-Desktop kernel: [ 4212.863833] xhci-hcd xhci-hcd.8.auto: @00000000f157baf0 00000000 00000000 1b000000 01058000
Aug 20 15:21:20 Debian-Desktop kernel: [ 4213.081030] usb 5-1: reset SuperSpeed USB device number 2 using xhci-hcd
Aug 20 15:21:20 Debian-Desktop kernel: [ 4213.094790] scsi host0: uas_eh_bus_reset_handler success
Aug 20 15:21:21 Debian-Desktop kernel: [ 4213.362698] sd 0:0:0:0: [sda] tag#1 data cmplt err -71 uas-tag 2 inflight: CMD
Aug 20 15:21:21 Debian-Desktop kernel: [ 4213.362746] sd 0:0:0:0: [sda] tag#1 CDB: opcode=0x2a 2a 00 0d f9 44 00 00 04 00 00
Aug 20 15:21:50 Debian-Desktop systemd-udevd[231]: seq 2906 '/devices/platform/usb1/fe900000.dwc3/xhci-hcd.8.auto/usb5/5-1/5-1:1.0/host0/target0:0:0/0:0:0:0/block/sda' is taking a long time
Aug 20 15:21:51 Debian-Desktop kernel: [ 4243.839409] sd 0:0:0:0: [sda] tag#0 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD IN
Aug 20 15:21:51 Debian-Desktop kernel: [ 4243.839453] sd 0:0:0:0: [sda] tag#0 CDB: opcode=0x12 12 00 00 00 24 00
Aug 20 15:21:51 Debian-Desktop kernel: [ 4243.839523] xhci-hcd xhci-hcd.8.auto: ERROR Transfer event for disabled endpoint or incorrect stream ring
Aug 20 15:21:51 Debian-Desktop kernel: [ 4243.839551] xhci-hcd xhci-hcd.8.auto: @00000000f157bcc0 00000000 00000000 1b000000 01078000
Aug 20 15:21:51 Debian-Desktop kernel: [ 4243.839647] sd 0:0:0:0: [sda] tag#1 uas_eh_abort_handler 0 uas-tag 2 inflight: CMD
Aug 20 15:21:51 Debian-Desktop kernel: [ 4243.839675] sd 0:0:0:0: [sda] tag#1 CDB: opcode=0x2a 2a 00 0d f9 44 00 00 04 00 00
Aug 20 15:21:51 Debian-Desktop kernel: [ 4243.839757] scsi host0: uas_eh_bus_reset_handler start
Aug 20 15:21:51 Debian-Desktop kernel: [ 4243.839825] xhci-hcd xhci-hcd.8.auto: ERROR Transfer event for disabled endpoint or incorrect stream ring
Aug 20 15:21:51 Debian-Desktop kernel: [ 4243.839853] xhci-hcd xhci-hcd.8.auto: @00000000f157bce0 00000000 00000000 1b000000 01058000
Aug 20 15:21:51 Debian-Desktop kernel: [ 4243.839968] xhci-hcd xhci-hcd.8.auto: ERROR Transfer event for disabled endpoint or incorrect stream ring
Aug 20 15:21:51 Debian-Desktop kernel: [ 4243.839996] xhci-hcd xhci-hcd.8.auto: @00000000f157bd00 00000000 00000000 1b000000 01058000
Aug 20 15:21:51 Debian-Desktop kernel: [ 4244.057499] usb 5-1: reset SuperSpeed USB device number 2 using xhci-hcd
Aug 20 15:21:51 Debian-Desktop kernel: [ 4244.071358] scsi host0: uas_eh_bus_reset_handler success
Aug 20 15:21:52 Debian-Desktop kernel: [ 4244.338781] sd 0:0:0:0: [sda] tag#0 data cmplt err -71 uas-tag 1 inflight: CMD
Aug 20 15:21:52 Debian-Desktop kernel: [ 4244.338823] sd 0:0:0:0: [sda] tag#0 CDB: opcode=0x2a 2a 00 0d f9 44 00 00 04 00 00
Aug 20 15:22:22 Debian-Desktop kernel: [ 4274.879486] sd 0:0:0:0: tag#1 uas_eh_abort_handler 0 uas-tag 2 inflight: CMD
Aug 20 15:22:22 Debian-Desktop kernel: [ 4274.879519] sd 0:0:0:0: tag#1 CDB: opcode=0x0 00 00 00 00 00 00
Aug 20 15:22:22 Debian-Desktop kernel: [ 4274.879555] sd 0:0:0:0: [sda] tag#0 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD
Aug 20 15:22:22 Debian-Desktop kernel: [ 4274.879577] sd 0:0:0:0: [sda] tag#0 CDB: opcode=0x2a 2a 00 0d f9 44 00 00 04 00 00
Aug 20 15:22:22 Debian-Desktop kernel: [ 4274.879867] scsi host0: uas_eh_bus_reset_handler start
Aug 20 15:22:22 Debian-Desktop kernel: [ 4274.879964] xhci-hcd xhci-hcd.8.auto: ERROR Transfer event for disabled endpoint or incorrect stream ring
Aug 20 15:22:22 Debian-Desktop kernel: [ 4274.879992] xhci-hcd xhci-hcd.8.auto: @00000000f157beb0 00000000 00000000 1b000000 01058000
Aug 20 15:22:22 Debian-Desktop kernel: [ 4274.880140] xhci-hcd xhci-hcd.8.auto: ERROR Transfer event for disabled endpoint or incorrect stream ring
Aug 20 15:22:22 Debian-Desktop kernel: [ 4274.880170] xhci-hcd xhci-hcd.8.auto: @00000000f157bed0 00000000 00000000 1b000000 01058000
Aug 20 15:22:22 Debian-Desktop kernel: [ 4275.099763] usb 5-1: reset SuperSpeed USB device number 2 using xhci-hcd
Aug 20 15:22:22 Debian-Desktop kernel: [ 4275.112483] scsi host0: uas_eh_bus_reset_handler success
Aug 20 15:22:23 Debian-Desktop kernel: [ 4275.471621]  sda: sda1
Aug 20 15:22:23 Debian-Desktop kernel: [ 4275.517426]  sda: sda1
Aug 20 15:22:23 Debian-Desktop kernel: [ 4275.983304]  sda: sda1
Aug 20 15:22:24 Debian-Desktop kernel: [ 4276.848566] sd 0:0:0:0: [sda] tag#1 data cmplt err -71 uas-tag 2 inflight: CMD
Aug 20 15:22:24 Debian-Desktop kernel: [ 4276.848594] sd 0:0:0:0: [sda] tag#1 CDB: opcode=0x2a 2a 00 00 00 08 78 00 04 00 00
Aug 20 15:22:24 Debian-Desktop kernel: [ 4276.849259] xhci-hcd xhci-hcd.8.auto: ERROR Transfer event for disabled endpoint or incorrect stream ring
Aug 20 15:22:24 Debian-Desktop kernel: [ 4276.849275] xhci-hcd xhci-hcd.8.auto: @00000000f157b9a0 00000000 00000000 0a000000 01088000

Can't even format the SSD using Gparted.
But it works fine on my laptop, so it's not a hardware issue.
Moreover, on this distro I can't even disable UAS (tried modprobe.d/blacklist.conf, and using quirks), but none of them worked:
root@Debian-Desktop:~# lsusb
Bus 005 Device 002: ID 152d:0579 JMicron Technology Corp. / JMicron USA Technology Corp.
Bus 005 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
...
root@Debian-Desktop:~# lsusb -t
...
/:  Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
    |__ Port 1: Dev 2, If 0, Class=Mass Storage, **Driver=uas**, 5000M
...
root@Debian-Desktop:~#

@Maxpako The undervoltage does not only happen with a power supply that would be too weak, it can also happen between the voltage regulator of the SBC (ie your RockPro64) and the ssd in its enclosure (ie through the usb cable + usb to sata adapter). This could come from a usb cable that is too long and/or too thin or it could simply be that your ssd produces power spikes that the SBC's voltage regulator can not digest (thus letting the voltage drop). In my case, everything worked fine on my laptop but every now and then when connected to my RockPro64, my ssd would get corrupt from such errors (it was a Samsung 840pro). After replacing it by another ssd (samsung 860evo) and hoping for the best, everything works (but it seems that even the voltage and power draw specifications change during the lifetime of a specific product number: earlier 840pro did produce such problems while mine works fine). I wanted to measure the voltage in my enclosure while it runs, but you would need very thin connectors and most probably a scope that can record the voltage trace...

on this distro I can't even disable UAS

Still people believe in driver issues when dealing with hardware problems...
If you want to UAS blacklist your USB-to-SATA adapter you could follow this route (the important part being initramfs-update): https://github.com/ayufan-rock64/linux-build/blob/48453709b401b9f8f602b2eeef139e761213a572/package/root/usr/local/sbin/rock64_fix_performance.sh

With UAS blacklisted, and updated initramfs:
root@rockpro64:~# tail -n4 /etc/modprobe.d/blacklist.conf
###Fix
blacklist uas

options usb-storage quicks=0x152d:0x0579:u
root@rockpro64:~#

syslog:
Aug 20 15:36:42 rockpro64 kernel: [  389.004141] usb 4-1: new SuperSpeed USB device number 4 using xhci-hcd
Aug 20 15:36:42 rockpro64 kernel: [  389.022997] usb 4-1: New USB device found, idVendor=152d, idProduct=0579
Aug 20 15:36:42 rockpro64 kernel: [  389.023031] usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Aug 20 15:36:42 rockpro64 kernel: [  389.023053] usb 4-1: Product: External
Aug 20 15:36:42 rockpro64 kernel: [  389.023074] usb 4-1: Manufacturer: JMicron
Aug 20 15:36:42 rockpro64 kernel: [  389.023094] usb 4-1: SerialNumber: DD56419883931
Aug 20 15:36:42 rockpro64 mtp-probe: checking bus 4, device 4: "/sys/devices/platform/usb1/fe900000.dwc3/xhci-hcd.9.auto/usb4/4-1"
Aug 20 15:36:42 rockpro64 mtp-probe: bus: 4, device: 4 was not an MTP device

lsusb and lsusb -t:
Bus 004 Device 004: ID 152d:0579 JMicron Technology Corp. / JMicron USA Technology Corp.
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub

/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
    |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=, 5000M

Blank driver XD
I'll need to think about the voltage drop since many distributions show the same issues :\

I'm measuring 5.149-5.150 on the USB 3.0 power input (red and black wires) from the Roshambo case, and for me, it looks stable... but still doing the same thing.
What else would you suggest to check?

By the way, I don't think it's a hardware issue, since I've tested Android 7.1 over emmc, and the SSD over usb 3.0 works like a charm: 137,6Mbps transferring 2,34 GB file in 2 minutes and 19 seconds.

May I add a datapoint to this thread (I think it's one the most referenced regarding this issue).
I experienced similar problems (and a lot of frustration), but I eventually managed to get a stable system that does not fail anymore under heavy hard drive I/O.
How it started:
A powered USB3.0 hub was connected to my Rock64. Two USB3.0 disks were connected to the hub:

Disk1: 2TB Seagate 2.5" external drive (powered from USB).
Disk2: 4TB WD Red in a recycled Seagate enclosure (self-powered 12V 5A).

Both Seagate enclosures were UAS blacklisted since the beginning because I had problems reading SMART values.
Initially, only Disk1 was plugged and everything was fine: Torrents downloads/uploads, network shares (large files transfer) used in both directions.
I then decided to use the rock64 as backup server with urBackup. Disk2 was supposed to collect backups from all computers to a BTRFS partition.
Once done with configuration, I start initial backup for the main computer (~2.2TB). I never managed to get this one finished. It would randomly fail after 10 to 200GB.
I thought BTRFS would be the problem here (maybe too demanding on processor), so I tried disabling compression, or using ext4 filesytem... Took me a week and that would still not work.
The failure would likely happen when I started large torrent downloads (on the other disk), or concurrent file transfers. When it failed, it was just rebooting and I could not find any relevant error messages in logs/dmesg... Not even usb3.0 stream/ring -related errors.
I then started reading messages here and I tried all sort of combinations: hubs, no hubs, powered and non-powered ones, only Disk2 connected directly to USB3.0 port, various 5V and 12V adapters for hubs and Disk2...
I could never manage to go beyond 300GB of backup... VERY frustrating !!!
I started suspecting the Seagate enclosure. It is old and a lot of people complain about it regarding UAS/SMART compatibility.
Some people were having success with externally powered HDD docks, so I ordered this: ORICO 6638US3-C-V1
Nice piece of hardware, but no UAS support at all (does not really matter) and it would still fail under heavy loads (same symptoms). Could not find datasheet so I don't know what USB3.0 to SATA chip is used there...
At this point I was about to give up, sell everything, and try Raspberry Pi4 which has supposedly a better USB3.0 implementation... Or a x86 miniPC, just got tired of these problems with arm SBC :)
Before taking my decision, I ordered these docks from Amazon:

Salcar Station d'accueil USB 3.0 SATA...
Chip: ASM1156
FIDECO Hard Drive Docking Station, USB 3.0 to SATA...
Chip: JMS561U

The SALCAR would work on my linux computer but disks would not even appear on Rock64... Did not investigate much, at this point it just became too frustrating.
And finally... The FIDECO (JMS561U) just works PERFECTLY !!!
No need to blacklist whatever, UAS works, backups work and I never got a reboot since I plugged it in...
In summary, it seems that there is indeed a problem with USB3.0 on the Rock64 with current linux version (hardware or software I don't want to know). Some adapter chips are better supported than others and I recommend going with JMS561U as it works perfectly for me.
ORICO and UGREEN seem to build similar docks with JMS561U chip, let us know if that works for you.
 Not sure about the chip used in here but they reliably fail on Rock64, they have trouble with UAS and SMART in general, and they silently change sector size. That is added trouble when you want to use your disk in another place.
Hope that helps somebody.

Hi @everyone, Hi @ayufan ,
there appears to be a (potential) fix for this issue. I first stumbled upon it in this thread:
https://community.nxp.com/thread/511218 (0001-usb-dwc3-disable-park-mode.patch)
There's also discussion concerning this mysterious park mode on a kernel mailing list:
https://lkml.org/lkml/2019/10/14/496
In any case, applying the 0001-usb-dwc3-disable-park-mode.patch to linux-5.5-rc5 seems to have entirely fixed the issues for me. In the first control test the xhci controller died after a few seconds and currently it is transferring data via a usb3 and a hub for >15 minutes.
I will report back concerning long term stability. At this point I recommend everyone experiencing usb3 instability to give it a shot.
Maybe this can also be incorporated into the linux-mainline-kernel repo for rockpro64?
0001-usb-dwc3-disable-park-mode.patch.zip

I also into the dreaded "xHCI host not responding to stop endpoint command" problem.
RockPi4a, debian 4.4.154-100 installation from Radxa's web page. Happens immediately when i try to rsync from one USB3 connected disk to a second one.
I am fairly certain, that this is not a power issue, because i first tried mit setup with x86 motherboard: 5TB 2.5" USB3 HDD via Amazon basic USB3 hubs, and it was unstable. I measured voltages and saw voltage level problems under load. So now, power setup is:
PC 400W power supply for everything.
RockPi4a powered from one 5V cable of the power supply.
4 USB3 hubs (and hence all HDDs) powered from a different 12v line of the power supply via an adjustable 20A DC/DC converter set on output to 5.2v. One USB port connects to a control voltmeter display. 5.2v to compensate for the voltage loss in the USB hubs. Supported voltage range for USB equipmet seems to be +- 0.25v at least, but when i fed 5.0v to the hubs, i did get problems during disk startups (from idle), and saw voltage drop below 4.75. Now the voltage on my voltmeter (behind usb output port) is 4.94 when e.g.: 9 disks are active/reading (stable aggregate 300 MByte aggregate read rate across disks), and close to 5v when they're idle.
As soon as i just copy (rsync) from one disk to another, i get the dreaded problem within a minute and loose all disks.
The dreaded problem does not happen when i use x86 motherboard or RPI4. Just that RPI4 is terribly slow, and x86 of course too large for my target physical box.
Did not have success getting a 5.x kernel work on rockpi4a yet, so limited to 4.4 kernel provided by radxa. Still hoping, the problem would be fixed sometime in some kernel sigh

v0.10.0 just shipped with the 5.6.0-1123-ayufan-g50979db7cb28 mainline kernel. Anyone brave enough to try? 🙃

Throwing my two cents in here: I was having this issue as well.  At first I was using a Rock64, but then I switched to an Orange Pi 4 (which uses an RK3399) and had the same issue there.  I was able to apply the patch linked by @Deathcow to kernel 5.4.49 -- once I did, I ran near-constant file transfers all weekend long and didn't have this issue come up once.

So... has this patch made it to any of the ayufan kernels yet?

So... has this patch made it to any of the ayufan kernels yet?

It appears to have been added in mainline in v5.7: https://github.com/torvalds/linux/commit/7ba6b09fda5e0cb741ee56f3264665e0edc64822

So... has this patch made it to any of the ayufan kernels yet?

It appears to have been added in mainline in v5.7: https://github.com/torvalds/linux/commit/7ba6b09fda5e0cb741ee56f3264665e0edc64822

You can try the latest 5.10:
https://github.com/ayufan-rock64/linux-mainline-kernel/releases
On Mon, Jan 11, 2021 at 12:22 PM Marek Benc<EMAIL_ADDRESS>wrote:

So... has this patch made it to any of the ayufan kernels yet?
It appears to have been added in mainline in v5.7: torvalds/linux@7ba6b09
https://github.com/torvalds/linux/commit/7ba6b09fda5e0cb741ee56f3264665e0edc64822
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ayufan-rock64/linux-build/issues/112#issuecomment-757887395,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AASOSQLAQSITFRVSZP5D77TSZLNNVANCNFSM4ESNUMYQ
.

You can try the latest 5.10:
https://github.com/ayufan-rock64/linux-mainline-kernel/releases
On Mon, Jan 11, 2021 at 12:22 PM Marek Benc<EMAIL_ADDRESS>wrote:

So... has this patch made it to any of the ayufan kernels yet?
It appears to have been added in mainline in v5.7: torvalds/linux@7ba6b09
https://github.com/torvalds/linux/commit/7ba6b09fda5e0cb741ee56f3264665e0edc64822
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ayufan-rock64/linux-build/issues/112#issuecomment-757887395,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AASOSQLAQSITFRVSZP5D77TSZLNNVANCNFSM4ESNUMYQ
.

@dusxmt @ayufan  I have been following but I have not been using my Rock64 due to this issue. So I might be a bit behind on the progress made here.
If the kernel I'm using contains the needed fixes, do I need to add anything to kernel command boot line or any other configurations to make sure the fix is enabled?

@dusxmt @ayufan  I have been following but I have not been using my Rock64 due to this issue. So I might be a bit behind on the progress made here.
If the kernel I'm using contains the needed fixes, do I need to add anything to kernel command boot line or any other configurations to make sure the fix is enabled?

@dusxmt @ayufan I have been following but I have not been using my Rock64 due to this issue. So I might be a bit behind on the progress made here.
If the kernel I'm using contains the needed fixes, do I need to add anything to kernel command boot line or any other configurations to make sure the fix is enabled?

I don't think so, the fix checks the hardware revision of the dwc3 chip and conditionally applies the fix.  What you might need from @ayufan are the device tree patches of his kernel, to allow the kernel to see the USB3 chip.  (Simply installing his kernel build should do)
I wonder what the status with upstreaming the device tree changes is.

@dusxmt @ayufan I have been following but I have not been using my Rock64 due to this issue. So I might be a bit behind on the progress made here.
If the kernel I'm using contains the needed fixes, do I need to add anything to kernel command boot line or any other configurations to make sure the fix is enabled?

I don't think so, the fix checks the hardware revision of the dwc3 chip and conditionally applies the fix.  What you might need from @ayufan are the device tree patches of his kernel, to allow the kernel to see the USB3 chip.  (Simply installing his kernel build should do)
I wonder what the status with upstreaming the device tree changes is.

(I can't confirm this though, because I was merely doing before-i-buy research for this board, I don't have the hardware just yet)

(I can't confirm this though, because I was merely doing before-i-buy research for this board, I don't have the hardware just yet)

Does anyone have any new updates on this?  Will the required changes make it to a upstream kernel?   And in the meantime @ayufan's latest kernel has all the required fixes and they work?

@ShapeShifter499 It does appear to be in the USB Subsystem's tree: https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git/commit/?h=testing/next&id=1080ed2a6cc53a07afdb1cd3f3968e808b714bbb - so it's only a matter of time before it's in mainline.

So... has this patch made it to any of the ayufan kernels yet?

It appears to have been added in mainline in v5.7: https://github.com/torvalds/linux/commit/7ba6b09fda5e0cb741ee56f3264665e0edc64822

I'll dig up my old rock64 to see if it works fine on a upstream Arch Linux 5.11 kernel

So... has this patch made it to any of the ayufan kernels yet?

It appears to have been added in mainline in v5.7: torvalds/linux@7ba6b09

I'll dig up my old rock64 to see if it works fine on a upstream Arch Linux 5.11 kernel

Keep in mind, Upstream 5.11 might not have the device tree patch that I linked.

@ShapeShifter499 It does appear to be in the USB Subsystem's tree: https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git/commit/?h=testing/next&id=1080ed2a6cc53a07afdb1cd3f3968e808b714bbb - so it's only a matter of time before it's in mainline.

Wait so the 5.7 kernel patch linked to earlier isn't all that's required then?

@ShapeShifter499 It does appear to be in the USB Subsystem's tree: https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git/commit/?h=testing/next&id=1080ed2a6cc53a07afdb1cd3f3968e808b714bbb - so it's only a matter of time before it's in mainline.

Wait so the 5.7 kernel patch linked to earlier isn't all that's required then?

That patch fixes the hang, the device tree patch makes the USB3 controller visible to the system in the first place.

@ShapeShifter499 It does appear to be in the USB Subsystem's tree: https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git/commit/?h=testing/next&id=1080ed2a6cc53a07afdb1cd3f3968e808b714bbb - so it's only a matter of time before it's in mainline.

Wait so the 5.7 kernel patch linked to earlier isn't all that's required then?

That patch fixes the hangup problem, the device tree patch makes the USB3 controller visible to the system in the first place.

I see, so either wait for mainline, patch a personal build, or use ayufan's kernel.
But basically the issue is known and there is a fix now.
Just making sure because I don't want to spend the time only to be disappointed again.
I originally brought my device in hopes of making a low powered, small NAS but that was nailed by the issues discussed here. I might have other plans I could use my board for but I don't want to worry about the USB failing on me if I decide to use it like it has before.


OIDC: Configurable audience

See #12465.
This allows instances like TestPyPI to configure their own OIDC audience.

I've set OIDC_AUDIENCE to pypi and testpypi respectively.


Multiple Triggered Webjob instances running during FileSystem ReadOnly

The lock obj used by Triggered Webjob is forgiving and allowed multiple Job instances to acquire the log.   The fix is to be more restricted similar to Continuous webjobs singleton.

Hi
If the problem persists and is related to running it on Azure App Service, please open a support incident in Azure:
https://learn.microsoft.com/en-us/azure/azure-portal/supportability/how-to-create-azure-support-request
This way we can better track and assist you on this case
Thanks,
Joaquin Vano
Azure App Service


Error when calling feeding switch

First of all, thanks for your work with this integration. It has worked great for a couple of years.
Both my feeders stopped working 3 days ago. HA states them as "Offline" for the entity named sensor.feeder_cid_state.

I get this error message in the logs:
2023-08-07 20:11:46.055 ERROR (MainThread) [custom_components.petkit] Petkit feeding failed: {'error': {'code': 1504, 'msg': '喂食器已离线，不能修改喂食计划'}}

The feeder is offline, the feeding schedule cannot be modified
(Translated from 喂食器已离线，不能修改喂食计划)

I can use the Petkit mobile app to trigger a feed, so they should be online.

im having the same issue, worked great for years, a few days ago stopped triggerring

Exactly the same behavior for me.

API has changed. Don't want to promote my repo here, but just want to offer some insight to those having issues.

I've switched over to Robert's integration, and everything is back working flawlessly

same issue with this integration as well for some weeks. and i thought it was because i had disconnected the feeder for some weeks when on vacation... I switched to Robert's integration too and it works fine


Layout of landing page doesn't show network information by default

This screenshots are taken on  c4296586f57f34278927f699f590cafbf1802ad7
When I land on my home page, i can't see things like the tor address, the block height, fee rate etc on the home page. On our desktop app, we always display those on the bottom of the page. We might want to move these to the top so a user sees these when they open up the app?

This has been addressed with the addition of the header nav.


OP-1775 0.7.0 packaging updates.

Removed wasm build in Makefile.  Other changes were already done.
Added defaulting to new networking.

bors r+

bors r+


[--with-license-file] Fails to extract license file on Black 22.10.0

For new versions of black, the license file has been moved to licenses folder. When using --with-license-file, the result is UNKNOWN

@roniemartinez Thanks for the report.
We have released a version that fixes this problem. Could you try it?
pip install -U pip-licenses==3.5.5

@raimon49 It is working fine now. Thank you.


Update Philips_RWL020.md

Swapped US-EU images and links

thanks

Hi, no problem, thanks to you for maintaining all of this.
I was just looking at the pages again and I still don't think they're quite right, unless it's my browser cache? The RWL020 should have the buttons labelled "ON" and "OFF", while the European version (RWL021) has the buttons labelled "I" and "O". I thought I swapped the images, did I get it wrong?


[eloquent] Stateless writer delivery improvement [7880]

With this PR, the StatelessWriter synchronous delivery order is set to:

Intra-process.
Inter-process, but only if there are remote readers or fixed locators.

This posses a performance improvement for the intra-process case, since the RTPSMessageGroup construction only happens when it's needed (remote readers or fixed locators).
Note: this has been backported from #946

Build status:

Linux
Mac
Windows

Build status:

Linux
Mac
Windows

@mjcarroll @dirk-thomas Would someone please run a ROS2 CI build for this?

From https://gist.githubusercontent.com/mjcarroll/f78accb72c78bbecf385fc98d92a4c8c/raw/b62e1351bbb4675050647eb158316c16abb5b71d/ros2.repos (ros2/ros2@eloquent + this branch)

Linux
Linux-aarch64
macOS
Windows

@mjcarroll All failures seem not to involve rmw_fastrtps_cpp, just rmw_cyclonedds_cpp and WStrings. Do you agree for us to merge this?


PR Template is missing!

Summary
I have noticed that the PR template iss missing for https://github.com/appsmithorg/appsmith-docs .
Motivation
This should be completed as early as possible because there are numerous PR's made everyday but in an irregular way!

@Nikhil-Nandagopal @mohanarpit I hope this is a good issue for Hacktoberfest and I would like to work on it!

Hey @Hard-Coder05! Welcome to Appsmith 🎉 Love your enthusiasm to improve our repo during Hacktoberfest. Unfortunately this issue is already raised and someone is already working on it. I welcome you to go through our Good first issues or create a new one by testing the application at app.appsmith.com
Looking forward to your contributions to our repo 😄

Duplicate of #826


CORS management

Should enable CORS to allow request from other domains.

Can you say a bit more about this? What other domains need to call in?

So basically cross origin resource sharing (CORS) is to restrict webpages from making requests to a different domain. For e.g frontend is hosted on xyz.com while the paymaster is hosted on abc.com (so they are in different domain and the server wouldn't accept the request). Added CORS management on the paymaster server to allow requests from other domains.

Oh I see, I must have been tired and thought it was in the frontend!
Let's figure out the pnpm settings than merge.


Helper: Language Handling

We need easy ways to pass languages to things like labels and metadata
Add some validation, this may require changing the schema:
https://github.com/IIIF/presentation-validator/blob/183a373d89bc203f2b77b94fa43c1f890792a7ef/schema/iiif_3_0.json#L15

Relates to #23

Covered by Rob's auto lang configs.


Colour coding accessibility

UPDATE: Pop up weren't working on my phone, the details are in the popup, this still requires me to ckick on many locations as i can't tell from a high-level glance.  My colour vision is not as bad as many others so i could see it being more issue for them.
I love the idea of this but it's not useful for me because it's using colour scale of green to red which is the most common colour vision deficiency.  As a woman its rare to be colour blind, but for the male population your map key on wait times is useless for about 1 in 10.  In my case 5 minutes looks the same as 25 mins and 45 mins looks the same as 60 plus.  No matter what you're coding you should always include a label or pattern option for accessibly. Great concert though and would be wonderful even outside of the current situation.

Hi, you are absolutely right.
Making the page accessible is one of the priorities I set myself at the beginning of the project. The choice of colors was linked to the common use of traffic lights, but it can always be improved.
Unfortunately / Fortunately, due to the rapid expansion that this project has had, I have not had the way to carry on those features.
As soon as I can stabilize the traffic on the server and optimize the speed and accuracy of the information, I will focus on UI / UX and accessibility.
Unfortunately I had already received this feedback a few days ago, I am sorry I cannot be of immediate help.
I am working hard on this project and any help, even your feedback, is well appreciated!
Thanks for taking the time to write here.

I will look into coming up with a more accessible colour palette (as well as improving other accessibility needs) as soon as I can!


Site bug download not working

I don't know if this is the right place to report this bug, but I noticed today when you download, and a wordpress error in json
http://prntscr.com/ez65gw
Uncaught SyntaxError: Unexpected token  http://blog.brackets.io/feed/json?callback=jQuery211032960339032121344_1492787729067&_=1492787729068

This bug is confirmed for me, because I downloaded, checked dev tools and the error did pop up.

Thanks for reporting, I reposted this to https://github.com/adobe/brackets.io/issues/196


Influxdb get historical alerts

Hello all,
I have some alerts configured and the output to InfluxDBout. Then I have first point when the the alert is active, and other point if the alert is inactive. Thus I have 2 points with the alert is inactive and 1 point if is active.
But I can't find a query to get all the alerts for historian purposes with the last status with it's time.
Thank you

@resquej thanks for the issue. I think you should be able to use the LAST function to get that information, but without additional information about your schema and influxdb version, i can't give much specific guidance.


fix bugs related to messages

add contactSearch for clickToSMS;
fix active call color;
fix message scroll;
fix format phoneNumber as entityName

Coverage increased (+0.09%) to 1.064% when pulling 66d721d78bddae0cde020473de31f21a088786f2 on alvita:rcint-3839 into 5302df028c03e5075d0552c0134a83a18c725d22 on ringcentral:master.

Coverage decreased (-0.0006%) to 0.972% when pulling d624e2e140ffd3e59c6ded7aae9407974f72a9cd on alvita:rcint-3839 into 5302df028c03e5075d0552c0134a83a18c725d22 on ringcentral:master.


updates to Colin Towery profile and SpectralLES profile

It seems like the problem with empty links (empty orange ovals) is only in your fork


Update Artificial-Intelligence.md

added some AI resources to the Artificial-Intelligence.md file. There are various types of resources with links to them.

The format is not correct @nermoo

can you be more specific please? is it file format?

The format is not correct @nermoo

can you be a little bit more specific brother.is it the file format?


Change git clone link

you cannot clone git:// links anymore and this fixes that

Why? litterly everyone uses git clone website.com/user/repo

Why? litterly everyone uses git clone website.com/user/repo

Not a fan of https based clones. They tend to default to username/password and I prefer a key based auth.

I'm thinking after looking at GitHub, this is the preferred way now - git@github.com:iBotPeaches/Apktool.git.

Well that doesn't work:
F:\>git clone git@github.com:iBotPeaches/Apktool.git
Cloning into 'Apktool'...
<EMAIL_ADDRESS>Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

Well that doesn't work:
F:\>git clone git@github.com:iBotPeaches/Apktool.git
Cloning into 'Apktool'...
<EMAIL_ADDRESS>Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

It does require having a ssh keypair setup, which I like as a default as we push GitHub users to do the most secure option as default.

Thanks for bringing this to my attention! I've rewritten that section a bit to help give both ssh/https options.

Thanks!


Can we promisfy js-crawler

Can you help me show, if we can promisfy the below js-crawler.
is there better way to return the response from each crawler state.
function runCrawler(url) {

            var crawler = new Crawler().configure({ignoreRelative: false, depth: 2});
            crawler.crawl({
                url: url,
                success: function (page) {
                    console.log(page.url +' --- ' + page.status);
                   },

                failure: function (page) {
                    console.log(page.url +' --- ' + page.status);

                },
                finished: function (page) {
                    return console.log('COMPLETED***********');
                }
        });

Hi,
Actually crawler is a natural Observable http://reactivex.io/documentation/observable.html, it even has a very similar API, maybe we can think about making it an actual Observable in the releases.
Promise resolves to a single value and crawler produces a series of values the length of which we do not know upfront, so we cannot just return a Promise from the crawl method.
It would be nice to think about some alternative to callback-based API.

I don't think promisifying the crawler API itself really makes sense, based on the fact that it is a many-result not a single-result system... it is better suited to the event listener system in place currently.
What I did to adapt it to my promise-based system, for those interested:
function startCrawl(url) {
  return new Promise(function(resolve) {
    // Create new results object
    let results = {
    };

    crawler.crawl({
      url: url,
      success: function(page) {
        // Do any actions you wanted with page, log to console if you don't care about output order, etc.
        // Add whatever you want to keep to your results object
      },
      failure: function(page) {
        // Do any actions you wanted with page, log to console if you don't care about output order, etc.
        // Add whatever you want to keep to your results object
      },
      finished: function(crawledUrls) {
        // Do any actions you wanted with list of crawled urls, log to console if you want, etc.
        // Add whatever you want to keep to your results object
        resolve(results);
      }
    });
  });
}

Basically, the "results" object would be used to contain anything you want to pass back after the promise resolves, and the promise resolves after the crawling completes. You could add a reject() to handle errors as well, if you want the promise to fail in certain cases.
To use this, it is as simple as any other promise/thenable function:
startCrawl("https://example.com").then(function(results) {
  // Do something with results object here...
});