Getting UAS working on HK 4.9

[crashoverride]

I should mention that it is of no concern to me whether the drive uses UAS or not. When using UAS it works... until it doesn't. The point was to identify that this is not a XU4 issue. Others seeing UAS issues should also understand that the XU4 is not to blame.

Also of importance is that UAS can be disabled without removing USB (module) from the kernel. We just need to add support for "usb-storage.quirks=" to boot.ini. It faces the same issue as other settings though in that its overwritten by updates.

[edit]
TL;DR = if UAS works for you, great. If it doesn't, it will not work on any Linux system currently, and it can be disabled in boot.ini.

[crashoverride]

On a side note:

For those of you expressing concern about the health of my HDD, thank you for the letters, prayers, and flowers showing your support!

I am happy to report that the copy from /dev/zero completed without issue over SATA. The drive has been placed back in its enclosure and is again faithfully in service on my XU4. My HDD and me both look forward to further contributions to the community.

[mad_ady]

Glad to hear that. I will then cancel the order for a 6TB drive I was shipping to your place [emoji14]

[rooted]

On a side note:

For those of you expressing concern about the health of my HDD, thank you for the letters, prayers, and flowers showing your support! [emoji38]

I am happy to report that the copy from /dev/zero completed without issue over SATA. The drive has been placed back in its enclosure and is again faithfully in service on my XU4. My HDD and me both look forward to further contributions to the community.

Thanks for all that testing, I'm wary of UAS now.

What is the performance penalty with it disabled?

[crashoverride]

What is the performance penalty with it disabled?

In my case, there isn't one!

Code: Select all

[    5.550533] usb 4-1.2: new SuperSpeed USB device number 4 using xhci-hcd
[    5.597126] usb 4-1.2: New USB device found, idVendor=0bc2, idProduct=2322
[    5.625245] usb 4-1.2: New USB device strings: Mfr=2, Product=3, SerialNumber=1
[    5.653541] usb 4-1.2: Product: Expansion
[    5.678566] usb 4-1.2: Manufacturer: Seagate
[    5.703706] usb 4-1.2: SerialNumber: [REDACTED]
[    5.710282] usb 3-1.1.2: new low-speed USB device number 5 using xhci-hcd
[    5.764330] usb 4-1.2: UAS is blacklisted for this device, using usb-storage instead
[    5.776433] usb-storage 4-1.2:1.0: USB Mass Storage device detected
[    5.787555] usb-storage 4-1.2:1.0: Quirks match for vid 0bc2 pid 2322: 800000
[    5.799280] scsi host0: usb-storage 4-1.2:1.0


Code: Select all

$ dd if=/dev/zero of=nothing bs=4M status=progress
3925868544 bytes (3.9 GB, 3.7 GiB) copied, 30.0232 s, 131 MB/s^C
938+0 records in
938+0 records out
3934257152 bytes (3.9 GB, 3.7 GiB) copied, 30.0918 s, 131 MB/s


130 MB/s is the maximum transfer rate of the drive observed when it was directly connected via SATA.

[tkaiser]

Bus 004 Device 004: ID 0bc2:2322 Seagate RSS LLC

Obviously this thing is broken (ASM1153 combined with broken firmware and hardware vendor don't giving a sh*t -- BTW: that's the reason I never buy 'external disks' but only empty enclosures with chipsets known and HDDs/SSDs separately). Would be great if you would send a patch upstream so this broken enclosure can be blacklisted in kernel (like it's done with many broken designs already, that's what uas-detect.h is about).

[tkaiser]

I am happy to report that the copy from /dev/zero completed without issue over SATA

Whatever this task should be able to 'test'. Are you searching for data corruption or only 'it's already way too late' situations? In case you care about the former I would strongly recommend to use filesystems that are able to detect data corruption. Using btrfs on a HDD with 2 metadata copies (default unless you change it) allows rather precisely to report data corruption. Just repeat the test and let then run a 'btrfs scrub' on the filesystem (strongly recommended to do this regularly eg. every month)

