Getting UAS working on HK 4.9
-
- Posts: 5276
- Joined: Tue Dec 30, 2014 8:42 pm
- languages_spoken: english
- ODROIDs: C1
- Has thanked: 0
- Been thanked: 418 times
- Contact:
Re: Getting UAS working on HK 4.9
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.
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.
-
- Posts: 5276
- Joined: Tue Dec 30, 2014 8:42 pm
- languages_spoken: english
- ODROIDs: C1
- Has thanked: 0
- Been thanked: 418 times
- Contact:
Re: Getting UAS working on HK 4.9
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.

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.

-
- Posts: 9257
- Joined: Wed Jul 15, 2015 5:00 pm
- languages_spoken: english
- ODROIDs: XU4, C1+, C2, C4, N1, N2, H2, Go, Go Advance
- Location: Bucharest, Romania
- Has thanked: 599 times
- Been thanked: 626 times
- Contact:
Re: Getting UAS working on HK 4.9
Glad to hear that. I will then cancel the order for a 6TB drive I was shipping to your place 

- rooted
- Posts: 8425
- Joined: Fri Dec 19, 2014 9:12 am
- languages_spoken: english
- Location: Gulf of Mexico, US
- Has thanked: 740 times
- Been thanked: 330 times
- Contact:
Re: Getting UAS working on HK 4.9
Thanks for all that testing, I'm wary of UAS now.crashoverride wrote: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.
What is the performance penalty with it disabled?
-
- Posts: 5276
- Joined: Tue Dec 30, 2014 8:42 pm
- languages_spoken: english
- ODROIDs: C1
- Has thanked: 0
- Been thanked: 418 times
- Contact:
Re: Getting UAS working on HK 4.9
In my case, there isn't one!rooted wrote:What is the performance penalty with it disabled?

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
-
- Posts: 673
- Joined: Mon Nov 09, 2015 12:30 am
- languages_spoken: english
- ODROIDs: C1+, C2, XU4, HC1
- Has thanked: 0
- Been thanked: 5 times
- Contact:
Re: Getting UAS working on HK 4.9
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).crashoverride wrote:Bus 004 Device 004: ID 0bc2:2322 Seagate RSS LLC
-
- Posts: 673
- Joined: Mon Nov 09, 2015 12:30 am
- languages_spoken: english
- ODROIDs: C1+, C2, XU4, HC1
- Has thanked: 0
- Been thanked: 5 times
- Contact:
Re: Getting UAS working on HK 4.9
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)crashoverride wrote:I am happy to report that the copy from /dev/zero completed without issue over SATA
-
- Posts: 34
- Joined: Tue Apr 11, 2017 11:18 pm
- languages_spoken: english, german
- ODROIDs: XU4
- Has thanked: 0
- Been thanked: 0
- Contact:
Re: Getting UAS working on HK 4.9
Thanks @crashoverride for your testing and findings!
Tried that too, but it doesn't work. After reboot boot.ini is reverted.crashoverride wrote:I discovered you can do this as a parameter on the kernel command line in boot.inicrashoverride wrote:2) We need to allow end users to disable UAS. There is already an issue for this here: https://github.com/hardkernel/linux/issues/290Code: Select all
usb-storage.quirks=0x0bc2:0x2322:u
Tried that before. Same result...crashoverride wrote:crashoverride wrote:I tried blacklisting UAS, but the kernel does not not load any driver (mass storage) at all.Code: Select all
modprobe.blacklist=uas
-
- Posts: 333
- Joined: Tue Jan 19, 2016 10:19 am
- languages_spoken: english
- ODROIDs: XU4, N1
- Has thanked: 0
- Been thanked: 0
- Contact:
Re: Getting UAS working on HK 4.9
rooted wrote:What is the performance penalty with it disabled?
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.crashoverride wrote: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.
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

