Getting UAS working on HK 4.9

Test and fix the Kernel 4.9 features

Moderators: mdrjr, odroid

Re: Getting UAS working on HK 4.9

Unread postby odroid » Thu May 11, 2017 9:07 am

linuxest wrote: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 what USB-SATA bridge chipsets support the UASP on XU4 Kernel 4.9?


I think you can report the OMV image related issues on this thread.
http://forum.openmediavault.org/index.p ... /?pageNo=1

Confirmed chipsets are very limited at this moment. Firmware revision in the chipset seems to affect the compatibility though.
ASM1053E
JMS567
JMS561
User avatar
odroid
Site Admin
 
Posts: 24345
Joined: Fri Feb 22, 2013 11:14 pm
languages_spoken: English
ODROIDs: ODROID

Re: Getting UAS working on HK 4.9

Unread postby rooted » Thu May 11, 2017 11:37 am

My two bay USB dock is a bit problematic, it's JMS56x (can't find out the x).
User avatar
rooted
 
Posts: 3653
Joined: Fri Dec 19, 2014 9:12 am
Location: Gulf of Mexico, US
languages_spoken: english
ODROIDs: C1
C1+
C2
XU3 Lite
XU4
VU7+
HiFi Shield 2
Smart Power (original)

Re: Getting UAS working on HK 4.9

Unread postby rncwnd » Thu May 11, 2017 4:37 pm

rooted wrote:My two bay USB dock is a bit problematic, it's JMS56x (can't find out the x).


You could try if running
Code: Select all
update-usbids

before running
Code: Select all
lsusb -v

gets more / more recent infos for your device(s).
rncwnd
 
Posts: 22
Joined: Tue Apr 11, 2017 11:18 pm
languages_spoken: english, german
ODROIDs: XU4

Re: Getting UAS working on HK 4.9

Unread postby odroid » Thu May 11, 2017 7:23 pm

odroid wrote:
linuxest wrote: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 what USB-SATA bridge chipsets support the UASP on XU4 Kernel 4.9?


I think you can report the OMV image related issues on this thread.
http://forum.openmediavault.org/index.p ... /?pageNo=1


The fbtft driver exists in OMV Kernel in OMV_3_0_71_Odroidxu4_4.9.23.7z image.
If you follow this instruction, you will see very similar image on CloudShell2 TFT-LCD.
http://odroid.com/dokuwiki/doku.php?id= ... dshell_omv
cs2_lcd.png
cs2_lcd.png (2.2 KiB) Viewed 3271 times
User avatar
odroid
Site Admin
 
Posts: 24345
Joined: Fri Feb 22, 2013 11:14 pm
languages_spoken: English
ODROIDs: ODROID

Re: Getting UAS working on HK 4.9

Unread postby tkaiser » Fri May 12, 2017 6:46 pm

Can anyone please try out
Code: Select all
sudo add-apt-repository ppa:kyle1117/ppa
sudo apt-get update
sudo apt install cloudshell-lcd cloudshell2-fan odroid-cloudshell

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.

Edit: And if anyone of you with physical access to both Cloudshells can come up with an I2C based detection method/routine it would be great. Background info: http://forum.openmediavault.org/index.php/Thread/17855-Building-OMV-automatically-for-a-bunch-of-different-ARM-dev-boards/?postID=143735#post143735
tkaiser
 
Posts: 94
Joined: Mon Nov 09, 2015 12:30 am
languages_spoken: english
ODROIDs: C1+, C2, XU4, HC1

Re: Getting UAS working on HK 4.9

Unread postby tkaiser » Tue May 16, 2017 3:49 pm

Great 'support' here. I released one last OMV image now that supports this Cloudshell 2 thingie out of the box and won't care any more from now on. Details: http://forum.openmediavault.org/index.php/Thread/17855-Building-OMV-automatically-for-a-bunch-of-different-ARM-dev-boards/?postID=144009#post144009

Updates enabled for
- 4.9 kernel from Armbian repo
- Jessie from official Debian repo
- OMV and OMV extras from official OMV repos
- Cloudshell 2 from this kyle1117 PPA I don't know who's behind since questions here aren't answered
tkaiser
 
Posts: 94
Joined: Mon Nov 09, 2015 12:30 am
languages_spoken: english
ODROIDs: C1+, C2, XU4, HC1

Re: Getting UAS working on HK 4.9

Unread postby odroid » Tue May 16, 2017 5:47 pm

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.
User avatar
odroid
Site Admin
 
Posts: 24345
Joined: Fri Feb 22, 2013 11:14 pm
languages_spoken: English
ODROIDs: ODROID

Re: Getting UAS working on HK 4.9

Unread postby tkaiser » Tue May 16, 2017 6:56 pm

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:
Code: Select all
root@odroidxu4:~# smartctl -a /dev/sda
smartctl 6.4 2014-10-07 r4002 [armv7l-linux-4.9.27-odroidxu4] (local build)
Copyright (C) 2002-14, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family:     Samsung based SSDs
Device Model:     Samsung SSD 840 EVO 120GB
Serial Number:    S1D5NSBDA33799H


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

Both Armbian and OMV will continue to support XU4 (including updates on a regular basis or if necessary -- security fixes) but me personally won't any more since enough work done / time wasted. Which doesn't matter that much since working 'Armbian style' nothing will ever be lost since the whole work spent on OMV optimization is now contained in Armbian's build system and available to everyone: https://github.com/armbian/build/blob/f175e28d30e3ed39881c00c9d7671995b78f0647/scripts/customize-image.sh.template#L31-L168 :)

That being said it would be great if you would start to

- 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
tkaiser
 
Posts: 94
Joined: Mon Nov 09, 2015 12:30 am
languages_spoken: english
ODROIDs: C1+, C2, XU4, HC1

Re: Getting UAS working on HK 4.9

Unread postby odroid » Tue May 16, 2017 7:29 pm

I will check the disk-id issue with my friend.

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.
User avatar
odroid
Site Admin
 
Posts: 24345
Joined: Fri Feb 22, 2013 11:14 pm
languages_spoken: English
ODROIDs: ODROID

Re: Getting UAS working on HK 4.9

Unread postby tkaiser » Tue May 16, 2017 7:53 pm

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! :)
tkaiser
 
Posts: 94
Joined: Mon Nov 09, 2015 12:30 am
languages_spoken: english
ODROIDs: C1+, C2, XU4, HC1

Re: Getting UAS working on HK 4.9

Unread postby odroid » Tue May 16, 2017 8:08 pm

I hope there can be a good OMV solution over the bad random disk ID. :oops:

Possible drawbacks are 160KB RAM for the small LCD framebuffer driver and 0.8~0.9% of CPU load.
We will check other negative side effects too.
User avatar
odroid
Site Admin
 
Posts: 24345
Joined: Fri Feb 22, 2013 11:14 pm
languages_spoken: English
ODROIDs: ODROID

Re: Getting UAS working on HK 4.9

Unread postby crashoverride » Wed May 17, 2017 5:43 am

odroid wrote:I hope there can be a good OMV solution over the bad random disk ID.

None of the issues are insurmountable. However, it requires the participation of those that are not openly hostile towards the Odroid community and hardware as @tkaiser is.

I recommend we focus our OMV efforts on @meveric 's minimal Debian Jessie installation. I would be happy to contribute whatever I can to the effort.
crashoverride
 
Posts: 3060
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1

Re: Getting UAS working on HK 4.9

Unread postby odroid » Wed May 17, 2017 8:16 am

Even @tkaiser proposed the UUID workaround to OMV team, one of key OMV developers gave us a negative answer.
http://forum.openmediavault.org/index.p ... post144110
Modifying the OMV source codes is not a good solution since it will be some hurdles for future upgrades. I

Therefore we will contact Jmicron to request a possible firmware update to make the two RANDOM IDs to fixed IDs.
User avatar
odroid
Site Admin
 
Posts: 24345
Joined: Fri Feb 22, 2013 11:14 pm
languages_spoken: English
ODROIDs: ODROID

Re: Getting UAS working on HK 4.9

Unread postby crashoverride » Wed May 17, 2017 9:13 am