[rncwnd]

Thanks @crashoverride for your testing and findings!

2) We need to allow end users to disable UAS. There is already an issue for this here: https://github.com/hardkernel/linux/issues/290

I discovered you can do this as a parameter on the kernel command line in boot.ini

Code: Select all

usb-storage.quirks=0x0bc2:0x2322:u

Tried that too, but it doesn't work. After reboot boot.ini is reverted.

I tried blacklisting UAS, but the kernel does not not load any driver (mass storage) at all.

Code: Select all

modprobe.blacklist=uas

Tried that before. Same result...

[DarkBahamut]

What is the performance penalty with it disabled?

In my case, there isn't one!

130 MB/s is the maximum transfer rate of the drive observed when it was directly connected via SATA.

When I tested before the patch I could manage ~137MB/s on the usb storage driver with an SSD, so any drives that manage less than that via a direct SATA connection shouldn't see any performance penalty. There will be increased CPU usage, but with so many CPU cores available on the XU4 that's unlikely to be a huge issue for most. All but the highest performance mechanical drives are likely not going to suffer too much on the usb storage driver. And of course for NAS applications the performance will be limited by the NIC to 115MB/s anyway which is a factor to consider.

UAS is good for 280-300MB/s, so SSD's will get a big increase, and I suspect the lower CPU usage/latency will really help 4k random accesses on them too.

The UAS driver is a nice addition for sure, but those sticking with the usb storage driver are still going to be getting a pretty nice level of performance

[tkaiser]

Folks, there has been a lot of serious research already be done in the past (not just in the last few weeks):

* https://github.com/tobetter/linux/issues/5
* http://xu4.keltike.de/performance/odroidxu4-with-and-without-uas-support/

UAS is a protocol and not a 'driver' and USB equipment (especially cheap one) is known to be crappy sometimes. Instead of fearing UAS we should focus on improving things. @crashoverride for example identified another totally broken device that claims to be UAS capable but is NOT. So he should send a patch upstream to USB kernel maintainers (or if not familiar with the process maybe just ask Hans and provide details) so this broken device can be blacklisted from now on and won't cause problems any more.

[crashoverride]

Tried that too, but it doesn't work. After reboot boot.ini is reverted.

Using the official Ubuntu image, I modified boot.ini as follows (usb-storage.quirks=0x0bc2:0x2322:u):
https://github.com/mdrjr/5422_bootini/blob/e832f8b3b21287e5e1f84dd061f551674ff08af0/boot.ini#L10-L13

#------------------------------------------------------------------------------------------------------
# Basic Ubuntu Setup. Don't touch unless you know what you are doing.
# --------------------------------
setenv bootrootfs "usb-storage.quirks=0x0bc2:0x2322:u console=tty1 console=ttySAC2,115200n8 root=UUID=e139ce78-9841-40fe-8823-96a304a09859 rootwait ro fsck.repair=yes net.ifnames=0"

After reboot, the change is still present. It will, however, be overwritten sometimes after "sudo apt upgrade".

Note that you need to change "0x0bc2:0x2322" to the VID:PID of the device to disable UAS for as mentioned in my earlier post.

[crashoverride]

Whatever this task should be able to 'test'. Are you searching for data corruption or only 'it's already way too late' situations?

The intention was to force the HDD to remap any bad sectors.

[moon.linux]

Instead of fearing UAS we should focus on improving things.

Yes I agree with this in the future we will see some core changes on USB 3.0 phy.

[tkaiser]

The intention was to force the HDD to remap any bad sectors.

You trust (again) in a HDD that already threw bad sectors and don't try to check for data integrity errors from now on (easy as already explained, it just needs to realize that filesystems that are based on decades old concepts are maybe somewhat anachronistic these days and that better alternatives exist)?

Anyway just a simple question: after that much of testing and wasting your time that allows us to identify two more Seagate USB3 'products' as broken:

* your Seagate HDD enclosure as broken wrt UAS (0bc2:2322)
* @Mattrix/@matthuisman Seagate HDD enclosure as broken wrt UAS (0bc2:3321) --> https://github.com/hardkernel/linux/issues/290

Do you plan to search for 'solutions' that only apply to this micro community here or will you be responsible and contribute fix/information upstream? 10 of these Seagate 'products' are already UAS blacklisted and the two from this thread should be blacklisted too to save every USB3 user out there from being affected by broken products.

https://github.com/hardkernel/linux/blo ... h#L54-L122

[tkaiser]

Forgot: http://www.linux-usb.org/FAQ.html#ts1 and https://github.com/torvalds/linux/blob/ ... sual_uas.h (even with 4.11 still only 10 Seagate products listed as being broken, the two that have been discovered in this thread still missing and needing upstream reporting!)

[crashoverride]

You trust (again) in a HDD that already threw bad sectors and don't try to check for data integrity errors from now on

Doing kernel development is a "hostile environment" for data regardless of filesystem. In past tests, the IOMMU has overrun memory used by the filesystem causing the FS driver to write out the junk data (and metadata) as if it were valid. A monolithic kernel can not guard against any driver doing the same. My use case is unique in the activities I perform. For this reason, it is not uncommon for me to wipe eMMC, SD, HDD repeatedly and frequently. Bad sectors are not a "deal breaker" for me; rather, they are the least of possible sources of corrupt data I will face on any give day.

after that much of testing and wasting your time