-
- Posts: 673
- Joined: Mon Nov 09, 2015 12:30 am
- languages_spoken: english
- ODROIDs: C1+, C2, XU4, HC1
- Has thanked: 0
- Been thanked: 5 times
- Contact:
Re: Getting UAS working on HK 4.9
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/odroi ... s-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.
* https://github.com/tobetter/linux/issues/5
* http://xu4.keltike.de/performance/odroi ... s-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.
-
- Posts: 5276
- Joined: Tue Dec 30, 2014 8:42 pm
- languages_spoken: english
- ODROIDs: C1
- Has thanked: 0
- Been thanked: 418 times
- Contact:
Re: Getting UAS working on HK 4.9
Using the official Ubuntu image, I modified boot.ini as follows (usb-storage.quirks=0x0bc2:0x2322:u):rncwnd wrote:Tried that too, but it doesn't work. After reboot boot.ini is reverted.
https://github.com/mdrjr/5422_bootini/b ... ni#L10-L13
After reboot, the change is still present. It will, however, be overwritten sometimes after "sudo apt upgrade".#------------------------------------------------------------------------------------------------------
# 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"
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.
-
- Posts: 5276
- Joined: Tue Dec 30, 2014 8:42 pm
- languages_spoken: english
- ODROIDs: C1
- Has thanked: 0
- Been thanked: 418 times
- Contact:
Re: Getting UAS working on HK 4.9
The intention was to force the HDD to remap any bad sectors.tkaiser wrote:Whatever this task should be able to 'test'. Are you searching for data corruption or only 'it's already way too late' situations?
-
- Posts: 1199
- Joined: Thu Oct 02, 2014 11:42 pm
- languages_spoken: english
- ODROIDs: U3, XU3. XU4, C1+...
- Has thanked: 0
- Been thanked: 13 times
- Contact:
Re: Getting UAS working on HK 4.9
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.
Yes I agree with this in the future we will see some core changes on USB 3.0 phy.
-
- Posts: 673
- Joined: Mon Nov 09, 2015 12:30 am
- languages_spoken: english
- ODROIDs: C1+, C2, XU4, HC1
- Has thanked: 0
- Been thanked: 5 times
- Contact:
Re: Getting UAS working on HK 4.9
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)?crashoverride wrote:The intention was to force the HDD to remap any bad sectors.
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
-
- Posts: 673
- Joined: Mon Nov 09, 2015 12:30 am
- languages_spoken: english
- ODROIDs: C1+, C2, XU4, HC1
- Has thanked: 0
- Been thanked: 5 times
- Contact:
Re: Getting UAS working on HK 4.9
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!)
-
- Posts: 5276
- Joined: Tue Dec 30, 2014 8:42 pm
- languages_spoken: english
- ODROIDs: C1
- Has thanked: 0
- Been thanked: 418 times
- Contact:
Re: Getting UAS working on HK 4.9
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.tkaiser wrote:You trust (again) in a HDD that already threw bad sectors and don't try to check for data integrity errors from now on
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.tkaiser wrote:after that much of testing and wasting your time
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.tkaiser wrote:Do you plan to search for 'solutions' that only apply to this micro community here
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 wrote:or will you be responsible and contribute fix/information upstream?
-
- Posts: 673
- Joined: Mon Nov 09, 2015 12:30 am
- languages_spoken: english
- ODROIDs: C1+, C2, XU4, HC1
- Has thanked: 0
- Been thanked: 5 times
- Contact:
Re: Getting UAS working on HK 4.9
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?
Simple question: will either you or mattrix take the additional time to report UAS issues with two more Seagate enclosures or not?
-
- Posts: 5276
- Joined: Tue Dec 30, 2014 8:42 pm
- languages_spoken: english
- ODROIDs: C1
- Has thanked: 0
- Been thanked: 418 times
- Contact:
Re: Getting UAS working on HK 4.9
I can only speak for myself:tkaiser wrote:Simple question: will either you or mattrix take the additional time to report UAS issues with two more Seagate enclosures or not?
Seagate STEA1000400 external USB hard disk (USB ID 0bc2:2322) causes
It has already been reported.crashoverride wrote:usb-storage.quirks=0x0bc2:0x2322:u
[edit]
Post #12 of bug report:
It would probably be simpler to "white-list" drives they have tested.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.

