on a Debian 8 installation without those packages installed (or do an 'apt purge' before) and share some insights which drawbacks installation has on XU3/XU4 that are not connected to Cloudshell? I would like to make this part of OMV default installation then.

Thank you for the update. I also tried the latest image last night but I couldn't use it due to missing storage auto mounting function.My friend already reported the issue on your OMV dev thread.BTW, kyle1117 is a Hardkernel member but he might not be able to access this forum due to frequent biz trips.

I have a couple of questions about the "Last OMV image" Do you mean the OMV team will not support ODROID-XU4 anymore?Or Armbian team will not support XU4 anymore?Or you won't ?I didn't hear any official notice from ryecoaaron.

The issue you observe seems to be related to Cloudshell 2 doing something unusual, please check output of 'smartctl -a /dev/sda' and if in doubt provide output from 'armbianmonitor -u' (standard Armbian support procedure). Looks like this for example: http://sprunge.us/MRMd

/srv/dev-disk-by-id-ata-Samsung_SSD_840_EVO_120GB_S1D5NSBDA33799H-part1 is what OMV is using and this is obviously constructed from drive's model name and serial:

Seems you either need to fix that on the Cloudshell or submit a PR to OMV to change this behaviour (doing a fallback to whatever -- I would use PARTUUID here for obvious reasons -- in case SMART data isn't available. Well, (not so) surprisingly we're back at page 1 of this thread now: https://forum.odroid.com/viewtopic.php?f=146&t=26016#p186466

- explore potential XU3/XU4 USB3 host controller issues (the quirk Hans de Goede was talking about)- provide I2C detection mechanism for 1st Cloudshell- move Cloudshell support stuff in a somewhat official repo so packages can be installed/updated from there

Appreciate your consideration.1. I fully agree we need to improve the USB 3.0 drivers for better USB storge compatibility. We will install the same 4.9 kernel on host PCs to compare the UASP troubles to narrow down the root causes since our host PCs still run slightly old Kernel 4.1 LTS.

2. Unfortunately, the 1st CloudShell had no I2C device on the controller board. Fortunately, even we install the three packages into old CloudShell, there is no negative side effect and LCD worked well.So your current solution should be fine.

3. After some bug fix, we will move those script source codes & packages to Hardkernel official repos within two weeks.

In the meantime it's confirmed that it's not related to 'ID' but to Cloudshell 2 providing a random/nonsense drive serial. This might be fixable but IMO the OMV method relying on disk model/serial should better be replaced (as already said I would use PARTUUID for this and the fix should be part of OMV 3.0.76).

Then when trying to explore USB3 host controller issues please keep in mind that PCs can also use (partially) broken host controllers. At one of my customers IT staff had to remove USB3 controller cards (IIRC NEC/Renesas) in a few hundred PCs since not even firmware updates helped there avoiding BSOD when accessing certain storage media.

So if I understood correctly then all three packages (odroid-cloudshell cloudshell-lcd cloudshell2-fan) are also needed/desirable on 1st Cloudshell and there are no drawbacks installing these packages on XU3/XU4 without a Cloudshell connected (unnecessary background activity for example since scripts fail to access hardware)? If all three packages are necessary and cause no harm on ODROIDs without Cloudshell attached then I2C detection method has to be removed and cloudshell-lcd package installed everywhere.

I'll look into that thread in 3 weeks again and then pick up results. Thanks for your feedback!

10. Push Start buttonIf your CloudShell2 does not show, then you should remove the USB cable to Host PC and try again.

start.png (40.21 KiB) Viewed 10681 times

You must have a Windows PC because Jmicron firmware tool doesn't support the Linux/Mac. It is ironical since Jmicron seems to be the most Linix compatible UASP bridge vendor.Now OMV works well without painful bad mounting issues.

Around 150~200 pcs of CloudShell2 in early batch could have no USB serial number.We will change our production process to write the serial number today.Sorry for the inconvenience caused for OMV users.

Last edited by lsc1117 on Mon Aug 07, 2017 5:00 pm, edited 2 times in total.

Jmicron doesn't allow manufacturers to distribute the production tool to end customers.So we searched the internet and we tried it and it worked.We installed the same executables on a few windows PC and anti-virus scanning... there is no issue so far.

Since there are many Russian members in this forum, I want to trust "USBDEV.RU" site.

Here is my proposed solution to the serial number issue. It does not require modifying OMV, Debian, or anything else. It works both with CloudShells that have a flashed serial number and those that do not. Simply add the following file:

Its more robust to apply it regardless of serial number. The reason for this is that a serial number binding will fail if the user places the drives in a different CloudShell2. This could happen, for example, in the event of a RMA.

There is no such thing. If users are affected by broken/early Cloudshell 2 devices, this gets detected (searching for 'RANDOM' as part of the serial number) and if that's the case the udev rule is applied until the user manually removes it (so even in an RMA case when the user gets a fixed Cloudshell it's unfortunately still active).