odroid wrote:Modifying the OMV source codes is not a good solution since it will be some hurdles for future upgrades. I

My planned solution is far simpler. ;) I will look at getting an OMV image up and running to verify some experiments.
crashoverride
 
Posts: 3060
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1

Re: Getting UAS working on HK 4.9

Unread postby lsc1117 » Wed May 17, 2017 3:55 pm

Sorry. We missed writing a serial number to the CloudShell2

To write the serial number you have to follow below steps.

1. Connect your HDDs to CloudShell2 first.
2. Connet a power cable to CloudShell2.
3. Connect your CloudShell2 to a Windows PC via USB cables( a longer micro USB 2.0 could be fine like this picture)

writing_serial.jpg
writing_serial.jpg (113.25 KiB) Viewed 3058 times


4. Download the writing utility for windows.
Direct Link : https://dn.odroid.com/cs2/JMMassProd2_v1_16_14_34.zip

5. Extract the file.

6. Download this INI file into the same utility directory.
CloudShell2.ini
(2.77 KiB) Downloaded 48 times


7. Run JMMassProd2_v1_16_14_1.exe file.

8. Load the Cloudshell2.ini file.

load_ini.png
load_ini.png (31.25 KiB) Viewed 3058 times


9. Check RD Version with a password.
pw:jmicron

check_RDVersion.png
check_RDVersion.png (43.86 KiB) Viewed 3058 times


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

start.png
start.png (40.21 KiB) Viewed 3058 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.
lsc1117
 
Posts: 44
Joined: Thu Aug 22, 2013 12:46 am
Location: South Korea
languages_spoken: english

Re: Getting UAS working on HK 4.9

Unread postby crashoverride » Thu May 18, 2017 2:07 am

lsc1117 wrote:4. Download the writing utility for windows. We found it via googling.
http://www.usbdev.ru/files/jmicron/ : find "JMicron 2033x M.P. Tool v1.16.14.1".

Its a really bad time to ask those in the USA to download and run programs off the internet from a Russian server. :lol:

Are the executables at least digitally signed?
crashoverride
 
Posts: 3060
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1

Re: Getting UAS working on HK 4.9

Unread postby odroid » Thu May 18, 2017 8:55 am

Yes! Political and DDoS issues at the same time~~ really bad time.

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. ;)
User avatar
odroid
Site Admin
 
Posts: 24345
Joined: Fri Feb 22, 2013 11:14 pm
languages_spoken: English
ODROIDs: ODROID

Re: Getting UAS working on HK 4.9

Unread postby crashoverride » Thu May 18, 2017 1:06 pm

crashoverride wrote:My planned solution is far simpler.

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:
Code: Select all
vi /etc/udev/rules.d/99-cloudshell2.rules

Code: Select all
# Odroid CloudShell2
ATTRS{idVendor}=="152d", ATTRS{idProduct}=="0561", KERNEL=="sd*", ENV{DEVTYPE}=="disk", SYMLINK="disk/by-id/$env{ID_BUS}-CloudShell2-$env{ID_MODEL}"
ATTRS{idVendor}=="152d", ATTRS{idProduct}=="0561", KERNEL=="sd*", ENV{DEVTYPE}=="partition", SYMLINK="disk/by-id/$env{ID_BUS}-CloudShell2-$env{ID_MODEL}-part%n"


This will enumerate CloudShell2 drives as:
Code: Select all
/dev/disk/by-id/usb-CloudShell2-0
/dev/disk/by-id/usb-CloudShell2-1

There will be additional entries per partition:
Code: Select all
/dev/disk/by-id/usb-CloudShell2-0-part1
/dev/disk/by-id/usb-CloudShell2-1-part1


For those testing it, please report your findings.

[edit]
Corrected typo in second entry.
crashoverride
 
Posts: 3060
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1

Re: Getting UAS working on HK 4.9

Unread postby odroid » Fri May 19, 2017 12:46 pm

We just confirmed @crashoverride solution fixed the CloudShell2 issue on OMV.
Thank you for the nice idea of the simpler solution.

Our office member is replacing our old PC based NAS servers with XU4Q + CloudShell2 + OMV now. :D
Let's see the performance and stability for a couple of weeks.
User avatar
odroid
Site Admin
 
Posts: 24345
Joined: Fri Feb 22, 2013 11:14 pm
languages_spoken: English
ODROIDs: ODROID

Re: Getting UAS working on HK 4.9

Unread postby tkaiser » Fri May 19, 2017 3:25 pm

odroid wrote:We just confirmed @crashoverride solution fixed the CloudShell2 issue on OMV.


I picked up his idea yesterday but udev workaround will be applied only on affected units: http://forum.openmediavault.org/index.p ... post144296

Feedback welcome ASAP since then @ryecoaaron can replace the official OMV image and early Cloudshell 2 adopters can save the hassles.
tkaiser
 
Posts: 94
Joined: Mon Nov 09, 2015 12:30 am
languages_spoken: english
ODROIDs: C1+, C2, XU4, HC1

Re: Getting UAS working on HK 4.9

Unread postby crashoverride » Fri May 19, 2017 4:03 pm

tkaiser wrote:workaround will be applied only on affected units

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.
crashoverride
 
Posts: 3060
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1

Re: Getting UAS working on HK 4.9

Unread postby tkaiser » Fri May 19, 2017 4:26 pm

crashoverride wrote:
tkaiser wrote:workaround will be applied only on affected units

a serial number binding


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

Only remaining issue: Improve/explore Exynos USB3 IP host controller issues and fix it upstream

@rooted: I'll rebuild OMV image now and it should be able to run from eMMC now. Would be great if you can test/comment over at https://github.com/armbian/build/commit ... t-22203795 using the image I'll provide in 30 minutes in openmediavault forum.
tkaiser
 
Posts: 94
Joined: Mon Nov 09, 2015 12:30 am
languages_spoken: english
ODROIDs: C1+, C2, XU4, HC1

Re: Getting UAS working on HK 4.9

Unread postby crashoverride » Fri May 19, 2017 4:41 pm

tkaiser wrote:There is no such thing.

I will try to explain it simpler... :roll:

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
crashoverride
 
Posts: 3060
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1

Re: Getting UAS working on HK 4.9

Unread postby tkaiser » Fri May 19, 2017 5:25 pm

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.
tkaiser
 
Posts: 94
Joined: Mon Nov 09, 2015 12:30 am
languages_spoken: english
ODROIDs: C1+, C2, XU4, HC1

Re: Getting UAS working on HK 4.9

Unread postby crashoverride » Fri May 19, 2017 5:31 pm

As stated before, Armbian can do whatever it wants. I do not use it, so none of its issues affect me.
crashoverride
 
Posts: 3060
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1

Re: Getting UAS working on HK 4.9

Unread postby tkaiser » Sat May 20, 2017 5:16 pm

odroid wrote:We just confirmed @crashoverride solution fixed the CloudShell2 issue on OMV.


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)

Further details: http://forum.openmediavault.org/index.p ... post144401
tkaiser
 
Posts: 94
Joined: Mon Nov 09, 2015 12:30 am
languages_spoken: english
ODROIDs: C1+, C2, XU4, HC1

Re: Getting UAS working on HK 4.9

Unread postby odroid » Sat May 20, 2017 6:11 pm

Thank you for the issue reporting and your effort.

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

Thanks,
User avatar
odroid
Site Admin
 
Posts: 24345
Joined: Fri Feb 22, 2013 11:14 pm
languages_spoken: English
ODROIDs: ODROID

Re: Getting UAS working on HK 4.9

Unread postby memeka » Sat May 20, 2017 6:48 pm

@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...
User avatar
memeka
 
Posts: 3561
Joined: Mon May 20, 2013 10:22 am
languages_spoken: english
ODROIDs: XU rev2 + eMMC + UART
U3 + eMMC + IO Shield + UART

Re: Getting UAS working on HK 4.9

Unread postby mad_ady » Sat May 20, 2017 7:13 pm

@memeka: @tkaiser works on OMV which is a NAS distro. DE is not a priority.
User avatar
mad_ady
 