I can not dismiss it as a waste of time. The revelation that the issues seen applies to all current Linux system has resolved an anomaly seen on a x86-64 server currently in use here (UAS works... until it doesn't). Furthermore, it prevents anyone "wasting time/money" looking for an XU4 specific cause.

Do you plan to search for 'solutions' that only apply to this micro community here

Since UAS is not "an Odroid issue", the solution applies to everyone, everywhere: If you have UAS problems, disable it. As noted before, it fixed our strange x86-64 server "random" issue.

or will you be responsible and contribute fix/information upstream?

I have no evidence supporting the theory that it is "broken" hardware. The same hardware functions without issue on computers running Windows and MacOS. I have not yet tested FreeBSD.

[tkaiser]

A couple of Seagate Disk enclosures are known to cause problems with Linux UAS implementation for whatever reasons (the kernel knows 18 exceptions and 10 of them are Seagate devices). The obvious solution: blacklist UAS for those 'broken' combinations until someone comes up with a real fix. This can be done on 'micro community' level suggesting boot.ini tweaks that might get lost with future upgrades (and ensures more ODROID-XU4 users can continue whining about UAS being bad/dangerous/whatever) while it would be better to save the whole Linux community from issues with these broken combinations.

Simple question: will either you or mattrix take the additional time to report UAS issues with two more Seagate enclosures or not?

[crashoverride]

Simple question: will either you or mattrix take the additional time to report UAS issues with two more Seagate enclosures or not?

I can only speak for myself:

[edit]
See also:
https://bugs.launchpad.net/ubuntu/+sour ... ug/1584557

Seagate STEA1000400 external USB hard disk (USB ID 0bc2:2322) causes

usb-storage.quirks=0x0bc2:0x2322:u

It has already been reported.

[edit]
Post #12 of bug report:

I've been seeing issues like this with a bevy of external drives hooked up through USB, on every single GNU/Linux distribution that is running kernel 4.3 or later.

It would probably be simpler to "white-list" drives they have tested.

[tkaiser]

It has already been reported.

A bug that has been reported over at Ubuntu doesn't affect this kernel at all. If we would instead talk about Ubuntu on x86/x64 and we would use Ubuntu's kernel then this might be worth to mention but we're talking about either HK's 4.9 kernel tree (we could call that vendor kernel) or mainline kernel.

So I see, the ODROID XU4 micro community prefers to remain insular, prefers to consider UAS being broken/dangerous/whatever and doesn't care about bugs fixed upstream. It would you both just require collecting full 'lsusb -v' output and then posting a brief description of the issue to linux-usb mailing list with a link to this thread.

[crashoverride]

A bug that has been reported over at Ubuntu doesn't affect this kernel at all.

When/if there is a fix upstream, we can backport it.

So I see, the ODROID XU4 micro community prefers to remain insular, prefers to consider UAS being broken/dangerous/whatever and doesn't care about bugs fixed upstream.

I am grateful to the community for raising the issue especially since it was the solution to a x86-64 issue I was seeing.

"UAS being broken/dangerous/whatever" has absolutely nothing to do with the Odroid community. The same issue is present on any board using USB3 capable of UAS, and it has been reported. There is nothing a duplicate report could add beyond what already has been reported. The output of "lsusb -v" is both known and meaningless:
https://www.spinics.net/lists/linux-usb/msg155618.html

Okay, nothing suspicious there.

(and yes, that is also an issue I encountered when using GPT partitions since it uses the last block.)

In conclusion, nobody wants UAS to be "broken"; it just is for many (but not all?) devices. The community is not blocking, obfuscating or otherwise impeding resolution of the issue. If Linus Torvalds happens to be a neighbor of someone in the Odroid community, please point him to this thread.

Until then, when its fixed for the rest of the world, it will also be fixed for us.

[tkaiser]

Ok, I finally give up.

The unwillingness to contribute to a real fix upstream is at least amazing. Good luck with this 'new' UAS world

For anyone else who's willing to go for a real solution: grab whole 'lsusb -v' output while your Seagate disk enclosure is connected and read through https://github.com/torvalds/linux/blob/ ... sual_uas.h how/where to report so Linux USB maintainers can blacklist those devices in upstream kernel module!

4.11 has been released today, merge window for 4.12 is now open so it would be rather wise to do this asapissimo.

[crashoverride]

Agreed. Anyone wishing to post the information to the mailing-list should do so.

[tkaiser]

To finish what started here: viewtopic.php?f=93&t=15727#p102754

I submitted patch/info to Hans and he said he'll send it upstream. Good luck to everyone trapped in micro communities.

[crashoverride]

Now that is resolved, we should move on to what we intend to do about the issue.

We should probably look into white-listing devices. I propose we reverse the behavior of the "quirk" flag so that everything is black-listed unless specifically enabled.

For the majority of mechanical USB drives, there should be no performance penalty. Right now there is an issue of everyone blaming XU4 "broken USB3". Additionally, white-listing is the safest default option for data. Its going to be far simpler to enable the "one or two devices" that are Linux compatible than to black-list "the thousands that are not".

[tkaiser]

Right now there is an issue of everyone blaming XU4 "broken USB3".

LOL! Can't really believe it. You bought a broken Seagate enclosure (eating one sector of a disk's capacity due to a firmware bug is a symptom for being broken), then there's a problem with these Seagate USB-to-SATA bridges (relying on ASM1153 but using a 'branded' broken firmware) with Linux that needs blacklisting. The problem why people still run into such issues in 2017 is that people in general are not contributing and don't send patches upstream to USB Linux kernel maintainers.

Now that's done. The UAS exception list contained 18 devices (10 of them being Seagates) before and starting with kernel 4.12 it will be 20 (12 of them being Seagates). But in case you feel better rejecting reality and claiming 'only a few devices work well but thousands not and we the great ODROID XU4 micro community know better than the rest of the Linux world' feel free to continue.

In case you want to improve XU4 specific things better look again into this: viewtopic.php?f=146&t=26016&start=50#p187838
This is either a cabling/contact problem (that needs attention in form of a readme: 'ODROID-XU4 users please be aware that many USB cables suck and that contact issues cause all sorts of troubles once SuperSpeed/5GHz are involved') or a problem with the internal USB3 hub on the XU4 (coming up after a reset in a strange state and therefore sitting in between host and drive and cutting the SuperSpeed data lines).