The user sets up OMV with CloudShell2 that has a serial number. Without the udev rule, the binding is something like (example only, not exact) "/dev/disk/by-id/usb-JMicron_12345-0".

The user then moves the drives (and sd/emmc) to a different CloudShell2 that also has a serial number. The fstab entry still points to "/dev/disk/by-id/usb-JMicron_12345-0"; however; the serial number is now different: "/dev/disk/by-id/usb-JMicron_67890-0". The fstab entry (binding) fails. The user must wait 1m 30s for timeout. The user must them unmount the old entry and mount the new entry.

Always using the udev entry alleviates this problem by producing consistent fstab entries:/dev/disk/by-id/usb-CloudShell2-0/dev/disk/by-id/usb-CloudShell2-1

OMG, always such a waste of time visiting vendor forums. The contents of /etc/udev/rules.d/99-cloudshell2.rules are defined on first boot and remain the same since then. It doesn't matter if the user in question changes his Cloudshell 2 devices then daily or not, whether these have random or fixed serial numbers since once /etc/udev/rules.d/99-cloudshell2.rules is in place exactly that behaviour happens that you try to describe.

Only difference: this will only be applied on installations where a Cloudshell 2 is connected showing the 'random serial' flaw at first boot.

It's part of latest official OMV image now (but the persistent udev rule gets only installed if Cloudshell 2 is connected at first boot). By looking at the stuff from kyle1117 PPA it's obvious that there are some fixes needed:

1) /bin/cloudshell-lcd script is insanely inefficient, causes the A15 cores to run at 2000 MHz instead of 600 MHz even when totally idle which leads to an average temperature increase of a whopping 8°C -- I didn't measured the consumption increase but we all know what 8°C more mean consumption wise. Though Hardkernel seems to not care about such stuff like unnecessarily increased consumption and heat, right? https://github.com/hardkernel/linux/com ... t-22211715

(OMV uses ondemand with the appropriate tweaks for identical performance as performance governor but way less consumption/heat in idle)

Anyway: Even if you disable in /bin/cloudshell-lcd all those useless checks every second I think it would be a good idea to assign the script to the little cores only (use taskset for example in service defintion)

2) ads7846 module should obviously be blacklisted on Cloudshell 2 installations. Please add this as part of updating PPA contents

3) When you moved the fixed stuff over to Hardkernel repo please provide a guide somewhere teaching users how to adjust stuff below /etc/apt/sources.d to get further cloudshell updates from your official repo. But please take care that the fixes from 1) and 2) are available at ppa:kyle1117/ppa soon and that this PPA remains where it is at least for some weeks (since then all affected users should get the fixes from there)

<1> I fully agree that script must be updated to reduce the CPU usage.We will fix it early next week and update kyle1117's packages. Please give us 2~3 days since here Korea is already Saturday evening.

<2> ads7846 driver seems to be badly coupled with SPI drivers. We will add it in the blacklist file via CloudShell2 package updates.

<3> Moving repo still needs a couple of more weeks. We will inform you when they are ready to move.

@tkaiser - using ondemand in my experience results in slower DE (with Gnome and Enligtenment, ondemand was crawling and EGL/GLES apps had 1/2 fps vs performance gov)so i think having performance default gov is the right choice, since most XU4 users want it for performance; individual OS images can of course choose a different governor, based on their intended use-case...

Ah, ok. That explains the switch to performance perfectly and is most probably also the root cause why the low cloudshell-lcd script efficiency isn't already fixed (since when using performance governor running cloudshell-lcd script or not won't make any real difference unlike with ondemand). BTW: I was pretty excited about new schedutil governor (available since 4.7 IIRC?) but seems not ready at least on ARM (with Armbian we switched back to ondemand on every platform in the meantime).

For NAS use case ondemand with few tweaks seems still to be the best choice to get both best performance and lowest idle consumption and wrt everything desktop related I've no clue anyway so appreciate the details above.