Posts: 2395
Joined: Wed Jul 15, 2015 5:00 pm
Location: Bucharest, Romania
languages_spoken: english
ODROIDs: XU4, C1+, C2

Re: Getting UAS working on HK 4.9

Unread postby tkaiser » Sat May 20, 2017 7:56 pm

memeka wrote:@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)


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)!
tkaiser
 
Posts: 94
Joined: Mon Nov 09, 2015 12:30 am
languages_spoken: english
ODROIDs: C1+, C2, XU4, HC1

Re: Getting UAS working on HK 4.9

Unread postby tkaiser » Sat May 20, 2017 8:04 pm

odroid wrote:Confirmed chipsets are very limited at this moment. Firmware revision in the chipset seems to affect the compatibility though.
ASM1053E
JMS567
JMS561


BTW: Samsung EVO 840 behind an ASM1153 with your latest kernel 4.9.28, Armbian default settings but without additional tweaks (IO scheduler priority classes and stuff like that) exceeds 340 MB/s with large blocksizes which is IMO rather impressive: https://github.com/armbian/build/commit ... t-22205465 (only quick test due to some regression testing)

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.
tkaiser
 
Posts: 94
Joined: Mon Nov 09, 2015 12:30 am
languages_spoken: english
ODROIDs: C1+, C2, XU4, HC1

Re: Getting UAS working on HK 4.9

Unread postby tkaiser » Sat May 20, 2017 11:20 pm

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:
Code: Select all
root@odroidxu4:~# hddtemp -n /dev/sda 2>/dev/null
root@odroidxu4:~# hddtemp -n /dev/sda
/dev/sda: SAMSUNG HM500JI: drive is sleeping
root@odroidxu4:~# smartctl -a /dev/sda >/dev/null ; hddtemp -n /dev/sda
31


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.
tkaiser
 
Posts: 94
Joined: Mon Nov 09, 2015 12:30 am
languages_spoken: english
ODROIDs: C1+, C2, XU4, HC1

Re: Getting UAS working on HK 4.9

Unread postby mad_ady » Sun May 21, 2017 3:59 am

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.
User avatar
mad_ady
 
Posts: 2395
Joined: Wed Jul 15, 2015 5:00 pm
Location: Bucharest, Romania
languages_spoken: english
ODROIDs: XU4, C1+, C2

Re: Getting UAS working on HK 4.9

Unread postby odroid » Mon May 22, 2017 11:55 am

tkaiser wrote:BTW: Samsung EVO 840 behind an ASM1153 with your latest kernel 4.9.28, Armbian default settings but without additional tweaks (IO scheduler priority classes and stuff like that) exceeds 340 MB/s with large blocksizes which is IMO rather impressive: https://github.com/armbian/build/commit ... t-22205465 (only quick test due to some regression testing)

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.
User avatar
odroid
Site Admin
 
Posts: 24345
Joined: Fri Feb 22, 2013 11:14 pm
languages_spoken: English
ODROIDs: ODROID

Re: Getting UAS working on HK 4.9

Unread postby tkaiser » Mon May 22, 2017 2:30 pm

odroid wrote:
tkaiser wrote:BTW, it seems to be around 25% faster than Jmicron USB 3.0 SATA bridges.


I don't think so, results are more or less the same as with JMS567: http://kaiser-edv.de/tmp/3zK9lI/

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

Some details about why testing with small SSDs or wrong tools (hdparm) may lead to wrong results: https://forum.armbian.com/index.php?/to ... ment=15265 (if you look there for XU4 I believe you find performance numbers with JMS567 too)
tkaiser
 
Posts: 94
Joined: Mon Nov 09, 2015 12:30 am
languages_spoken: english
ODROIDs: C1+, C2, XU4, HC1

Re: Getting UAS working on HK 4.9

Unread postby tkaiser » Mon May 22, 2017 3:08 pm

Since one of the JMS567 was lying around I just switched the EVO 840 SSD and tested.

1) Powering up XU4, using Web UI to mount /dev/sda, fails early and disk doesn't show up at all:
Code: Select all
[   94.565421] EXT2-fs (sda1): (no)user_xattr optionsnot supported
[   94.565429] EXT2-fs (sda1): (no)acl options not supported
[   94.565917] EXT2-fs (sda1): warning: mounting unchecked fs, running e2fsck is recommended
[  100.933775] usb 4-1.1: USB disconnect, device number 3
[  100.935868] EXT2-fs (sda1): previous I/O error to superblock detected

[  100.938948] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[  101.021248] EXT2-fs (sda1): previous I/O error to superblock detected

[  101.026390] EXT2-fs (sda1): previous I/O error to superblock detected

[  101.026498] VFS: Dirty inode writeback failed for block device sda1 (err=-5).
[  101.226228] sd 0:0:0:0: [sda] Synchronize Cache(10) failed: Result: hostbyte=0x07 driverbyte=0x00
[  108.789563] Buffer I/O error on dev dm-0, logical block 25049072, async page read
[  108.789920] Buffer I/O error on dev dm-0, logical block 25049072, async page read
[  108.790205] Buffer I/O error on dev dm-1, logical block 4192240, async page read
[  108.790536] Buffer I/O error on dev dm-1, logical block 4192240, async page read
[  108.829836] Buffer I/O error on dev dm-0, logical block 25049072, async page read
[  108.830200] Buffer I/O error on dev dm-1, logical block 4192240, async page read
[  114.401317] usb 4-1.1: new SuperSpeed USB device number 4 using xhci-hcd
[  114.422967] usb 4-1.1: New USB device found, idVendor=152d, idProduct=3562
[  114.422982] usb 4-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  114.422993] usb 4-1.1: Product: AD TO BE II
[  114.423004] usb 4-1.1: Manufacturer: ADMKIV
[  114.423015] usb 4-1.1: SerialNumber: DB123456789699
[  114.428751] scsi host1: uas
[  114.430984] scsi 1:0:0:0: Direct-Access     ADplus   SuperVer         6302 PQ: 0 ANSI: 6
[  114.487746] sd 1:0:0:0: [sdb] 234441648 512-byte logical blocks: (120 GB/112 GiB)
[  114.487762] sd 1:0:0:0: [sdb] 4096-byte physical blocks
[  114.488050] sd 1:0:0:0: Attached scsi generic sg0 type 0
[  114.488726] sd 1:0:0:0: [sdb] Write Protect is off
[  114.488745] sd 1:0:0:0: [sdb] Mode Sense: 53 00 00 08
[  114.489319] sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[  114.494589]  sdb: sdb1 sdb2 < sdb5 >
[  114.499548] sd 1:0:0:0: [sdb] Attached SCSI disk
[  118.720705] Buffer I/O error on dev dm-0, logical block 25049072, async page read
[  118.721076] Buffer I/O error on dev dm-1, logical block 4192240, async page read
[  128.722093] Buffer I/O error on dev dm-0, logical block 25049072, async page read
[  128.722462] Buffer I/O error on dev dm-1, logical block 4192240, async page read
[  138.726009] Buffer I/O error on dev dm-0, logical block 25049072, async page read
[  138.726528] Buffer I/O error on dev dm-1, logical block 4192240, async page read


2) Now reusing the cable from the ASM1153 enclosure before (30 cm short, good connection to XU4 USB receptacle unlike the cable from 1) above):
Code: Select all
                                                              random    random
              kB  reclen    write  rewrite    read    reread    read     write
          102400       4    17411    18161    15878    16319    15897    18051
          102400      16    52884    51694    51447    53528    52048    52847
          102400     512   186637   211794
Error reading block 124 b5c00000
read: Input/output error


