Beiträge von nasnas

My cousin sister found the enclosure in her room.
The original Seagate enclosure worked fine with coherent_pool=1M option.
I've flashed the latest OMV image cleanly too and it also worked nicely out of the box.

I threw away the original Seagate 2.5" enclosure to somewhere.
I will try to find it Monday.
As per my note, its vid:pid is 0bc2:ab28.
If I find it, I will post the test result on here.

By the way, can you tell me more about the potential kernel fix?

Finally the boot.ini tweak fixed the annoying format issue finally.
Thank you for sharing the great news.

Thank you for the suggestion.
I tried "f", "t", "ft" and some other combinations with JMS578. Nothing worked except for "u".
But JMS561 in my CloudShell2 had no issue without any quirk option.

Zitat von tkaiser

And this should be related to another USB quirk in kernel? Clearly not, right?

The above patch was meant to be tested against Seagate enclosures (ASM1153 with 'branded' firmware). Unfortunately zero feedback here.

I have no idea indeed. I used a JMS578 bridge and a 5TB Seagate 2.5inch HDD as I described in previous post.
I didn't add any USB quirk option in the kernel parameter since many people mentioned the JMS578 is very compatible with Linux.

By the way, I could reproduce the issue with "mkfs.ext4 -b 4096 -m 0 -E lazy_itable_init=0,lazy_journal_init=0 /dev/sda1" command on Armbian too.
If I removed " -E lazy_itable_init=0,lazy_journal_init=0", the format process completed without any error.
The command seems to be identical to the OMV "Create File System" function.

Did you have any problem while you use "Create File System" menu with your Rock64 + ASM1153 + Hitachi HDD ?

Thank you for the new kernel package. I've successfully updated the kernel. Kernel version has been changed to 4.9.37 from 4.9.33.
My CloudShell2(JMS561) has no issue with the new kernel as well as the previous kernel while running "Create File System" (my previous report).

But "Create File System" crashes another XU4 that works with the JMS578 + 5TB HDD within a few seconds.
With newer kernel, there was no "Ring expansion failed" but the SSH has no response at all. The blue LED turned off and rebooted in 1~2 minutes automatically.

I will stop digging the uas things and disable it until my rock64 arrives in few weeks. I'm very curious how the rock64 can manage the various uas chipset issues.
But I don't know why I've been so interested in the uas things since my HDD Samba performance is not so influenced by the uas feature.

Do you mean this patch? if yes, I will try it tonight.
http://www.spinics.net/lists/kernel/msg1912802.html

It's me again.
I played with a 2.5" 5TB HDD which was extracted from the Seagate Backup-plus box because it is not compatible with Linux UAS driver.
Seagate Baraccuda 5TB HDD is around $200 while the Backup Plus is only $140. So I could save $60 easily.
Yes, the Backup Plus box has the same Baraccuda 5TB HDD.

Anyway, I found a small sata-usb adapter board which has JMS578 chip on ebay. It really worked well with the UAS driver in XU4 for a few days.
I could upload and download over 3TB files without single bit error with stable 100MB/s speed over Samba.
Last night, I just wanted to clean the disk with a format option in the OMV "file systems" menu.
It started to wipe and format. But several seconds later, there was a popup of "communication failure".
I connected to SSH and "dmesg" showed tons of "Ring expansion failed" like followings.

