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.

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! [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.

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: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)

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

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 wrote: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:

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.

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

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: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.

tkaiser wrote: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.

tkaiser wrote: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.

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?

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.

tkaiser wrote: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.

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.

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.

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".

crashoverride wrote: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#p187838This 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 wrote: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).

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=6351Mounting 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.

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.

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.

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.

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.

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

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).

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]

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).

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.

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-21996557I 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.

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?

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?

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.

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.

odroid wrote: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.