And
Code: Select all
[   23.461664] EXT2-fs (sda1): (no)user_xattr optionsnot supported
[   23.461671] EXT2-fs (sda1): (no)acl options not supported
[  238.571198] sd 0:0:0:0: [sda] tag#2 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD IN
[  238.571208] sd 0:0:0:0: [sda] tag#2 CDB: opcode=0x28 28 00 00 01 3a 8a 00 01 e8 00
[  238.571613] scsi host0: uas_eh_bus_reset_handler start
[  243.676253] xhci-hcd xhci-hcd.2.auto: Timeout while waiting for setup device command
[  243.886302] usb 4-1.1: reset SuperSpeed USB device number 3 using xhci-hcd
[  243.909448] scsi host0: uas_eh_bus_reset_handler success
[  276.971198] sd 0:0:0:0: [sda] tag#3 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD IN
[  276.971207] sd 0:0:0:0: [sda] tag#3 CDB: opcode=0x28 28 00 00 02 54 06 00 00 7a 00
[  276.971362] sd 0:0:0:0: [sda] tag#2 uas_eh_abort_handler 0 uas-tag 3 inflight: CMD IN
[  276.971369] sd 0:0:0:0: [sda] tag#2 CDB: opcode=0x28 28 00 00 02 52 96 00 01 6e 00
[  276.971636] sd 0:0:0:0: [sda] tag#1 uas_eh_abort_handler 0 uas-tag 2 inflight: CMD IN
[  276.971642] sd 0:0:0:0: [sda] tag#1 CDB: opcode=0x28 28 00 00 02 50 94 00 02 00 00
[  276.972011] scsi host0: uas_eh_bus_reset_handler start
[  282.076240] xhci-hcd xhci-hcd.2.auto: Timeout while waiting for setup device command
[  282.286311] usb 4-1.1: reset SuperSpeed USB device number 3 using xhci-hcd
[  282.309281] scsi host0: uas_eh_bus_reset_handler success
[  287.066783] usb 4-1.1: USB disconnect, device number 3
[  287.068175] sd 0:0:0:0: [sda] tag#0 uas_zap_pending 0 uas-tag 1 inflight: CMD
[  287.068198] sd 0:0:0:0: [sda] tag#0 CDB: opcode=0x28 28 00 00 03 2d 06 00 01 e8 00
[  287.068219] sd 0:0:0:0: [sda] tag#1 uas_zap_pending 0 uas-tag 2 inflight: CMD
[  287.068225] sd 0:0:0:0: [sda] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x01 driverbyte=0x00
[  287.068235] sd 0:0:0:0: [sda] tag#1 CDB: opcode=0x28 28 00 00 03 27 04 00 00 fe 00
[  287.068252] sd 0:0:0:0: [sda] tag#0 CDB: opcode=0x28 28 00 00 03 2d 06 00 01 e8 00
[  287.068258] sd 0:0:0:0: [sda] tag#2 uas_zap_pending 0 uas-tag 3 inflight: CMD
[  287.068272] sd 0:0:0:0: [sda] tag#2 CDB: opcode=0x28 28 00 00 03 2c 02 00 01 02 00
[  287.068278] blk_update_request: I/O error, dev sda, sector 208134
[  287.070962] sd 0:0:0:0: [sda] tag#1 UNKNOWN(0x2003) Result: hostbyte=0x01 driverbyte=0x00
[  287.070974] sd 0:0:0:0: [sda] tag#1 CDB: opcode=0x28 28 00 00 03 27 04 00 00 fe 00
[  287.070983] blk_update_request: I/O error, dev sda, sector 206596
[  287.071052] sd 0:0:0:0: [sda] tag#2 UNKNOWN(0x2003) Result: hostbyte=0x01 driverbyte=0x00
[  287.071064] sd 0:0:0:0: [sda] tag#2 CDB: opcode=0x28 28 00 00 03 2c 02 00 01 02 00
[  287.071076] blk_update_request: I/O error, dev sda, sector 207874
[  287.071294] EXT2-fs (sda1): previous I/O error to superblock detected

[  287.088432] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[  287.381226] sd 0:0:0:0: [sda] Synchronize Cache(10) failed: Result: hostbyte=0x07 driverbyte=0x00


3) Now using a second 5V/2A PSU connected to the JMS567 enclosure so that XU4 isn't powering the SSD any more:
Code: Select all
                                                              random    random
              kB  reclen    write  rewrite    read    reread    read     write
          102400       4    17020    17837    15911    16100    15684    17400
          102400      16    52790    51964    51359    53206    49646    54841
          102400     512   183983   210422   188490   194573   199289   220860
          102400    1024   199731   229626   211717   221393   222507   235260
          102400   16384   213030   309115   317193   319007   319431   309443


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):
Code: Select all
                                                          random    random
          kB  reclen    write  rewrite    read    reread    read     write
      102400       4    17429    18063    16711    16583    16662    18157
      102400      16    60515    66411    54269    53884    53125    62796
      102400     512   196927   222043   194967   201697   197068   227450
      102400    1024   209206   238126   216232   224110   222387   203806
      102400   16384   212471   319707   334500   333360   328053   344759
tkaiser
 
Posts: 94
Joined: Mon Nov 09, 2015 12:30 am
languages_spoken: english
ODROIDs: C1+, C2, XU4, HC1

Re: Getting UAS working on HK 4.9

Unread postby crashoverride » Mon May 22, 2017 3:22 pm

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.
crashoverride
 
Posts: 3060
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1

Re: Getting UAS working on HK 4.9

Unread postby tkaiser » Mon May 22, 2017 4:00 pm

crashoverride wrote:We should probably post a sticky of Linux compatible UAS controllers.


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

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
 
Posts: 94
Joined: Mon Nov 09, 2015 12:30 am
languages_spoken: english
ODROIDs: C1+, C2, XU4, HC1

Re: Getting UAS working on HK 4.9

Unread postby crashoverride » Mon May 22, 2017 4:04 pm

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?
crashoverride
 
Posts: 3060
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1

Re: Getting UAS working on HK 4.9

Unread postby odroid » Tue May 23, 2017 8:09 am

I've made a new sub-forum to talk about the CloudShell related issues.
viewforum.php?f=147

Let's keep talking about the USB and UAS related issue here.
User avatar
odroid
Site Admin
 
Posts: 24345
Joined: Fri Feb 22, 2013 11:14 pm
languages_spoken: English
ODROIDs: ODROID

Re: Getting UAS working on HK 4.9

Unread postby memeka » Tue May 23, 2017 9:25 am

crashoverride wrote:
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 :D)
User avatar
memeka
 
Posts: 3561
Joined: Mon May 20, 2013 10:22 am
languages_spoken: english
ODROIDs: XU rev2 + eMMC + UART
U3 + eMMC + IO Shield + UART

Re: Getting UAS working on HK 4.9

Unread postby crashoverride » Tue May 23, 2017 11:54 am

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".
crashoverride
 
Posts: 3060
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1

Re: Getting UAS working on HK 4.9

Unread postby Kosmatik » Tue May 23, 2017 12:19 pm

Add me to the list that's also having issues with 4.9.y and UAS
I 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.