[ 1904.773710] xhci-hcd xhci-hcd.2.auto: Ring expansion failed
[ 1904.773731] sd 0:0:0:0: [sda] tag#19 data out submit err -12 uas-tag 19 inflight: s-out a-cmd s-cmd work 
[ 1904.773736] sd 0:0:0:0: [sda] tag#19 CDB: opcode=0x2a 2a 00 4c 00 d9 00 00 04 00 00
[ 1904.774153] xhci-hcd xhci-hcd.2.auto: Ring expansion failed
[ 1904.774179] sd 0:0:0:0: [sda] tag#7 data out submit err -12 uas-tag 20 inflight: s-out a-cmd s-cmd work 
[ 1904.774184] sd 0:0:0:0: [sda] tag#7 CDB: opcode=0x2a 2a 00 4c 00 dd 00 00 04 00 00
[ 1904.774582] xhci-hcd xhci-hcd.2.auto: Ring expansion failed
[ 1904.774604] sd 0:0:0:0: [sda] tag#20 data out submit err -12 uas-tag 21 inflight: s-out a-cmd s-cmd work 
[ 1904.774610] sd 0:0:0:0: [sda] tag#20 CDB: opcode=0x2a 2a 00 4c 00 e1 00 00 04 00 00
[ 1904.775005] xhci-hcd xhci-hcd.2.auto: Ring expansion failed
[ 1904.775026] sd 0:0:0:0: [sda] tag#21 data out submit err -12 uas-tag 22 inflight: s-out a-cmd s-cmd work 
[ 1904.775037] sd 0:0:0:0: [sda] tag#21 CDB: opcode=0x2a 2a 00 4c 00 e9 00 00 04 00 00
[ 1904.775434] xhci-hcd xhci-hcd.2.auto: Ring expansion failed
[ 1904.775455] sd 0:0:0:0: [sda] tag#22 data out submit err -12 uas-tag 23 inflight: s-out a-cmd s-cmd work 
[ 1904.775461] sd 0:0:0:0: [sda] tag#22 CDB: opcode=0x2a 2a 00 4c 00 ed 00 00 04 00 00
[ 1904.775861] xhci-hcd xhci-hcd.2.auto: Ring expansion failed
[ 1904.775884] sd 0:0:0:0: [sda] tag#23 data out submit err -12 uas-tag 24 inflight: s-out a-cmd s-cmd work 
[ 1904.775889] sd 0:0:0:0: [sda] tag#23 CDB: opcode=0x2a 2a 00 4d 00 6d 00 00 04 00 00
[ 1904.776285] xhci-hcd xhci-hcd.2.auto: Ring expansion failed
[ 1904.776305] sd 0:0:0:0: [sda] tag#25 data out submit err -12 uas-tag 25 inflight: s-out a-cmd s-cmd work 
[ 1904.776311] sd 0:0:0:0: [sda] tag#25 CDB: opcode=0x2a 2a 00 4d 00 75 00 00 04 00 00
[ 1904.776705] xhci-hcd xhci-hcd.2.auto: Ring expansion failed
[ 1904.776725] sd 0:0:0:0: [sda] tag#26 data out submit err -12 uas-tag 26 inflight: s-out a-cmd s-cmd work 
[ 1904.776736] sd 0:0:0:0: [sda] tag#26 CDB: opcode=0x2a 2a 00 4d 00 79 00 00 04 00 00

It seems to be related to the UAS things. So I disabled it and I could successfully format the disk. I can access the Samba again.
The actual read/write speed over Samba has no big difference even I turn the UAS driver off. It is still over 100MB/sec.
But I just turned the UAS on again for better feeling. It still works stably.

I just want to share what I met last night and how I could overcome the nightmare.
Thread based OMV disk formatting routine seems to send a tons of sequential UAS commands and the bad UAS or USB driver in XU4 kernel might make the disk be crazy.
If anybody knows a real root cause of the "Ring expansion failure" problem, please let me know.

"Changing to 5.2V from 5.0V" seems to be very important key fact for many other ARM SBC as an HDD-NAS solution.
I hope we can see a new SBC which contains a good powerful SATA port and stable HDD power supply circuit soon as you suggested.

Great! Appreciate your valuable tests.
My XU4 CPU temperature is near 75°C with similar NAS performance.

BTW, your HDD seems to be much faster than mine. My 5TB is 5400rpm while yours is 7200rpm.
Stupid Seagate also broke the UAS compatibility against Linux.
I have to invest more time to search a Linux friendly enclosure this weekend before Rock64 arrives here.

I tried the the first iozone command several times. There was no error at all. So the USB cable comes with the Seagate 5TB HDD box seems to have very low resistance.

Anyway, RK3328 development progress is very impressive. :o
I hope somebody can show me the LanTest numbers with an HDD instead of the ideal SSD.

Great explanation for my dumb brain.
I want to try the same iozone test.
Please share a full iozone parameters for the heavy disk access test.