Thanks for explanation/update (also to the others -- @odroid take your time please)!

Totally unrelated to UAS but Cloudshell 2 and disk monitoring as part of cloudshell-lcd script instead:

- doing a SMART query every second will prevent the disks from spinning down forever, it will even prevent the disk entering some low power modes (not all disks implement this)- temperature changes inside disks happen very slowly so checking this every 60 seconds only is totally ok- if you want to allow disks to spin down check their status prior to smartctl call: https://github.com/armbian/build/blob/m ... onitor#L67 (if they're in standby/sleeping state simply use 0 as value). There exists a 'hddtemp' package which is known to not wake up sleeping disks but unfortunatenyl this is unmaintained since years and most modern drivers are missing from its drive database- grepping for 'Temp' string won't work with every disk out there (since some provide two SMART attributes with this string in it, eg. Seagate and Samsung HDDs -- but not SSD -- use 190 and 194 with the former being the more interesting readout): http://sprunge.us/QCSU (starting from https://forum.armbian.com/index.php?/to ... e/&page=11 you find a lot more SMART dumps for various disks searching for 'sprunge')

My personal opinion is that displaying actual values is mostly useless if the purpose is monitoring and not just displaying fancy data. It's somewhat about the difference between data (some numbers) and information (what do the numbers mean? Do I need to care about them?). HDD thermal data should include temperature peaks too: see attribute 190 for Seagate/Samsung HDD or better check output of 'smartctl -l scttemp' or 'smartctl -x' (most modern drives monitor internally temperature history with timestamps and store up to 128 records).

And then there are two other SMART attributes that are really useful and worth monitoring:

- 199: CRC counter, if this number increases then there's something wrong with cabling/connectors. The primitive CRC checks allows for detection of most such cases and then ATA protocol triggers a data retransmit (responsible for noticable performance drops). But in rare occassions corrupted data can generate a valid checksum and then silent data corruption happened. That's why 199 is a mandatory monitoring source- 193: Load Cycle Count (google for 'wd lcc issue'). Mostly WD HDDs are affected since their heads are parked by default after just 8 seconds inactivity and sometimes situations occur where after another few seconds the heads are unramped again. LCC limits look rather high (IIRC 600,000 by specs with modern drives) but this should also be monitored since if this count increases fast then users should explore how to for fix this (using wdidle3, idle3ctl or eg. 'hdparm -B 254 ' for Samsung/Seagate)

Edit: Just remembered that calling update-smart-drivedb once would be useful (grabbing latest smartmontools device database from the net), I'll add this to future OMV installations. And then I also forgot that I've written some script code to dynamically update hddtemp.db: https://github.com/armbian/build/blob/m ... #L427-L454

When adopting this and adding hddtemp package to cloudshell-lcd dependencies then simply using 'hddtemp -n' is the most convenient way to allow spin-down and deal with sleeping disks:

And another important piece of information worth to be displayed on the LCD: Is a firmware update available? https://github.com/armbian/build/blob/m ... nitor#L457 (at least for SSDs this can be a life saver if firmware contains ugly bugs, with HDDs it's not that important)

Last edited by tkaiser on Sun May 21, 2017 4:17 pm, edited 2 times in total.

193: Load Cycle Count (google for 'wd lcc issue'). Mostly WD HDDs are affected since their heads are parked by default after just 8 seconds inactivity and sometimes situations occur where after another few seconds the heads are unramped again. LCC limits look rather high (IIRC 600,000 by specs with modern drives) but this should also be monitored since if this count increases fast then users should explore how to for fix this (using wdidle3, idle3ctl or eg. 'hdparm -B 254 ' for Samsung/Seagate)

My 3TB WD green HDD reached about 1.800.000 for this counter while operating inside the WD MyBook NAS. I turned off this "feature" after 3-4 years when I moved the disk to a XU4.

Also I don't know why you don't list ASM1153 above? It's just Seagate disk enclosures relying on same bridge chip but combining it with a crippled/broken firmware that causes troubles.

Thank you for the test report.Because nobody reported about ASM1153 compatibility, I couldn't add it in the list.BTW, it seems to be around 25% faster than Jmicron USB 3.0 SATA bridges.I've ordered an HDD enclosure which claims it has ASM1153. I will test it Wednesday or Thursday probably and share the test result.