This is connected through the CloudShell2
here's dmesg with UAS
Code: Select all
[   98.731333] sd 0:0:0:0: [sda] tag#0 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD IN
[   98.731343] sd 0:0:0:0: [sda] tag#0 CDB: opcode=0x85 85 08 0e 00 d5 00 08 00 04 00 4f 00 c2 00 b0 00
[  117.596386] sd 0:0:0:0: [sda] tag#3 uas_eh_abort_handler 0 uas-tag 4 inflight: CMD IN
[  117.596396] sd 0:0:0:0: [sda] tag#3 CDB: opcode=0x85 85 08 0e 00 00 00 01 00 00 00 00 00 00 00 ec 00
[  117.596482] scsi host0: uas_eh_bus_reset_handler start
[  117.598466] sd 0:0:0:1: [sdb] tag#1 uas_zap_pending 0 uas-tag 2 inflight: CMD
[  117.598473] sd 0:0:0:1: [sdb] tag#1 CDB: opcode=0x88 88 00 00 00 00 00 09 ea 01 00 00 00 01 00 00 00
[  117.598481] sd 0:0:0:1: [sdb] tag#2 uas_zap_pending 0 uas-tag 3 inflight: CMD
[  117.598487] sd 0:0:0:1: [sdb] tag#2 CDB: opcode=0x88 88 00 00 00 00 00 09 ea 02 00 00 00 01 00 00 00
[  117.598494] sd 0:0:0:0: [sda] tag#4 uas_zap_pending 0 uas-tag 5 inflight: CMD
[  117.598500] sd 0:0:0:0: [sda] tag#4 CDB: opcode=0x8a 8a 00 00 00 00 01 b6 00 08 00 00 00 00 08 00 00
[  117.598507] sd 0:0:0:0: [sda] tag#5 uas_zap_pending 0 uas-tag 6 inflight: CMD
[  117.598513] sd 0:0:0:0: [sda] tag#5 CDB: opcode=0x8a 8a 00 00 00 00 01 b6 00 08 80 00 00 00 08 00 00
[  117.598519] sd 0:0:0:0: [sda] tag#6 uas_zap_pending 0 uas-tag 7 inflight: CMD
[  117.598525] sd 0:0:0:0: [sda] tag#6 CDB: opcode=0x8a 8a 00 00 00 00 01 b6 00 09 00 00 00 00 08 00 00
[  117.598532] sd 0:0:0:0: [sda] tag#7 uas_zap_pending 0 uas-tag 8 inflight: CMD
[  117.598537] sd 0:0:0:0: [sda] tag#7 CDB: opcode=0x8a 8a 00 00 00 00 01 b6 00 0b e0 00 00 00 28 00 00
[  117.598544] sd 0:0:0:0: [sda] tag#8 uas_zap_pending 0 uas-tag 9 inflight: CMD
[  117.598550] sd 0:0:0:0: [sda] tag#8 CDB: opcode=0x8a 8a 00 00 00 00 01 b6 01 09 08 00 00 00 08 00 00
[  117.598557] sd 0:0:0:0: [sda] tag#9 uas_zap_pending 0 uas-tag 10 inflight: CMD
[  117.598563] sd 0:0:0:0: [sda] tag#9 CDB: opcode=0x8a 8a 00 00 00 00 00 40 c0 08 38 00 00 00 08 00 00
[  117.598569] sd 0:0:0:0: [sda] tag#10 uas_zap_pending 0 uas-tag 11 inflight: CMD
[  117.598575] sd 0:0:0:0: [sda] tag#10 CDB: opcode=0x8a 8a 00 00 00 00 00 00 00 28 30 00 00 00 08 00 00
[  117.598582] sd 0:0:0:0: [sda] tag#11 uas_zap_pending 0 uas-tag 12 inflight: CMD
[  117.598588] sd 0:0:0:0: [sda] tag#11 CDB: opcode=0x8a 8a 00 00 00 00 00 00 00 28 20 00 00 00 08 00 00
[  117.676469] usb 4-1.1: reset SuperSpeed USB device number 3 using xhci-hcd
[  117.698748] scsi host0: uas_eh_bus_reset_handler success
[  157.700937] program smartctl is using a deprecated SCSI ioctl, please convert it to SG_IO
[  189.931450] sd 0:0:0:0: [sda] tag#12 uas_eh_abort_handler 0 uas-tag 13 inflight: CMD IN
[  189.931461] sd 0:0:0:0: [sda] tag#12 CDB: opcode=0x88 88 00 00 00 00 01 b6 01 09 18 00 00 00 08 00 00
[  189.931522] sd 0:0:0:0: [sda] tag#11 uas_eh_abort_handler 0 uas-tag 12 inflight: CMD OUT
[  189.931530] sd 0:0:0:0: [sda] tag#11 CDB: opcode=0x8a 8a 00 00 00 00 00 00 00 0e e0 00 00 00 08 00 00
[  189.931604] sd 0:0:0:0: [sda] tag#10 uas_eh_abort_handler 0 uas-tag 11 inflight: CMD OUT
[  189.931611] sd 0:0:0:0: [sda] tag#10 CDB: opcode=0x8a 8a 00 00 00 00 00 00 00 09 08 00 00 00 08 00 00
[  189.931686] sd 0:0:0:0: [sda] tag#9 uas_eh_abort_handler 0 uas-tag 10 inflight: CMD OUT
[  189.931692] sd 0:0:0:0: [sda] tag#9 CDB: opcode=0x8a 8a 00 00 00 00 00 00 00 08 00 00 00 00 10 00 00
[  189.931769] sd 0:0:0:0: [sda] tag#8 uas_eh_abort_handler 0 uas-tag 9 inflight: CMD OUT
[  189.931775] sd 0:0:0:0: [sda] tag#8 CDB: opcode=0x8a 8a 00 00 00 00 00 00 00 28 10 00 00 00 08 00 00
[  189.931853] sd 0:0:0:0: [sda] tag#7 uas_eh_abort_handler 0 uas-tag 8 inflight: CMD OUT
[  189.931859] sd 0:0:0:0: [sda] tag#7 CDB: opcode=0x8a 8a 00 00 00 00 00 00 00 28 20 00 00 00 08 00 00
[  189.931936] sd 0:0:0:0: [sda] tag#6 uas_eh_abort_handler 0 uas-tag 7 inflight: CMD OUT
[  189.931942] sd 0:0:0:0: [sda] tag#6 CDB: opcode=0x8a 8a 00 00 00 00 00 00 00 28 30 00 00 00 08 00 00
[  189.932021] sd 0:0:0:0: [sda] tag#5 uas_eh_abort_handler 0 uas-tag 6 inflight: CMD OUT
[  189.932027] sd 0:0:0:0: [sda] tag#5 CDB: opcode=0x8a 8a 00 00 00 00 00 40 c0 08 38 00 00 00 08 00 00
[  189.932104] sd 0:0:0:0: [sda] tag#4 uas_eh_abort_handler 0 uas-tag 5 inflight: CMD OUT
[  189.932110] sd 0:0:0:0: [sda] tag#4 CDB: opcode=0x8a 8a 00 00 00 00 01 b6 01 09 08 00 00 00 08 00 00
[  189.932188] sd 0:0:0:0: [sda] tag#3 uas_eh_abort_handler 0 uas-tag 4 inflight: CMD OUT
[  189.932194] sd 0:0:0:0: [sda] tag#3 CDB: opcode=0x8a 8a 00 00 00 00 01 b6 00 0b e0 00 00 00 28 00 00


Everything below with it blacklisted

Code: Select all
root@openmediavault:# smartctl -a /dev/sda
smartctl 6.4 2014-10-07 r4002 [armv7l-linux-4.9.28-odroidxu4] (local build)
Copyright (C) 2002-14, Bruce Allen, Christian Franke, www.smartmontools.org

/dev/sda: Unknown USB bridge [0x152d:0x0561 (0x8037)]
Please specify device type with the -d option.

Use smartctl -h to get a usage summary

Code: Select all
root@openmediavault:/dev# smartctl -a /dev/sdb -d scsi
smartctl 6.4 2014-10-07 r4002 [armv7l-linux-4.9.28-odroidxu4] (local build)
Copyright (C) 2002-14, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Vendor:               JMicron
Product:              1
Revision:             8037
Compliance:           SPC-4
User Capacity:        4,000,787,030,016 bytes [4.00 TB]
Logical block size:   512 bytes
LB provisioning type: unreported, LBPME=-1, LBPRZ=0
Form Factor:          3.5 inches
Serial number:        DB01234567D2
Device type:          disk
Local Time is:        Mon May 22 23:23:03 2017 EDT
SMART support is:     Unavailable - device lacks SMART capability.

=== START OF READ SMART DATA SECTION ===

Error Counter logging not supported

Device does not support Self Test logging

Code: Select all
root@openmediavault:# smartctl -a /dev/sda -d sat
smartctl 6.4 2014-10-07 r4002 [armv7l-linux-4.9.28-odroidxu4] (local build)
Copyright (C) 2002-14, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Device Model:     TOSHIBA HDWQ140
Serial Number:    47A1K0SRFPBE
Firmware Version: FJ1M
User Capacity:    4,000,787,030,016 bytes [4.00 TB]
Sector Size:      512 bytes logical/physical
Rotation Rate:    7200 rpm
Device is:        Not in smartctl database [for details use: -P showall]
ATA Version is:   ATA/ATAPI-7 (minor revision not indicated)
Local Time is:    Mon May 22 23:00:29 2017 EDT
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART Status not supported: Incomplete response, ATA output registers missing
SMART overall-health self-assessment test result: PASSED
Warning: This result is based on an Attribute check.