It is really hard to find a reliable seller who sells a real Linux UAS compatible enclosure on ebay/amazon.
Time to forget the perfect UAS compatibility in the ARM & x86 Linux world for a while.
I can live without UAS since I still have around 90MB/sec Samba performance with XU4. Let's see how it can be improved with Rock64.

Anyway, my Seagate 5TB has worked very stably with XU4 for a couple of weeks without extra power cable.
When I looked into the XU4 schematics, they used 2Amp load switch on the USB 3.0 power rail. So it is very reasonable.
If I ran a very heavy load like transcoding on all 8-cores at 2Ghz, the peak current could be over 3Amp. So I must use a 6Amp power supply because the HDD in-rush current could be over 1Amp.
Another Toshiba 2TB external HDD and the problematic Seagate 5TB could work together thanks to the 6Amp PSU.

Do you know the maximum clock of the Rock64 CPU and the spec of the load switch on the USB 3.0 port?
If it is too much out of topic, I can wait until I receive it in August or September.

Thank you for the link.
Is it worth to try usb-storage quirks=0x0bc2:2322:t (US_FL_NO_ATA_1X) option with my Linux PC which runs Kernel 4.4?

Too bad~~.
I thought ROCK64 or other kernel update can solve my issue. But there is nothing to do with Linux at this moment probably.
That storage works well on my Windows10 PC in UAS mode.
Sadly there is no hope Microsoft opens their UAS driver source code for Linux users.

I will open the case to extract the 5TB HDD.
Can you recommend a 2.5" disk enclosure which works with Linux UAS driver?

Zitat von tkaiser

UAS vs. Mass Storage is really not that important if we're talking about typical NAS use cases especially with rather slow HDDs.

Most people are typical NAS users like me. My 3.5" WD 4TB RED NAS HDDs are also very slow too.
So I can live without UAS since I can't build a NAS with very expensive SSDs.

But can you find any possible way to enable the UAS for my poor 2.5" 5TB Seagate HDD on ROCK64 kernel or XU4 kernel?
Its USB ID is 0bc2:2322 Seagate RSS LLC.
I hope the ROCK64 comes with a newer kernel 4.12 or higher.

Thank you for the detail explanation. So my current 100MB/s of Samba speed will be 50MB/s once my sister fills it with 5TB files in 4~5 years later.

My Seagate 2.5" 5TB and 3.5" 4TB Desktop Expansion HDDs are not Linux friendly either. My Mint x86 PC shows this message.

UAS is blacklisted for this device, using usb-storage instead

But I still get sufficient 100MB/s of Samba speed with those external HDDs.
I believed the UAS is not so important for NAS application if we don't have 10Gbit infrastructure. But I was totally wrong.

Anyway, I hope you guys can fix the issue in RK3328 kernel soon because I just ordered two ROCK64 boards.
I guess ROCK64 is rock solid and its Samba performance is better than my XU4 because ROCK64 kernel must fix my shitty UAS compatibility issue soon.

Thank you for the help. I modified both two files and the max clock is limited at 1.5Ghz after reboot.
It reduces the power consumption and the heat obviously. The fan is running very rarely now.
Anyway, the Samba speed is still impressive even with a quite slow 2.5inch 5TB HDD.
The performance is very similar to my CloudShell2. But I have to build a tiny 2.5" NAS for my sister.

This is the test result with the 2.5" HDD. So the random access speed is very slow.

BTW, I hope the ROCK64 also can be a very affordable NAS solution for the low-power consumption 2.5" HDDs.
Do you have a 2.5" HDD to test the ROCK64 NAS performance?

I want to lower than maximum clock of the A15 big cores to lower the power consumption.
I already tried to change /sys/devices/system/cpu/cpu4/cpufreq/scaling_max_freq to 1.5GHz from 2Ghz and the CIFS download speed is still over 100MB/s with Seagate 2.5inch external 5TB HDD.
Please let me know which file I need to edit in the XU4 OMV rootfs to change the max clock permanently.

try this if you have xu4 not c4.
https://forum.odroid.com/viewtopic.php?f=53&t=6173