This sort of tests can't be done with HDDs or small SSDs, it needs large SSDs (the higher the capacity the more parallelism inside, the higher throughput numbers even with large test filesizes) and the units need to be tested on a native SATA port before to know when the SSD starts to bottleneck in which area. Both JMS567 and ASM1153 allow sequential transfer speeds of up to 400 MB/s with UAS and large blocksizes so it gets more interesting to test through situations with many small files and random IO patterns (how do the USB-to-SATA bridges deal with the drive's NCQ capabilities and expose this through UAS?)

The mandatory dmesg check for errors showed zero and this is the 3rd run (you never run just a single benchmark, this has to be repeated at least 3 times to get an idea whether your numbers are consistent or something went wrong).

We can draw 4 conclusions:

1) XU4 USB3 receptacles are problematic, exchange of a cable made the difference between total fail and running into next issue (not UAS related at all)

2) host powered disks might fail (somewhat UAS related since UAS is way more efficient than the old Mass Storage mode and power requirements are simply higher when running demanding loads, that's real storage benchmarks like iozone or fio not insufficent stuff like hdparm or dd)

3) The average user will blame not the hardware but UAS and 'instable drivers/situation' (at least software) for both 1) and 2)

4) ASM1153 seems to be slightly faster than JMS567 above when combined with the USB3 host controller in XU4's Exynos. I'm writing 'seems' since this needs confirmation with at least 2 different other SSDs but I neither have some spare SSDs around known to exceed 450 MB/s in all situations (that's the requirement when you want to test for a potential 350 MB/s bridge limitation) nor further time since it's somewhat weird to deal with very fast USB storage anyway here

ASM1153 numbers as a reference for comparison (if you use a Seagate disk enclosure these numbers aren't for you, Seagate uses also ASM1153 but f*cked up the firmware):

We should probably post a sticky of Linux compatible UAS controllers. Maybe someday they will fix the broken Linux UAS drivers and the devices will work as good as they do on commercial operating systems like Windows and MacOS.

Interesting reaction to the posts above where real problems are listed.

Wrt 'broken Linux UAS drivers' your opinion as well as your testing methodology [1] is absolutely amazing and funny. I still hope @odroid will start to investigate Exynos host controller issues since that's the only way to get UAS with XU3/XU4 a bit less of the mess it currently is (partially related to mislead user expectations). An important area of improvement is clearly documentation (eg. check contacts: 'if an USB cable doesn't fit tightly in XU4 USB3 receptacles you can expect troubles', check for underpowering)

[1] viewtopic.php?f=146&t=26016&start=50#p188246 (made with a host powered Seagate thingie connected to a PC with unknown host controller and showing similar symptoms as my underpowered external JMS567 above). This is the proof that Linux UAS drivers are broken in general and everywhere and guys like Hans de Goede that know better and were trying to help are just lamers. Dealing with (certain members of) micro communities is always so refreshing. BTW: that was my last post here since it's such an insane waste of time coping with vendor forums.

tkaiser wrote:BTW: that was my last post here since it's such an insane waste of time coping with vendor forums.

Isn't that the 3rd or 4th "last post" here?

i wish community members won't fight like this on the forums. especially since it's over something so childish i am eager to see both @crashiverride's developments on mali, and @tkaiser's experience with NAS, and any loss would be sad (esp since i don't read armbian forums, can't afford to read too many forums )

In any society, disagreements are inevitable. Its how we deal with them and work to resolve them that makes the difference.

Armbian is a build system for "something Pi" boards where this is no vendor leadership and limited community participation. Odroid boards, by contrast, have constant vendor participation and an active community. Its unreasonable to suggest that "Armbian" (@tkaiser) can insult our community, insult our hardware, and insult our vendor while expecting everyone to "get along".

Regardless of personal feelings, the observations and experiments regarding UAS+Linux have been openly and publicly discussed. When Armbian begins testing other USB3+UAS boards, they will inevitably see the same issues. The issues are reproducible on any hardware (including x86) as demonstrated in this thread. However, what we will not see is a retraction in all the forum posts (here and elsewhere) where @tkaiser has called XU4 and its community "a waste of time".

Add me to the list that's also having issues with 4.9.y and UASI had to turn off UAS through the usb-storage.quirks in boot.ini as the system was very unstable and would crash whenever smart monitoring was enabled or when anything was written to the disks through for example samba.

How are you guys updating the kernel on these new OMV (Armbian based) images? I flashed the one with kernel 4.9.23 yesterday because it did not boot without ethernet connected. I would want to update the kernel now.