General SMART Values:
Offline data collection status:  (0x82) Offline data collection activity
                                        was completed without error.
                                        Auto Offline Data Collection: Enabled.
Self-test execution status:      (   0) The previous self-test routine completed
                                        without error or no self-test has ever
                                        been run.
Total time to complete Offline
data collection:                (  120) seconds.
Offline data collection
capabilities:                    (0x5b) SMART execute Offline immediate.
                                        Auto Offline data collection on/off support.
                                        Suspend Offline collection upon new
                                        command.
                                        Offline surface scan supported.
                                        Self-test supported.
                                        No Conveyance Self-test supported.
                                        Selective Self-test supported.
SMART capabilities:            (0x0003) Saves SMART data before entering
                                        power-saving mode.
                                        Supports SMART auto save timer.
Error logging capability:        (0x01) Error logging supported.
                                        No General Purpose Logging support.
Short self-test routine
recommended polling time:        (   2) minutes.
Extended self-test routine
recommended polling time:        ( 449) minutes.

SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000b   100   100   050    Pre-fail  Always       -       0
  2 Throughput_Performance  0x0005   100   100   050    Pre-fail  Offline      -       0
  3 Spin_Up_Time            0x0027   100   100   001    Pre-fail  Always       -       6841
  4 Start_Stop_Count        0x0032   100   100   000    Old_age   Always       -       40
  5 Reallocated_Sector_Ct   0x0033   100   100   050    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x000b   100   100   050    Pre-fail  Always       -       0
  8 Seek_Time_Performance   0x0005   100   100   050    Pre-fail  Offline      -       0
  9 Power_On_Hours          0x0032   100   100   000    Old_age   Always       -       44
 10 Spin_Retry_Count        0x0033   100   100   030    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       35
191 G-Sense_Error_Rate      0x0032   100   100   000    Old_age   Always       -       1
192 Power-Off_Retract_Count 0x0032   100   100   000    Old_age   Always       -       22
193 Load_Cycle_Count        0x0032   100   100   000    Old_age   Always       -       44
194 Temperature_Celsius     0x0022   100   100   000    Old_age   Always       -       53 (Min/Max 22/55)
196 Reallocated_Event_Count 0x0032   100   100   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0032   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0030   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x0032   200   253   000    Old_age   Always       -       0
220 Disk_Shift              0x0002   100   100   000    Old_age   Always       -       0
222 Loaded_Hours            0x0032   100   100   000    Old_age   Always       -       43
223 Load_Retry_Count        0x0032   100   100   000    Old_age   Always       -       0
224 Load_Friction           0x0022   100   100   000    Old_age   Always       -       0
226 Load-in_Time            0x0026   100   100   000    Old_age   Always       -       573
240 Head_Flying_Hours       0x0001   100   100   001    Pre-fail  Offline      -       0

SMART Error Log Version: 1
No Errors Logged

SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Short offline       Completed without error       00%         6         -
# 2  Short offline       Completed without error       00%         6         -

SMART Selective self-test log data structure revision number 1
 SPAN  MIN_LBA  MAX_LBA  CURRENT_TEST_STATUS
    1        0        0  Not_testing
    2        0        0  Not_testing
    3        0        0  Not_testing
    4        0        0  Not_testing
    5        0        0  Not_testing
Selective self-test flags (0x0):
  After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.


http://sprunge.us/KKQD
Kosmatik
 
Posts: 25
Joined: Tue May 23, 2017 12:06 pm
languages_spoken: English, Russian
ODROIDs: XU4

Re: Getting UAS working on HK 4.9

Unread postby odroid » Tue May 23, 2017 4:19 pm

Did you flash this OMV image?
OMV_3_0_76_Odroidxu4_4.9.28.7z

Do you use PM(JBOD) mode on CloudShell?
User avatar
odroid
Site Admin
 
Posts: 24345
Joined: Fri Feb 22, 2013 11:14 pm
languages_spoken: English
ODROIDs: ODROID

Re: Getting UAS working on HK 4.9

Unread postby Kosmatik » Tue May 23, 2017 9:23 pm

PM and I tried all images, finally built my own fresh 16 hours ago.

Linux openmediavault 4.9.28-odroidxu4 #9 SMP PREEMPT Mon May 22 14:06:39 EDT 2017 armv7l GNU/Linux
Kosmatik
 
Posts: 25
Joined: Tue May 23, 2017 12:06 pm
languages_spoken: English, Russian
ODROIDs: XU4

Re: Getting UAS working on HK 4.9

Unread postby tmihai20 » Tue May 23, 2017 9:39 pm

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.
tmihai20
 
Posts: 56
Joined: Mon Nov 07, 2016 10:56 pm
Location: Romania
languages_spoken: english, french, italian, romanian
ODROIDs: XU4

Re: Getting UAS working on HK 4.9

Unread postby odroid » Tue May 23, 2017 9:46 pm

@Kosmatik
Please let me know what happens if you disable UAS mode.
Add the CloudShell2 VID/PID in boot parameter of boot.ini file to disable the UAS function temporarily.
usb-storage.quirks=0x0bc2:0x2322:u

I will try the smartctrl functionality on the OMV_3_0_76_Odroidxu4_4.9.28.7z image tomorrow.
User avatar
odroid
Site Admin
 
Posts: 24345
Joined: Fri Feb 22, 2013 11:14 pm
languages_spoken: English
ODROIDs: ODROID

Re: Getting UAS working on HK 4.9

Unread postby odroid » Tue May 23, 2017 9:50 pm

@tmihai20
Try the Update Management menu on the Web UI.
User avatar
odroid
Site Admin
 
Posts: 24345
Joined: Fri Feb 22, 2013 11:14 pm
languages_spoken: English
ODROIDs: ODROID

Re: Getting UAS working on HK 4.9

Unread postby Kosmatik » Tue May 23, 2017 10:34 pm

@tmihai20
Compile your own or wait ~2 weeks and then you'll be able to get it through apt.

@odroid
With UAS disabled deluge had a couple torrents stop overnight due to a read error.

Looks like it's not as stable as I thought with UAS disabled. It remounted sdb to sdc which messes with monitoring scripts in OMV.