-
- Posts: 673
- Joined: Mon Nov 09, 2015 12:30 am
- languages_spoken: english
- ODROIDs: C1+, C2, XU4, HC1
- Has thanked: 0
- Been thanked: 5 times
- Contact:
Re: Getting UAS working on HK 4.9
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.crashoverride wrote:It has already been reported.
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.
-
- Posts: 5276
- Joined: Tue Dec 30, 2014 8:42 pm
- languages_spoken: english
- ODROIDs: C1
- Has thanked: 0
- Been thanked: 418 times
- Contact:
Re: Getting UAS working on HK 4.9
When/if there is a fix upstream, we can backport it.tkaiser wrote:A bug that has been reported over at Ubuntu doesn't affect this kernel at all.
I am grateful to the community for raising the issue especially since it was the solution to a x86-64 issue I was seeing.tkaiser wrote: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.

"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
(and yes, that is also an issue I encountered when using GPT partitions since it uses the last block.)Okay, nothing suspicious there.
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.
-
- Posts: 673
- Joined: Mon Nov 09, 2015 12:30 am
- languages_spoken: english
- ODROIDs: C1+, C2, XU4, HC1
- Has thanked: 0
- Been thanked: 5 times
- Contact:
Re: Getting UAS working on HK 4.9
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.
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.
Last edited by tkaiser on Tue May 02, 2017 6:17 am, edited 1 time in total.
-
- Posts: 5276
- Joined: Tue Dec 30, 2014 8:42 pm
- languages_spoken: english
- ODROIDs: C1
- Has thanked: 0
- Been thanked: 418 times
- Contact:
Re: Getting UAS working on HK 4.9
Agreed. Anyone wishing to post the information to the mailing-list should do so.
-
- Posts: 673
- Joined: Mon Nov 09, 2015 12:30 am
- languages_spoken: english
- ODROIDs: C1+, C2, XU4, HC1
- Has thanked: 0
- Been thanked: 5 times
- Contact:
Re: Getting UAS working on HK 4.9
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.
I submitted patch/info to Hans and he said he'll send it upstream. Good luck to everyone trapped in micro communities.
-
- Posts: 5276
- Joined: Tue Dec 30, 2014 8:42 pm
- languages_spoken: english
- ODROIDs: C1
- Has thanked: 0
- Been thanked: 418 times
- Contact:
Re: Getting UAS working on HK 4.9
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".
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".
-
- Posts: 673
- Joined: Mon Nov 09, 2015 12:30 am
- languages_spoken: english
- ODROIDs: C1+, C2, XU4, HC1
- Has thanked: 0
- Been thanked: 5 times
- Contact:
Re: Getting UAS working on HK 4.9
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.crashoverride wrote:Right now there is an issue of everyone blaming XU4 "broken USB3".
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).
-
- Posts: 89
- Joined: Tue Jan 13, 2015 7:12 am
- languages_spoken: english
- ODROIDs: C1
- Has thanked: 0
- Been thanked: 0
- Contact:
Re: Getting UAS working on HK 4.9
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).
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).
-
- Posts: 5276
- Joined: Tue Dec 30, 2014 8:42 pm
- languages_spoken: english
- ODROIDs: C1
- Has thanked: 0
- Been thanked: 418 times
- Contact:
Re: Getting UAS working on HK 4.9
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.tkaiser wrote:we the great ODROID XU4 micro community know better than the rest
I have alread had to clean up after your mess:
https://github.com/hardkernel/linux/com ... e4e818013a
-
- Posts: 673
- Joined: Mon Nov 09, 2015 12:30 am
- languages_spoken: english
- ODROIDs: C1+, C2, XU4, HC1
- Has thanked: 0
- Been thanked: 5 times
- Contact:
Re: Getting UAS working on HK 4.9
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).mattrix wrote:So you have sent a patch for 0x0bc2x0x2322 & 0x0bc2:0x3321 ?
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
- Site Admin
- Posts: 36949
- Joined: Fri Feb 22, 2013 11:14 pm
- languages_spoken: English, Korean
- ODROIDs: ODROID
- Has thanked: 1598 times
- Been thanked: 1072 times
- Contact:
Re: Getting UAS working on HK 4.9
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
After adding
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)
Without UAS (NS1068X)
Is there any list of Linux compatible UAS chipsets?
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
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
-
- Posts: 673
- Joined: Mon Nov 09, 2015 12:30 am
- languages_spoken: english
- ODROIDs: C1+, C2, XU4, HC1
- Has thanked: 0
- Been thanked: 5 times
- Contact:
Re: Getting UAS working on HK 4.9
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 ... enclosuresodroid wrote:Is there any list of Linux compatible UAS chipsets?
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.
-
- Posts: 5276
- Joined: Tue Dec 30, 2014 8:42 pm
- languages_spoken: english
- ODROIDs: C1
- Has thanked: 0
- Been thanked: 418 times
- Contact:
Re: Getting UAS working on HK 4.9
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.
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"
-
- Posts: 5276
- Joined: Tue Dec 30, 2014 8:42 pm
- languages_spoken: english
- ODROIDs: C1
- Has thanked: 0
- Been thanked: 418 times
- Contact:
Re: Getting UAS working on HK 4.9
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.memeka wrote:What's wrong with having uas and usb-storage as modules?
-
- Posts: 5276
- Joined: Tue Dec 30, 2014 8:42 pm
- languages_spoken: english
- ODROIDs: C1
- Has thanked: 0
- Been thanked: 418 times
- Contact:
Re: Getting UAS working on HK 4.9
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/l ... 1126-L1129
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.
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/l ... 1126-L1129
Code: Select all
#if IS_ENABLED(CONFIG_USB_UAS)
if (uas_use_uas_driver(intf, id, NULL))
return -ENXIO;
#endif
[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.
-
- Posts: 673
- Joined: Mon Nov 09, 2015 12:30 am
- languages_spoken: english
- ODROIDs: C1+, C2, XU4, HC1
- Has thanked: 0
- Been thanked: 5 times
- Contact:
Re: Getting UAS working on HK 4.9
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 UAScrashoverride wrote:However, I have not tested it.

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
- Posts: 8425
- Joined: Fri Dec 19, 2014 9:12 am
- languages_spoken: english
- Location: Gulf of Mexico, US
- Has thanked: 740 times
- Been thanked: 330 times
- Contact:
Re: Getting UAS working on HK 4.9
Is there a reason you constantly have an attitude?tkaiser wrote: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 UAScrashoverride wrote:However, I have not tested it.![]()
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).
-
- Posts: 5276
- Joined: Tue Dec 30, 2014 8:42 pm
- languages_spoken: english
- ODROIDs: C1
- Has thanked: 0
- Been thanked: 418 times
- Contact:
Re: Getting UAS working on HK 4.9
This was addressed in the github comment linked earlier. The flags are not applicable to my issue.tkaiser wrote: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
Like a super hero, I am protecting the entire world from "evil UAS" since this is not a XU4 specific issue.tkaiser wrote:since you're so busy protecting ODROID XU4 community from evil UAS

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
- Posts: 8425
- Joined: Fri Dec 19, 2014 9:12 am
- languages_spoken: english
- Location: Gulf of Mexico, US
- Has thanked: 740 times
- Been thanked: 330 times
- Contact:
Re: Getting UAS working on HK 4.9
I agree, it should be disabled by default but should have a package that enables it for the CloudShell 2.
-
- Posts: 5276
- Joined: Tue Dec 30, 2014 8:42 pm
- languages_spoken: english
- ODROIDs: C1
- Has thanked: 0
- Been thanked: 418 times
- Contact:
Re: Getting UAS working on HK 4.9
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.
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
- Site Admin
- Posts: 36949
- Joined: Fri Feb 22, 2013 11:14 pm
- languages_spoken: English, Korean
- ODROIDs: ODROID
- Has thanked: 1598 times
- Been thanked: 1072 times
- Contact:
Re: Getting UAS working on HK 4.9
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?
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?
-
- Posts: 673
- Joined: Mon Nov 09, 2015 12:30 am
- languages_spoken: english
- ODROIDs: C1+, C2, XU4, HC1
- Has thanked: 0
- Been thanked: 5 times
- Contact:
Re: Getting UAS working on HK 4.9
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?odroid wrote:0bc2:a003 Seagate RSS LLC Backup Plus
ASM1051 is blacklisted since ages: http://www.spinics.net/lists/linux-usb/msg119432.htmlodroid wrote:174c:5106 ASMedia Technology Inc. ASM1051
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?
-
- Posts: 1199
- Joined: Thu Oct 02, 2014 11:42 pm
- languages_spoken: english
- ODROIDs: U3, XU3. XU4, C1+...
- Has thanked: 0
- Been thanked: 13 times
- Contact:
Re: Getting UAS working on HK 4.9
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.
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.
- Attachments
-
- a9cfc8d.diff.zip
- Enable LPM and U2/U3 quick link
- (775 Bytes) Downloaded 106 times
-
- Posts: 673
- Joined: Mon Nov 09, 2015 12:30 am
- languages_spoken: english
- ODROIDs: C1+, C2, XU4, HC1
- Has thanked: 0
- Been thanked: 5 times
- Contact:
Re: Getting UAS working on HK 4.9
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)?
-
- Posts: 1199
- Joined: Thu Oct 02, 2014 11:42 pm
- languages_spoken: english
- ODROIDs: U3, XU3. XU4, C1+...
- Has thanked: 0
- Been thanked: 13 times
- Contact:
Re: Getting UAS working on HK 4.9
@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.
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.
-
- Posts: 5276
- Joined: Tue Dec 30, 2014 8:42 pm
- languages_spoken: english
- ODROIDs: C1
- Has thanked: 0
- Been thanked: 418 times
- Contact:
Re: Getting UAS working on HK 4.9
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?tkaiser wrote: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?
It is not a XU4 hardware issue. It also occurs on x86 PC.moon.linux wrote:We should enable CONFIG_DYNAMIC_DEBUG and CONFIG_USB_DEBUG to trace the usb handshakes between the USB device.
-
- Posts: 673
- Joined: Mon Nov 09, 2015 12:30 am
- languages_spoken: english
- ODROIDs: C1+, C2, XU4, HC1
- Has thanked: 0
- Been thanked: 5 times
- Contact:
Re: Getting UAS working on HK 4.9
You're still referring to this 'test' here: viewtopic.php?f=146&t=26016&start=50#p188246crashoverride wrote:Perhaps someone can elaborate on how disabling USB-3 bulk streams on XU4 will fix the issue on my x86 PC.
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?
-
- Posts: 5276
- Joined: Tue Dec 30, 2014 8:42 pm
- languages_spoken: english
- ODROIDs: C1
- Has thanked: 0
- Been thanked: 418 times
- Contact:
Re: Getting UAS working on HK 4.9
That is only one of the issues I am referring to. The same issues are reproducible even with my external powered USB3 UAS drives.tkaiser wrote:You're still referring to this 'test' here
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.

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 wrote:I would neither call this a proper test setup nor a testing methodology.
@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.
-
- Posts: 5276
- Joined: Tue Dec 30, 2014 8:42 pm
- languages_spoken: english
- ODROIDs: C1
- Has thanked: 0
- Been thanked: 418 times
- Contact:
Re: Getting UAS working on HK 4.9
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.odroid wrote:Is it possible to make a white-list of UAS compatible controller instead of black-list?
- rooted
- Posts: 8425
- Joined: Fri Dec 19, 2014 9:12 am
- languages_spoken: english
- Location: Gulf of Mexico, US
- Has thanked: 740 times
- Been thanked: 330 times
- Contact:
Re: Getting UAS working on HK 4.9
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.
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.
-
- Posts: 43
- Joined: Tue Nov 08, 2016 6:35 pm
- languages_spoken: english
- ODROIDs: 1 x HC1 and 2 x C2s with HiFi-Shield 2
And some RPi3 boards - Has thanked: 0
- Been thanked: 0
- Contact:
Re: Getting UAS working on HK 4.9
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?
Where should I report this issue?
BTW, which USB-SATA bridge chipsets are compatible for UASP for XU4 Kernel 4.9?
Who is online
Users browsing this forum: No registered users and 1 guest