[mattrix]

Oh man, I haven't read this thread in a while.

I would have been happy to send a patch up.
Just so I can try getting my name in Linux Kernel source!

@tkaiser
So you have sent a patch for 0x0bc2x0x2322 & 0x0bc2:0x3321 ?

I have the 3321, here is a lsusb -v if you did need it:
https://pastebin.com/1bdjhjq8

These Seagate drives are pretty popular in New zealand (probably as they are the cheapest).

[crashoverride]

we the great ODROID XU4 micro community know better than the rest

If you have a problem take it up with me. The Odroid community has been outstanding and I am proud to be part of it.

I have alread had to clean up after your mess:
https://github.com/hardkernel/linux/com ... e4e818013a

[tkaiser]

So you have sent a patch for 0x0bc2x0x2322 & 0x0bc2:0x3321 ?

I've sent Hans de Goede link to this patch https://github.com/armbian/build/commit ... 46abc9c125 and he said he'll send it upstream. Since I don't have the devices I can't test whether this patch does it really fix or not. So it's more or less based on the assumption that Seagate re-uses same ASM1153 with same firmware on all their USB3 disks (though using different product IDs for whatever purpose).

To me it seems pretty obvious what happened with all those Seagate enclosures. They chose ASM1153 for all their USB3 disks, then allowed the one software guy they hired to work a few days on the software and that way they introduced both the capacity bug (ASM1153 with Seagate firmware reports one sector less -- maybe Seagate considers this being a feature since it doesn't affect customers until they want to use a different HDD in these enclosures that has been used somewhere else before) and also the UAS 'bug' (at least it's a problem with Linux' UAS implementation).

And why does unusual_uas.h gets flooded with so many Seagate devices? Since it's always the same: ASM1153 with broken/branded firmware. I guess they use the different product IDs to be able to display nice logos in some fancy/useless Windows/macOS software they bundle with their drives. No idea since as already said I would never buy 'external HDDs' for exactly that reason: the risk to get a crappy branded firmware that never receives updates again is way too high.

So instead of 'white-listing' you should better get in contact with your Seagate representative to ask them whether they could schedule/allow their software guy to spend a couple of hours on fixing the firmware and provide an update?

And since Seagate will release more and more USB3 products in the future (all with different product IDs) in the meantime it might be an idea to blacklist everything with vendor ID 0bc2 (though once Seagate decides to use another bridge chip eg. JMS578 and also decides to re-use same vendor/product ID then all this device identification stuff will go wrong anyway -- major brands are known to do such crap from time to time).

[odroid]

I've found another problematic USB-SATA UAS bridge controller.
It is NS1068X chipset 0x2537:0x1068 in this enclosure http://www.orico.cc/goods.php?id=6351
Mounting time was extremely slow and it shows ERROR Transfer event for disabled endpoint or incorrect stream ring messages randomly.
After adding usb-storage.quirks=0x2537:0x1068:u in kernel parameter, it worked stably without UAS mode.
But it was 20~30% slower than other JMS567/JMS561 based UAS bridge boards.
My x86 i7 Ubuntu PC(kernel 4.4) also have the same issue with NS1068X while Windows 10 PC has no issue at all.

My poor 3 years old 128GB SSD shows below test results on XU4 Kernel 4.9.25
With UAS (JMS567/561)

Code: Select all

WRITE
$ dd if=/dev/zero of=test3 oflag=direct bs=8M count=256
256+0 records in                                                                                                                                                   
256+0 records out                                                                                                                                                 
2147483648 bytes (2.1 GB, 2.0 GiB) copied, 10.8362 s, 198 MB/s

READ
$ dd if=test3 of=/dev/null iflag=direct bs=8M
256+0 records in                                                                                                                                                   
256+0 records out                                                                                                                                                 
2147483648 bytes (2.1 GB, 2.0 GiB) copied, 7.96288 s, 270 MB/s

Without UAS (NS1068X)

Code: Select all

WRITE
$ dd if=/dev/zero of=test3 oflag=direct bs=8M count=256
256+0 records in                                                                                                                                                   
256+0 records out                                                                                                                                                 
2147483648 bytes (2.1 GB, 2.0 GiB) copied, 12.2283 s, 176 MB/s                                                                                                     

READ
$ dd if=test3 of=/dev/null iflag=direct bs=8M
256+0 records in                                                                                                                                                   
256+0 records out                                                                                                                                                 
2147483648 bytes (2.1 GB, 2.0 GiB) copied, 10.1888 s, 211 MB/s

Is there any list of Linux compatible UAS chipsets?

[tkaiser]

Is there any list of Linux compatible UAS chipsets?

Since I didn't found something like that I did some research and started 'my own' 2 years ago (not maintained though since I relied on ASM1153 and JMS567 with original firmware in the meantime instead of testing through broken stuff): http://linux-sunxi.org/USB/UAS#UASP_cap ... enclosures

It would be great if you could share your findings with Linux USB maintainers. And I would strongly suggest to stop using dd for benchmarks since way better tools like fio or iozone3 are just an 'apt install' away!

Running dd with 8 MB blocksize has no meaning for any real workload out there. Better use fio with a mix of 50/50 or 72/25 read/write since then you're able to see the benefits of UAS even with HDDs.

[crashoverride]

Here is my proposed solution to the issue:
https://github.com/OtherCrashOverride/l ... 33692ab78a
https://github.com/OtherCrashOverride/5 ... fc575d6993

A new kernel parameter is added to the usb-storage driver that allows UAS to be disabled from the kernel command line rather than a re-compile. This parameter is also added to boot.ini giving users the option to control it. The kernel defaults to normal UAS behavior; however, boot.ini defaults to disabling UAS.

Code: Select all

#------------------------------------------------------------------------------
#
# USB attached SCSI (UAS) control
#
#------------------------------------------------------------------------------
#
# Disables the UAS driver for all devices.  The driver is known to cause issues
# with many USB storage devices.
# 0 : normal UAS behavior
# 1 : UAS is globally disabled
#
# default: 1
#
#------------------------------------------------------------------------------
setenv disable_uas "1"


[memeka]

What's wrong with having uas and usb-storage as modules?

[crashoverride]

What's wrong with having uas and usb-storage as modules?

If someone has their rootfs on a HDD, the drivers need to be either baked into the kernel or in initrd. If initrd is used, then it must stay in sync with the kernel. If it doesn't, the kernel will not be able to load the rootfs. Also, some users do not use an initrd.

[crashoverride]

I should probably throw this out there now:
I do not believe it is possible to have UAS enabled in the kernel but disabled as a module. When I tested this by blacklisting uas.ko, no storage driver at all is loaded for the device. The source code supports this observation:
https://github.com/OtherCrashOverride/linux-hardkernel/blob/odroidxu4-4.9.y/drivers/usb/storage/usb.c#L1126-L1129

Code: Select all

#if IS_ENABLED(CONFIG_USB_UAS)
   if (uas_use_uas_driver(intf, id, NULL))
      return -ENXIO;
#endif


My proposal above makes it possible to have UAS configured but disabled.

[edit]
It should also be theoretically possible to enable/disable "on-the-fly" through "/sys/module/usb_storage/parameters/disable_uas_flag" and disconnecting/reconnecting a USB storage device. However, I have not tested it.

[tkaiser]

However, I have not tested it.

You have not even tested whether your Seagate disk featuring just another broken firmware only needs the usual quirk(s) to work quite well with UAS since you're so busy protecting ODROID XU4 community from evil UAS

https://github.com/hardkernel/linux/com ... t-21984566

BTW: All the 'benchmarks' done here with dd trying to get a clue whether Mass Storage is as fast as UAS with HDDs are plain stupid if it's about normal disk usage and especially dealing with a lot of smaller files (since UAS has less overhead and supports NCQ).

[rooted]

However, I have not tested it.

You have not even tested whether your Seagate disk featuring just another broken firmware only needs the usual quirk(s) to work quite well with UAS since you're so busy protecting ODROID XU4 community from evil UAS [emoji38]

https://github.com/hardkernel/linux/com ... t-21984566

BTW: All the 'benchmarks' done here with dd trying to get a clue whether Mass Storage is as fast as UAS with HDDs are plain stupid if it's about normal disk usage and especially dealing with a lot of smaller files (since UAS has less overhead and supports NCQ).

Is there a reason you constantly have an attitude?

[crashoverride]

You have not even tested whether your Seagate disk featuring just another broken firmware only needs the usual quirk(s) to work quite well with UAS

This was addressed in the github comment linked earlier. The flags are not applicable to my issue.

since you're so busy protecting ODROID XU4 community from evil UAS

Like a super hero, I am protecting the entire world from "evil UAS" since this is not a XU4 specific issue.

Its not an issue of "blame". The fact of the matter is simply that UAS will cause problems/data loss for a great many devices. Whether you blame the "broken device" or the "the broken Linux driver" does not alter the fact that many users will encounters the issue. It is a false assumption to imply that Seagate shows up in the "unusual" list frequently because "its bad". The popularity of the devices also accounts for it. If nobody used them, they would go unreported just as the less common devices with issues do.

Since UAS is know to cause issue and since many users own devices that are known to exhibit issues, it makes sense to disable it by default while allowing advanced users to enable it should they choose. Armbian is free to decide whatever default it wishes. It is my personal recommendation that the official Ubuntu image disable UAS by default to prevent the hoards from massing with pitchforks and torches.

[rooted]

I agree, it should be disabled by default but should have a package that enables it for the CloudShell 2.

[crashoverride]

For those not following the github comment/flamewar, the "(ex) maintainer of the uas kernel driver" has posted stating the problem lies in the XU4, the cables, or the drive power supply.
https://github.com/hardkernel/linux/com ... t-21996557
I have noted there is evidence to the contrary. Anyone wishing to provide supplemental data, evidence, and/or observations should probably do so in the github thread.

My personal recommendation is still to proceed with the change that allows UAS to be optionally disabled. If the github topic results in a fix for more than just a single drive, we can look at backporting it (or wait for it to be provided in a LTS update). I do not believe there is any merit in "waiting to see what happens" and delaying the XU4 4.9.y image release.

[odroid]

We also found other two chipsets which have the same UAS problem.
0bc2:a003 Seagate RSS LLC Backup Plus
174c:5106 ASMedia Technology Inc. ASM1051
There must be many other incompatible controllers.

Is it possible to make a white-list of UAS compatible controller instead of black-list?

[tkaiser]

0bc2:a003 Seagate RSS LLC Backup Plus

Well, it's just another Seagate using the same ASM1153 + broken firmware combination. And if you read through the Github issue referenced above Hans de Goede recommends a specific fix (disable USB-3 bulk streams). Why not giving that a try?

174c:5106 ASMedia Technology Inc. ASM1051

ASM1051 is blacklisted since ages: http://www.spinics.net/lists/linux-usb/msg119432.html

The problem here is that ASMedia simply doesn't give a sh*t about correct device IDs and maybe you just spotted another enclosure messing things up. As Hans said it would help if people start to provide dmesg output when the error occurs (together with full 'lsusb -v' output). How should stuff be fixed if not properly reported upstream?

[moon.linux]

We should enable CONFIG_DYNAMIC_DEBUG and CONFIG_USB_DEBUG to trace the usb handshakes between the USB device.

https://burzalodowa.wordpress.com/2013/ ... -for-xhci/

Also some support for LPM and u2_susphy_quirk/u3_susphy_quirk controller is missing.
Could you people integrate following patch in your testing.

[tkaiser]

I second moon.linux's suggestion and want to ask @odroid whether it's possible that you add description + relevant dmesg + lsusb output to the aforementioned github issue (adding information for NS1068X there too)?

[moon.linux]

@tkaiser
just the diff of lusb -tt will be good enough to trace the issue.

If this is not related to the Seagate SATA drive then I will check with at my end with my 2.5" drive.
and share the relevant information.

[crashoverride]

And if you read through the Github issue referenced above Hans de Goede recommends a specific fix (disable USB-3 bulk streams). Why not giving that a try?

Perhaps someone can elaborate on how disabling USB-3 bulk streams on XU4 will fix the issue on my x86 PC. Are they quantum entangled?

We should enable CONFIG_DYNAMIC_DEBUG and CONFIG_USB_DEBUG to trace the usb handshakes between the USB device.

It is not a XU4 hardware issue. It also occurs on x86 PC.

[tkaiser]

Perhaps someone can elaborate on how disabling USB-3 bulk streams on XU4 will fix the issue on my x86 PC.

You're still referring to this 'test' here: viewtopic.php?f=146&t=26016&start=50#p188246

Ok, you've a harddisk that already showed physical errors living in an enclosure that is buggy (firmware eats up the last sector) and part of a disk enclosure series knowing to cause trouble with UAS anyway (combining an ASM1153 USB-to-SATA bridge with a somewhat problematic firmware).

A guy 'somewhat familiar' with Linux USB issues (I think you're still laughing on him?) mentioned UAS being more efficient and therefore switching between usb-storage and UAS sometimes triggers weird errors related to insufficient powering. Your disk enclosure is bus-powered so what happens also depends on current/voltage available on the host's USB ports.

I would neither call this a proper test setup nor a testing methodology.

Hans mentioned not having received a single such error from PC users and mentioned his belief that 'disabling USB-3 bulk streams' might be worth a look since the problem can be a USB host controller issue (which host controller is your 'Core i5 PC' using? IIRC you never mentioned this). He even used an example with another problematic USB host controller (Fresco Logic FL1009) to illustrate that.

What's living inside the Exynos? Is this some Synopsys IP?

[crashoverride]

You're still referring to this 'test' here

That is only one of the issues I am referring to. The same issues are reproducible even with my external powered USB3 UAS drives.

This issue is reproducible across various other equipment too (as pointed out in this thread). This would appear to indemnify my poor little drive. It was just in the wrong place at the wrong time.

I would neither call this a proper test setup nor a testing methodology.

The experiments and data are openly presented for peer review. Furthermore, it has also been independently reproduced on x86. The equipment required to reproduce the issue is commodity and openly available to anyone wishing to procure it. There is no evidence to suggest this is anything other than a "Linux incompatibility".

@tkaiser, again, Armbian is free to make the choices regarding UAS that it deems appropriate for its consumers. HardKernel will do the same for their customer interests.

[crashoverride]

Is it possible to make a white-list of UAS compatible controller instead of black-list?

I have not found any currently available method to achieve a white-list. We could develop that feature. However, since it would be a more complicated change than disabling UAS, it would take more time and testing than disabling does.

[rooted]

I think Armbian needs to focus a bit on their XU4 booting process, it seems to be broken for 4.9.y from eMMC currently. Without 4.9.y there is no UAS.

I spent many hours yesterday attempting to get mainline uboot working since the shipping hardkernel uboot has no ext4load, without it you can't boot from the single ext4 partition Armbian uses.

I created a workable boot.cmd/boot.scr and now have Armbian booting 4.9.y on my XU4 from a single ext4 partition. I will create a pull request unless something has changed since yesterday.

[linuxest]

OMV(kernel 4.9) image has no "fbtft_device" driver in their Kernel. So I couldn't enable the TFT LCD of CloudShell2.
Where should I report this issue?

BTW, which USB-SATA bridge chipsets are compatible for UASP for XU4 Kernel 4.9?