Code: Select all
[ 1180.457957] usb 4-1.1: reset SuperSpeed USB device number 3 using xhci-hcd
[ 1181.582912] usb 4-1.1: reset SuperSpeed USB device number 3 using xhci-hcd
[ 1195.692937] usb 4-1.1: reset SuperSpeed USB device number 3 using xhci-hcd
[ 1226.248005] usb 4-1.1: reset SuperSpeed USB device number 3 using xhci-hcd
[ 1282.403060] usb 4-1.1: reset SuperSpeed USB device number 3 using xhci-hcd
[ 1329.893135] usb 4-1.1: reset SuperSpeed USB device number 3 using xhci-hcd
[ 1331.818166] usb 4-1.1: reset SuperSpeed USB device number 3 using xhci-hcd
[ 1350.433161] usb 4-1.1: reset SuperSpeed USB device number 3 using xhci-hcd
[ 1404.958252] usb 4-1.1: reset SuperSpeed USB device number 3 using xhci-hcd
[ 1434.518277] usb 4-1.1: reset SuperSpeed USB device number 3 using xhci-hcd
[ 1497.948369] usb 4-1.1: reset SuperSpeed USB device number 3 using xhci-hcd
[ 1506.008376] usb 4-1.1: reset SuperSpeed USB device number 3 using xhci-hcd
[ 1533.853419] usb 4-1.1: reset SuperSpeed USB device number 3 using xhci-hcd
[ 1553.453445] usb 4-1.1: reset SuperSpeed USB device number 3 using xhci-hcd
[ 1558.808475] usb 4-1.1: reset SuperSpeed USB device number 3 using xhci-hcd
[ 1565.958478] usb 4-1.1: Device not responding to setup address.
[ 1566.168390] usb 4-1.1: Device not responding to setup address.
[ 1566.378330] usb 4-1.1: device not accepting address 3, error -71
[ 1567.080151] usb 4-1.1: USB disconnect, device number 3
[ 1567.103389] sd 0:0:0:1: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x01 driverbyte=0x00
[ 1567.103399] sd 0:0:0:1: [sdb] tag#0 CDB: opcode=0x88 88 00 00 00 00 00 03 2c b8 10 00 00 01 00 00 00
[ 1567.103405] blk_update_request: I/O error, dev sdb, sector 53262352
[ 1567.103517] sd 0:0:0:1: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x01 driverbyte=0x00
[ 1567.103525] sd 0:0:0:1: [sdb] tag#0 CDB: opcode=0x88 88 00 00 00 00 00 03 2c b9 10 00 00 01 00 00 00
[ 1567.103531] blk_update_request: I/O error, dev sdb, sector 53262608
[ 1567.103575] sd 0:0:0:1: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x01 driverbyte=0x00
[ 1567.103583] sd 0:0:0:1: [sdb] tag#0 CDB: opcode=0x88 88 00 00 00 00 00 03 2c b8 10 00 00 00 08 00 00
[ 1567.103588] blk_update_request: I/O error, dev sdb, sector 53262352
[ 1567.103657] sd 0:0:0:1: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x01 driverbyte=0x00
[ 1567.103663] sd 0:0:0:1: [sdb] tag#0 CDB: opcode=0x88 88 00 00 00 00 00 03 2c b8 10 00 00 00 08 00 00
[ 1567.103669] blk_update_request: I/O error, dev sdb, sector 53262352
[ 1567.109110] sd 0:0:0:1: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x01 driverbyte=0x00
[ 1567.109118] sd 0:0:0:1: [sdb] tag#0 CDB: opcode=0x88 88 00 00 00 00 00 03 2c b8 10 00 00 00 08 00 00
[ 1567.109125] blk_update_request: I/O error, dev sdb, sector 53262352
[ 1567.109611] sd 0:0:0:1: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x01 driverbyte=0x00
[ 1567.109620] sd 0:0:0:1: [sdb] tag#0 CDB: opcode=0x88 88 00 00 00 00 00 03 2c b8 10 00 00 00 08 00 00
[ 1567.109626] blk_update_request: I/O error, dev sdb, sector 53262352
[ 1567.109701] sd 0:0:0:1: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x01 driverbyte=0x00
[ 1567.109708] sd 0:0:0:1: [sdb] tag#0 CDB: opcode=0x88 88 00 00 00 00 00 03 2c b8 10 00 00 00 08 00 00
[ 1567.109713] blk_update_request: I/O error, dev sdb, sector 53262352
[ 1568.720780] EXT4-fs error (device sdb1): ext4_find_entry:1463: inode #185860097: comm deluged: reading directory lblock 0
[ 1568.853841] EXT4-fs error (device sdb1): ext4_find_entry:1463: inode #185860099: comm Plex Media Scan: reading directory lblock 0
[ 1569.515077] EXT4-fs error (device sdb1): ext4_find_entry:1463: inode #185860099: comm Plex Media Scan: reading directory lblock 0
[ 1570.170975] EXT4-fs error (device sdb1): ext4_find_entry:1463: inode #185860099: comm Plex Media Scan: reading directory lblock 0
[ 1570.833837] EXT4-fs error (device sdb1): ext4_find_entry:1463: inode #185860099: comm Plex Media Scan: reading directory lblock 0
[ 1571.494823] EXT4-fs error (device sdb1): ext4_find_entry:1463: inode #185860099: comm Plex Media Scan: reading directory lblock 0
[ 1572.156874] EXT4-fs error (device sdb1): ext4_find_entry:1463: inode #185860099: comm Plex Media Scan: reading directory lblock 0
[ 1572.849191] EXT4-fs error (device sdb1): ext4_find_entry:1463: inode #185860099: comm Plex Media Scan: reading directory lblock 0
[ 1572.883424] usb 4-1.1: new SuperSpeed USB device number 4 using xhci-hcd
[ 1572.904422] usb 4-1.1: New USB device found, idVendor=152d, idProduct=0561
[ 1572.904431] usb 4-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=5
[ 1572.904437] usb 4-1.1: Product: External Disk 3.0
[ 1572.904442] usb 4-1.1: Manufacturer: JMicron
[ 1572.904447] usb 4-1.1: SerialNumber: DB01234567D2
[ 1572.905467] usb 4-1.1: UAS is blacklisted for this device, using usb-storage instead
[ 1572.905476] usb-storage 4-1.1:1.0: USB Mass Storage device detected
[ 1572.905666] usb-storage 4-1.1:1.0: Quirks match for vid 152d pid 0561: 800000
[ 1572.905736] scsi host1: usb-storage 4-1.1:1.0
[ 1573.527635] EXT4-fs error (device sdb1): ext4_find_entry:1463: inode #185860098: comm Plex Media Scan: reading directory lblock 0
[ 1573.919668] scsi 1:0:0:0: Direct-Access     JMicron  0                8037 PQ: 0 ANSI: 6
[ 1573.921420] sd 1:0:0:0: [sda] Very big device. Trying to use READ CAPACITY(16).
[ 1573.921769] sd 1:0:0:0: [sda] 7814037168 512-byte logical blocks: (4.00 TB/3.64 TiB)
[ 1573.921775] sd 1:0:0:0: Attached scsi generic sg0 type 0
[ 1573.922392] sd 1:0:0:0: [sda] Write Protect is off
[ 1573.922413] sd 1:0:0:0: [sda] Mode Sense: 47 00 10 08
[ 1573.923005] sd 1:0:0:0: [sda] No Caching mode page found
[ 1573.923014] sd 1:0:0:0: [sda] Assuming drive cache: write through
[ 1573.924577] scsi 1:0:0:1: Direct-Access     JMicron  1                8037 PQ: 0 ANSI: 6
[ 1573.926766] sd 1:0:0:1: Attached scsi generic sg1 type 0
[ 1573.929624] sd 1:0:0:0: [sda] Very big device. Trying to use READ CAPACITY(16).
[ 1573.929922] sd 1:0:0:1: [sdc] Very big device. Trying to use READ CAPACITY(16).
[ 1573.930441] sd 1:0:0:1: [sdc] 7814037168 512-byte logical blocks: (4.00 TB/3.64 TiB)
[ 1573.931333] sd 1:0:0:1: [sdc] Write Protect is off
[ 1573.931344] sd 1:0:0:1: [sdc] Mode Sense: 47 00 10 08
[ 1573.932223] sd 1:0:0:1: [sdc] No Caching mode page found
[ 1573.932232] sd 1:0:0:1: [sdc] Assuming drive cache: write through
[ 1574.144033] sd 1:0:0:1: [sdc] Very big device. Trying to use READ CAPACITY(16).
[ 1574.186826] EXT4-fs error (device sdb1): ext4_find_entry:1463: inode #185860099: comm Plex Media Scan: reading directory lblock 0
[ 1574.473529]  sda: sda1
[ 1574.482305] sd 1:0:0:0: [sda] Very big device. Trying to use READ CAPACITY(16).
[ 1574.483993]  sdc: sdc1
[ 1574.484689] sd 1:0:0:0: [sda] Attached SCSI disk
[ 1574.485147] sd 1:0:0:1: [sdc] Very big device. Trying to use READ CAPACITY(16).
[ 1574.486551] sd 1:0:0:1: [sdc] Attached SCSI disk
[ 1574.881369] EXT4-fs error (device sdb1): ext4_find_entry:1463: inode #185860099: comm Plex Media Scan: reading directory lblock 0
[ 1575.554062] EXT4-fs error (device sdb1): ext4_find_entry:1463: inode #185860099: comm Plex Media Scan: reading directory lblock 0
[ 1576.210002] EXT4-fs error (device sdb1): ext4_find_entry:1463: inode #185860099: comm Plex Media Scan: reading directory lblock 0
[ 1576.874715] EXT4-fs error (device sdb1): ext4_find_entry:1463: inode #185860099: comm Plex Media Scan: reading directory lblock 0
[ 1577.553756] EXT4-fs error (device sdb1): ext4_find_entry:1463: inode #185860099: comm Plex Media Scan: reading directory lblock 0
[ 1578.230125] EXT4-fs error (device sdb1): ext4_find_entry:1463: inode #185860099: comm Plex Media Scan: reading directory lblock 0
[ 1578.897763] EXT4-fs error (device sdb1): ext4_find_entry:1463: inode #185860099: comm Plex Media Scan: reading directory lblock 0
[ 1579.576047] EXT4-fs error (device sdb1): ext4_find_entry:1463: inode #185860098: comm Plex Media Scan: reading directory lblock 0
[ 1580.246263] EXT4-fs error (device sdb1): ext4_find_entry:1463: inode #185860099: comm Plex Media Scan: reading directory lblock 0
[ 1580.905301] EXT4-fs error (device sdb1): ext4_find_entry:1463: inode #185860099: comm Plex Media Scan: reading directory lblock 0
[ 1581.578729] EXT4-fs error (device sdb1): ext4_find_entry:1463: inode #185860099: comm Plex Media Scan: reading directory lblock 0
[ 1581.772873] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: user_xattr,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0,acl
[ 1582.267891] EXT4-fs error (device sdb1): ext4_find_entry:1463: inode #185860099: comm Plex Media Scan: reading directory lblock 0
[ 1582.946169] EXT4-fs error (device sdb1): ext4_find_entry:1463: inode #185860099: comm Plex Media Scan: reading directory lblock 0
[ 1583.605588] EXT4-fs error (device sdb1): ext4_find_entry:1463: inode #185860099: comm Plex Media Scan: reading directory lblock 0
[ 1584.262160] EXT4-fs error (device sdb1): ext4_find_entry:1463: inode #185860099: comm Plex Media Scan: reading directory lblock 0
[ 1584.917138] EXT4-fs error (device sdb1): ext4_find_entry:1463: inode #185860099: comm Plex Media Scan: reading directory lblock 0
[ 1585.605947] EXT4-fs error (device sdb1): ext4_find_entry:1463: inode #185860099: comm Plex Media Scan: reading directory lblock 0
[ 1586.262006] EXT4-fs error (device sdb1): ext4_find_entry:1463: inode #185860098: comm Plex Media Scan: reading directory lblock 0
[ 1586.917555] EXT4-fs error (device sdb1): ext4_find_entry:1463: inode #185860098: comm Plex Media Scan: reading directory lblock 0
[ 1587.590428] EXT4-fs error (device sdb1): ext4_find_entry:1463: inode #185860099: comm Plex Media Scan: reading directory lblock 0
[ 1588.580676] EXT4-fs error (device sdb1): ext4_find_entry:1463: inode #185860099: comm Plex Media Scan: reading directory lblock 0
[ 1589.245975] EXT4-fs error (device sdb1): ext4_find_entry:1463: inode #185860099: comm Plex Media Scan: reading directory lblock 0
[ 1589.920599] EXT4-fs error (device sdb1): ext4_find_entry:1463: inode #185860099: comm Plex Media Scan: reading directory lblock 0
[ 1590.572934] EXT4-fs error (device sdb1): ext4_find_entry:1463: inode #185860099: comm Plex Media Scan: reading directory lblock 0
[ 1591.243163] EXT4-fs error (device sdb1): ext4_find_entry:1463: inode #185860099: comm Plex Media Scan: reading directory lblock 0
[ 1701.296137] EXT4-fs error (device sdb1): ext4_find_entry:1463: inode #185860099: comm deluged: reading directory lblock 0
[19924.013389] TCP: request_sock_TCP: Possible SYN flooding on port 40231. Sending cookies.  Check SNMP counters.
[26946.411083] EXT4-fs error (device sdb1): ext4_find_entry:1463: inode #185860098: comm Plex Media Serv: reading directory lblock 0
[26946.412253] EXT4-fs error (device sdb1): ext4_find_entry:1463: inode #185860099: comm Plex Media Serv: reading directory lblock 0
[27014.063295] EXT4-fs warning (device sdb1): htree_dirblock_to_tree:962: inode #185860099: lblock 0: comm Plex Media Scan: error -5 reading directory block
[27014.063376] EXT4-fs error (device sdb1): __ext4_get_inode_loc:4339: inode #185860099: block 743440416: comm Plex Media Scan: unable to read itable block
[27014.063995] EXT4-fs error (device sdb1) in ext4_reserve_inode_write:5418: IO failure
[27014.064448] ------------[ cut here ]------------
[27014.064461] WARNING: CPU: 5 PID: 14209 at fs/fs-writeback.c:2154 __mark_inode_dirty+0x184/0x214
[27014.064465] bdi-block not registered
[27014.064469] Modules linked in: binfmt_misc cfg80211 rfkill cpufreq_powersave cpufreq_conservative cpufreq_userspace cpufreq_ondemand s5p_sss pwm_fan uio_pdrv_genirq uio exynos_gpiomem fb_ili9340(C) fbtft_device(C) fbtft(C) spidev spi_s3c64xx fuse ipv6 uas md_mod
[27014.064541] CPU: 5 PID: 14209 Comm: Plex Media Scan Tainted: G         C      4.9.28-odroidxu4 #9
[27014.064545] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[27014.064562] [<c010e93c>] (unwind_backtrace) from [<c010b5a4>] (show_stack+0x10/0x14)
[27014.064571] [<c010b5a4>] (show_stack) from [<c05ae218>] (dump_stack+0x84/0x98)
[27014.064581] [<c05ae218>] (dump_stack) from [<c0121028>] (__warn+0xe8/0x100)
[27014.064589] [<c0121028>] (__warn) from [<c0121078>] (warn_slowpath_fmt+0x38/0x48)
[27014.064596] [<c0121078>] (warn_slowpath_fmt) from [<c0251328>] (__mark_inode_dirty+0x184/0x214)
[27014.064605] [<c0251328>] (__mark_inode_dirty) from [<c0241e18>] (generic_update_time+0x74/0xa4)
[27014.064613] [<c0241e18>] (generic_update_time) from [<c0243798>] (touch_atime+0x98/0xb0)
[27014.064620] [<c0243798>] (touch_atime) from [<c0239bfc>] (iterate_dir+0x15c/0x194)
[27014.064635] [<c0239bfc>] (iterate_dir) from [<c023a284>] (SyS_getdents64+0x7c/0x120)
[27014.064648] [<c023a284>] (SyS_getdents64) from [<c0107780>] (ret_fast_syscall+0x0/0x3c)
[27014.064716] ---[ end trace 15655c406e77177f ]---
[27020.109763] Aborting journal on device sdb1-8.
[27020.109777] Buffer I/O error on dev sdb1, logical block 488144896, lost sync page write
[27020.109783] JBD2: Error -5 detected when updating journal superblock for sdb1-8.
[27049.925270] EXT4-fs warning (device sdb1): htree_dirblock_to_tree:962: inode #185860099: lblock 0: comm Plex Media Scan: error -5 reading directory block
[27080.590772] EXT4-fs warning (device sdb1): htree_dirblock_to_tree:962: inode #185860097: lblock 0: comm smbd: error -5 reading directory block
[27160.334246] EXT4-fs (sdc1): recovery complete
[27160.334564] EXT4-fs (sdc1): mounted filesystem with ordered data mode. Opts: user_xattr,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0,acl
root@openmediavault:~# ls /dev/sd*
/dev/sda  /dev/sda1  /dev/sdc  /dev/sdc1
Kosmatik
 
Posts: 25
Joined: Tue May 23, 2017 12:06 pm
languages_spoken: English, Russian
ODROIDs: XU4

Re: Getting UAS working on HK 4.9

Unread postby crashoverride » Tue May 23, 2017 10:45 pm

Kosmatik wrote:191 G-Sense_Error_Rate 0x0032 100 100 000 Old_age Always - 1

It appears the drive had been dropped or otherwise physically "shocked".
https://kb.acronis.com/content/9126
G-sense error rate S.M.A.R.T. parameter indicates the number of errors caused by externally-induced shock or vibration.


You should perform a full surface scan on the drive. It may have developed bad sectors due to physical trauma.
crashoverride
 
Posts: 3060
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1

PreviousNext

Return to Linux Kernel 4.9 Debugging Party

Who is online

Users browsing this forum: No registered users and 1 guest