Error: Communication Failure; SCSI Bus reset due to UAS

Hello alltogether,

I just upgraded my NAS to OMV 3.0.75.1. On that occasion I also switched from Bananian (due to the discontinuation) to Armbian 5.25 (with Kernel 4.9.12). At first glance everything seemed fine, until I plugged in my external USB HDD. (Intenso Memory Center 4TB 3,5" USB 3.0). In the "Storage" Section of the Menu an error pops up: "Communication Failure". When clickung on details, no further information show up.

This is the excerpt of the syslog.

May 14 13:25:31 NAS kernel: [48160.664339] sd 1:0:0:0: [sda] tag#2 uas_eh_abort_handler 0 uas-tag 3 inflight: CMD 
May 14 13:25:31 NAS kernel: [48160.664385] sd 1:0:0:0: [sda] tag#2 CDB: opcode=0x85 85 08 0e 00 00 00 01 00 00 00 00 00 00 00 ec 00
May 14 13:25:31 NAS kernel: [48160.664434] sd 1:0:0:0: [sda] tag#1 uas_eh_abort_handler 0 uas-tag 2 inflight: CMD 
May 14 13:25:31 NAS kernel: [48160.664460] sd 1:0:0:0: [sda] tag#1 CDB: opcode=0x85 85 09 0e 00 00 00 01 00 03 00 05 00 00 00 2f 00
May 14 13:25:31 NAS kernel: [48160.664499] sd 1:0:0:0: [sda] tag#0 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD 
May 14 13:25:31 NAS kernel: [48160.664526] sd 1:0:0:0: [sda] tag#0 CDB: opcode=0x85 85 09 0e 00 00 00 01 00 03 00 04 00 00 00 2f 00
May 14 13:25:31 NAS kernel: [48160.664675] scsi host1: uas_eh_bus_reset_handler start
May 14 13:25:31 NAS kernel: [48160.667949] usb 1-1: cmd cmplt err -2
May 14 13:25:31 NAS kernel: [48160.678710] usb 1-1: cmd cmplt err -2
May 14 13:25:31 NAS kernel: [48160.824333] usb 1-1: reset high-speed USB device number 2 using ehci-platform
May 14 13:25:31 NAS kernel: [48161.016410] scsi host1: uas_eh_bus_reset_handler success
May 14 13:25:31 NAS kernel: [48161.016938] program smartctl is using a deprecated SCSI ioctl, please convert it to SG_IO
May 14 13:25:31 NAS kernel: [48161.240047] program smartctl is using a deprecated SCSI ioctl, please convert it to SG_IO

What I got so far, is that the HDD (or the casing) supports USB attached SCSI (UAS). However, the bus crashes and reset continously. I have read that is is possible to deacticate UAS and fall back to the BOT protocol. At the moment it would be a possible option. However, I don't know how massive the performance loss will be.

So my question to you is, if this is a known problem and if there are other work-arounds. Is this a general problem with the kernel version? I hope you can help me out here

I am aware that this problem is probably not directly related to OMV. Nonetheless I want to give it a try in this forum, since I have witnesses how many smart people are active here.
Soon I want to connect the HDD via Sata and use ext4 as a filesystem (currently ntfs). But due to a backup via USB I would like to have my USB ports working properly.

Thank you in advance and have a great day.

ok what I have found out so far is that there is a problem with the UAS support of certain ASMedia chips.
This is described here:
http://linux-sunxi.org/USB/UAS#Blacklisted_.2F_UAS_disabled
However, normally the UAS support of my ASM1053 chip (which is in my enclosure) is blacklisted since it cannot be distinguished properly with the ASM1051. The ASM1051 have version with broken support. The ASM1053 is supposed to work.

That poses two questions: Why is not working when the ASM1053 is known working with UAS. And why is it not working since it is supposed to be blacklisted (and fall back to BOT) by default.

Where and how can I blacklist / deactivate modules or configure the kernel config (that is a bit too high for me atm).

ok I realized that I do better move this question to the armbian forum since it is purely OS related.

However, I will quickly elaborate on what I have found since I do not like to leave the topic like that and since it might help someone:

disabling works with these steps:
remove the harddrive

rmmod uas
echo "174c:55aa:u" >/sys/module/usb_storage/parameters/quirks

where 174c:55aa stands for the vendor id and product id of the usb-to-sata converter of the enclosure.
seen here: here https://debianforum.de/forum/viewtopic.php?f=13&t=157229

this has to be redone on every reboot (a script might help)

the status can be checked by using

lsusb -t

in the field "driver" it should state "usb-storage" instead of "uas".

However, the UAS mode can be used with the limitation that it will give and error in the OMV GUI since the S.M.A.R.T. functionality produce a constant error and reset the driver. When the module is deactivated and not accessed by the GUI a share can still be used utilizing UAS, resulting in better performance.

What did not work for me:
was to create a file named ignore_uas.conf in the /etc/modprobe.d directory with the content seen below and after that reinitialize the ramdisk.
(as seen here: https://bbs.archlinux.org/viewtopic.php?pid=1428782#p1428782 )

options usb-storage quirks=Vendor_ID:Product_ID:u

I hope that clarified the matter a bit. I will further investigate the matter and continue to search for a solution, but I think here is not the right place.