Getting UAS working on HK 4.9

Test and fix the Kernel 4.14 features

Moderators: mdrjr, odroid

Re: Getting UAS working on HK 4.9

Unread postby mad_ady » Fri Apr 14, 2017 7:30 pm

@odroid: Regarding SMART - can you check if reading smart parameters whe the disks are spun down will wake up the disks?
You can spin down the disk with
Code: Select all
sudo hdparm -y /dev/sda

Check that the disk is in standby with sudo hdparm -C /dev/sda, then try to read smart data and see the disk state again. If the disk wakes up you may want to let your users know that showing smart data on the cloudshell's display may keep their drives awake. The longer discussion about this is in the XU4 as a general purpose NAS article.
Regarding reading smart data from a raid array - some hardware raid vendors expose the raw disks under some different nodes in /dev, so getting smart data should be possible.
User avatar
mad_ady
 
Posts: 2741
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 moon.linux » Fri Apr 14, 2017 11:42 pm

Thanks for New Cloudshell2

Code: Select all
 Storage
    2 Drive Bays     Supported size : 3.5” SATA HDD


All the 3.5" driver are powered via Cloudshell 2 ?

what is the max capacity for NAS HDD ?
moon.linux
 
Posts: 919
Joined: Thu Oct 02, 2014 11:42 pm
languages_spoken: english

Re: Getting UAS working on HK 4.9

Unread postby tkaiser » Sat Apr 15, 2017 12:19 am

moon.linux wrote:what is the max capacity for NAS HDD ?


There is none of course. You can attach any SATA HDD of any size.

mad_ady wrote:can you check if reading smart parameters whe the disks are spun down will wake up the disks


It's easy to prevent waking up the disks if you can query them (which I doubt since most people like unreliable hardware RAID modes ;) )
https://github.com/igorpecovnik/lib/blob/master/scripts/armbianmonitor/armbianmonitor#L67
tkaiser
 
Posts: 119
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 » Sat Apr 15, 2017 1:49 am

There is a risk though. Suppose your disk are scheduled to spin down after 10 min of inactivity. And you read temperature from them every 5 minutes. Let's say that you've set smartctl not to spin up the drive if it's idle. But once the disk has spun up (for whatever reason), smartctl will keep it awake by making small queries every 5 minutes. In this case you need to insure that smartctl polling time is greater than hdd sleep time.
User avatar
mad_ady
 
Posts: 2741
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 Apr 15, 2017 3:07 am

mad_ady wrote:But once the disk has spun up (for whatever reason), smartctl will keep it awake by making small queries every 5 minutes.


Maybe disks exist that are too stupid to differentiate between real access and metadata queries. But I personally never encountered such disk and do a lot of HDD monitoring and am also responsible for many users doing the same -- my RPi-Monitor template for H3 devices also monitors HDD temperature: http://www.cnx-software.com/2016/03/17/ ... orange-pi/

Not a single complaint but I still believe the real problem with Cloudshell2 is that it's not possible to query/control drives in RAID-1 mode (which people will use for reasons unknown to me)
tkaiser
 
Posts: 119
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 rooted » Sat Apr 15, 2017 3:58 am

How much does the surface temperature of an HD case reflect the inside temperature?

A couple of 1wire temperature sensors could be used instead of polling the drive if the temperature is similar, could also be used to place the drives in standby if they get too warm.
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 tkaiser » Sat Apr 15, 2017 5:35 am

rooted wrote:How much does the surface temperature of an HD case reflect the inside temperature?


Huh? If this is really of interest then the drive enclosure is broken by (thermal) design. If there's a NEED to monitor drive temperatures then there's already something really wrong. Fortunately in case of those Cloudshells it's just a useless gimmick throwing some numbers on a display.

If I'm concerned about drive health I add those drives to my central monitoring. If I'm concerned about heat I let a stress test run and then check the appropriate SMART log after 30 minutes. That's SCT! And looks like this:

Code: Select all
***@bananas ~ # smartctl -l scttemp /dev/sda
smartctl 5.41 2011-06-09 r3365 [armv7l-linux-3.4.104+] (local build)
Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net

=== START OF READ SMART DATA SECTION ===
SCT Status Version: 3
SCT Version (vendor specific): 1 (0x0001)
SCT Support Level: 1
Device State: Active (0)
Current Temperature: 25 Celsius
Power Cycle Min/Max Temperature: ?/ ? Celsius
Lifetime Min/Max Temperature: ?/ ? Celsius
Under/Over Temperature Limit Count: 0/5571
SCT Temperature History Version: 2
Temperature Sampling Period: 10 minutes
Temperature Logging Interval: 10 minutes
Min/Max recommended Temperature: ?/ ? Celsius
Min/Max Temperature Limit: ?/ ? Celsius
Temperature History Size (Index): 128 (109)

Index Estimated Time Temperature Celsius
110 2014-12-03 02:00 23 ****
... ..( 33 skipped). .. ****
16 2014-12-03 07:40 23 ****
17 2014-12-03 07:50 22 ***
... ..( 18 skipped). .. ***
36 2014-12-03 11:00 22 ***
37 2014-12-03 11:10 23 ****
38 2014-12-03 11:20 23 ****
39 2014-12-03 11:30 24 *****
... ..( 6 skipped). .. *****
46 2014-12-03 12:40 24 *****
47 2014-12-03 12:50 23 ****
... ..( 12 skipped). .. ****
60 2014-12-03 15:00 23 ****
61 2014-12-03 15:10 22 ***
... ..( 9 skipped). .. ***
71 2014-12-03 16:50 22 ***
72 2014-12-03 17:00 23 ****
73 2014-12-03 17:10 24 *****
... ..( 3 skipped). .. *****
77 2014-12-03 17:50 24 *****
78 2014-12-03 18:00 25 ******
... ..( 9 skipped). .. ******
88 2014-12-03 19:40 25 ******
89 2014-12-03 19:50 26 *******
90 2014-12-03 20:00 25 ******
... ..( 6 skipped). .. ******
97 2014-12-03 21:10 25 ******
98 2014-12-03 21:20 26 *******
... ..( 5 skipped). .. *******
104 2014-12-03 22:20 26 *******
105 2014-12-03 22:30 25 ******
... ..( 3 skipped). .. ******
109 2014-12-03 23:10 25 ******


Modern drives keep a long history of temperature records (the numbers on the right). You test this once with a new enclosure with worst case conditions (run a random IO disk benchmark for 30 minutes) and if it's ok there's exactly no need to query the drive ever again permanently. Just check SCT logs from time to time and you're done.

The problem with the Cloudshell2 is: it's impossible to get this data when using the stupid mode (RAID-1)
tkaiser
 
Posts: 119
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 rooted » Sat Apr 15, 2017 6:14 am

tkaiser wrote:
rooted wrote:How much does the surface temperature of an HD case reflect the inside temperature?


Huh? If this is really of interest then the drive enclosure is broken by (thermal) design. If there's a NEED to monitor drive temperatures then there's already something really wrong. Fortunately in case of those Cloudshells it's just a useless gimmick throwing some numbers on a display.

If I'm concerned about drive health I add those drives to my central monitoring. If I'm concerned about heat I let a stress test run and then check the appropriate SMART log after 30 minutes. That's SCT! And looks like this:

Code: Select all
***@bananas ~ # smartctl -l scttemp /dev/sda
smartctl 5.41 2011-06-09 r3365 [armv7l-linux-3.4.104+] (local build)
Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net

=== START OF READ SMART DATA SECTION ===
SCT Status Version: 3
SCT Version (vendor specific): 1 (0x0001)
SCT Support Level: 1
Device State: Active (0)
Current Temperature: 25 Celsius
Power Cycle Min/Max Temperature: ?/ ? Celsius
Lifetime Min/Max Temperature: ?/ ? Celsius
Under/Over Temperature Limit Count: 0/5571
SCT Temperature History Version: 2
Temperature Sampling Period: 10 minutes
Temperature Logging Interval: 10 minutes
Min/Max recommended Temperature: ?/ ? Celsius
Min/Max Temperature Limit: ?/ ? Celsius
Temperature History Size (Index): 128 (109)

Index Estimated Time Temperature Celsius
110 2014-12-03 02:00 23 ****
... ..( 33 skipped). .. ****
16 2014-12-03 07:40 23 ****
17 2014-12-03 07:50 22 ***
... ..( 18 skipped). .. ***
36 2014-12-03 11:00 22 ***
37 2014-12-03 11:10 23 ****
38 2014-12-03 11:20 23 ****
39 2014-12-03 11:30 24 *****
... ..( 6 skipped). .. *****
46 2014-12-03 12:40 24 *****
47 2014-12-03 12:50 23 ****
... ..( 12 skipped). .. ****
60 2014-12-03 15:00 23 ****
61 2014-12-03 15:10 22 ***
... ..( 9 skipped). .. ***
71 2014-12-03 16:50 22 ***
72 2014-12-03 17:00 23 ****
73 2014-12-03 17:10 24 *****
... ..( 3 skipped). .. *****
77 2014-12-03 17:50 24 *****
78 2014-12-03 18:00 25 ******
... ..( 9 skipped). .. ******
88 2014-12-03 19:40 25 ******
89 2014-12-03 19:50 26 *******
90 2014-12-03 20:00 25 ******
... ..( 6 skipped). .. ******
97 2014-12-03 21:10 25 ******
98 2014-12-03 21:20 26 *******
... ..( 5 skipped). .. *******
104 2014-12-03 22:20 26 *******
105 2014-12-03 22:30 25 ******
... ..( 3 skipped). .. ******
109 2014-12-03 23:10 25 ******


Modern drives keep a long history of temperature records (the numbers on the right). You test this once with a new enclosure with worst case conditions (run a random IO disk benchmark for 30 minutes) and if it's ok there's exactly no need to query the drive ever again permanently. Just check SCT logs once a month and you're done.

The problem with the Cloudshell2 is: it's impossible to get this data when using the stupid mode (RAID-1)


I didn't say that it needs it, I don't have one yet.

What I'm saying is (over)heat is directly related to mechanical condition of the drives, if monitoring doesn't work in certain RAID modes it allows you to at least keep an eye on temperature. We don't all have new drives, I have a new 2TB WD Blue and an older 1.5TB Samsung. The Samsung is in poor mechanical condition (bearings) so it generates more heat than it should.

It's important for me to monitor the temperature of that drive at all times, I should just replace it but eh.

This is all about the CloudShell 2, in the mode that can't be monitored. Personally I wouldn't use RAID but others will.
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 tkaiser » Sat Apr 15, 2017 6:52 am

Kinda off-topic already :)

But IMO it's pretty easy to check thermal problems. 30 minutes with a stress test are sufficient. If drives then report temperatures too high you need to investigate (there's that google report about drive failures, there's backblaze reporting their mis-use of desktop drives). Anyway: I would prefer to check thermal problems *once* and then never think about again (there's no magic involved: If you stress test your HDD to the max in an enclosure for 30 minutes you know what's to be expected with worst case conditions -- if temperature readouts via SMART years later exceed this your house is burning down -- it's that simple)

We use the thermal monitoring of HDDs/SSDs in the meantime for 'environmental' monitoring in rack cabinets. If temperature exceeds 15°C the normal level it triggers an alert. And that's all that's important if you want to be notified whether there's something wrong or not. :)
tkaiser
 
Posts: 119
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 rooted » Sat Apr 15, 2017 6:54 am

I thought this was the CloudShell 2 thread so way off topic, oops.
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 tkaiser » Wed Apr 26, 2017 4:34 pm

Just for the record: the automated OMV build I did some days ago has been tested with 2 Win 10 clients by myself now and performance numbers match my expectations. So I won't look into further 'tuning' those OMV images currently available for XU4 (and also C2 and C1): http://forum.openmediavault.org/index.php/Thread/17855-Building-OMV-automatically-for-a-bunch-of-different-ARM-dev-boards/?postID=142181#post142181

These OMV images are the result of using Armbian's build system producing a Debian Jessie OS image from scratch (building u-boot and kernel automatically, then debootstrapping a fresh Jessie) with OMV on top by a final image customization routine: https://github.com/armbian/build/blob/de25a5d8abd347cb3e3aacdbddbbc64255db823b/scripts/customize-image.sh.template#L31-L159

The OS image has to do some small tweaks on first boot (eg. resizing rootfs, finishing OMV installation) and reboots once. It gets u-boot/kernel upgrades through Armbian apt repository that uses upstream HK repo with UAS enabled: https://github.com/armbian/build/blob/master/config/sources/odroidxu4.conf#L33-L34

Debian and OMV repos are also configured so this OMV image will receive updates automagically. One issue currently with HK 4.9 kernel branch seems thermal behaviour (see first link to OMV forum) but once this has been addressed upstream every fix is just an 'apt upgrade' away.

The performance tweaks for ODROID-XU4 as follows

    * UAS enabled
    * IRQ processing on little CPU cores (differentiating between cpus 0-2 and 3) that are set to performance governor
    * NAS daemons running on big cores only with ondemand governor (tweaked settings, eg. io_is_busy=1) and optimized IO scheduling/priority
    * optimized Samba settings as default already set in OMV
    * flashmemory plugin enabled (making use of folder2ram to minimize writes to SD card or eMMC)
    * monitoring disabled by default (to minimize writes to SD card or eMMC)

Logon credentials are root/openmediavault for SSH access and admin/openmediavault for the UI.
tkaiser
 
Posts: 119
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 tmihai20 » Wed Apr 26, 2017 7:18 pm

Excellent work. This is the OMV image I was looking for.
tmihai20
 
Posts: 62
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 rncwnd » Thu Apr 27, 2017 1:18 am

I''m having a problem with uas and a USB3 HDD connected to an USB3 port.

After a cold boot (shutdown -h now, unplug, plug power) the USB HDD is recognized as USB3 uas device. But as soon as I read or write to it, I get strange errors and the disk is not usable anymore until I restart the xu4.
After a reboot (reboot or shutdown -r now) the disk is suddenly attached as USB2 uas device (yes USB two). Slow but stable.

Question:
Is it possible to blacklist the USB HDD for uas so that it uses old fashioned usb-storage?

The USB HDD enclosure is a Asmedia ASM1153E (SATA6.0 to USB3.0).
The SATA-HDD is a Western digital red 1TB.

This is the error I get in dmesg after cold boot (USB HDD connected as USB3 device, uas)
Code: Select all
[14060.012017] sd 1:0:0:0: [sdb] tag#0 data cmplt err -71 uas-tag 1 inflight: CMD
[14060.012032] sd 1:0:0:0: [sdb] tag#0 CDB: opcode=0x2a 2a 00 03 9d 29 00 00 00 80 00
[14060.012159] xhci-hcd xhci-hcd.2.auto: ERROR Transfer event for disabled endpoint or incorrect stream ring
[14060.012172] xhci-hcd xhci-hcd.2.auto: @00000000b684e060 00000000 00000000 04000000 04048000
[14093.291189] sd 1:0:0:0: [sdb] tag#27 uas_eh_abort_handler 0 uas-tag 28 inflight: CMD OUT
[14093.291202] sd 1:0:0:0: [sdb] tag#27 CDB: opcode=0x2a 2a 00 03 9d 83 00 00 00 18 00
[14093.291299] sd 1:0:0:0: [sdb] tag#26 uas_eh_abort_handler 0 uas-tag 27 inflight: CMD OUT
[14093.291307] sd 1:0:0:0: [sdb] tag#26 CDB: opcode=0x2a 2a 00 03 9d 82 80 00 00 80 00
[14093.291389] sd 1:0:0:0: [sdb] tag#25 uas_eh_abort_handler 0 uas-tag 26 inflight: CMD OUT
[14093.291396] sd 1:0:0:0: [sdb] tag#25 CDB: opcode=0x2a 2a 00 03 9d 82 00 00 00 80 00
[14093.291474] sd 1:0:0:0: [sdb] tag#24 uas_eh_abort_handler 0 uas-tag 25 inflight: CMD OUT
[14093.291482] sd 1:0:0:0: [sdb] tag#24 CDB: opcode=0x2a 2a 00 03 9d 81 80 00 00 80 00


This is after reboot without powercycle (USB HDD connected as USB2 device)
Relevant dmesg output:
Code: Select all
[    2.916445] usb 3-1: new high-speed USB device number 2 using xhci-hcd
[    3.155559] usb 3-1: New USB device found, idVendor=05e3, idProduct=0610
[    3.155582] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[    3.155596] usb 3-1: Product: USB2.0 Hub
[    3.155609] usb 3-1: Manufacturer: GenesysLogic
[    3.163942] hub 3-1:1.0: USB hub found
[    3.164369] hub 3-1:1.0: 2 ports detected
...
[    4.212829] usbcore: registered new interface driver uas
[    4.281217] usb 3-1.2: new high-speed USB device number 4 using xhci-hcd
[    4.428422] usb 3-1.2: New USB device found, idVendor=174c, idProduct=55aa
[    4.428460] usb 3-1.2: New USB device strings: Mfr=2, Product=3, SerialNumber=1
[    4.428499] usb 3-1.2: Product: ASM1153E
[    4.428527] usb 3-1.2: Manufacturer: ASMedia
[    4.428554] usb 3-1.2: SerialNumber: 201603090000EF
[    4.432427] scsi host1: uas
[    4.439374] scsi 1:0:0:0: Direct-Access     ASMedia  ASM1153E         0    PQ: 0 ANSI: 6
[    4.491760] sd 1:0:0:0: Attached scsi generic sg0 type 0
[    4.654445] sd 1:0:0:0: [sda] 1953525168 512-byte logical blocks: (1.00 TB/932 GiB)
[    4.654467] sd 1:0:0:0: [sda] 4096-byte physical blocks
[    4.656087] sd 1:0:0:0: [sda] Write Protect is off
[    4.656107] sd 1:0:0:0: [sda] Mode Sense: 43 00 00 00
[    4.657016] sd 1:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[    4.678229]  sda: sda1
[    4.682669] sd 1:0:0:0: [sda] Attached SCSI disk


Code: Select all
root@odroid:~# lsusb -t
/:  Bus 06.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
    |__ Port 1: Dev 2, If 0, Class=Vendor Specific Class, Driver=r8152, 5000M
/:  Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M
/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/2p, 5000M
        |__ Port 1: Dev 3, If 0,Class=Mass Storage, Driver=usb-storage, 5000M            ***** this is the internal cloudshell disk
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/2p, 480M
        |__ Port 2: Dev 4, If 0, Class=Mass Storage, Driver=uas, 480M                    ***** this is the external USB3 disk
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=exynos-ohci/3p, 12M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=exynos-ehci/3p, 480M
rncwnd
 
Posts: 31
Joined: Tue Apr 11, 2017 11:18 pm
languages_spoken: english, german
ODROIDs: XU4

Re: Getting UAS working on HK 4.9

Unread postby tkaiser » Thu Apr 27, 2017 1:56 am

rncwnd wrote:After a reboot (reboot or shutdown -r now) the disk is suddenly attached as USB2 uas device (yes USB two).


Time to check receptacles/contacts/cabling if the host is not even able to negotiate a SuperSpeed connection! :o
tkaiser
 
Posts: 119
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 » Thu Apr 27, 2017 3:04 am

Yes, I too experienced weird read/write errors (with usb-storage), which seemed to be ultimately fixed by *firmly* pushing the cables all the way in. I'm now afraid to reboot or touch my xu4 because it has been rock solid for the past month...
User avatar
mad_ady
 
Posts: 2741
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 » Thu Apr 27, 2017 5:15 am

Well, I thought one year ago about getting an XU4 but this thread was way too discouraging: viewtopic.php?f=95&t=15302
tkaiser
 
Posts: 119
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 rncwnd » Thu Apr 27, 2017 5:39 pm

mad_ady wrote:Yes, I too experienced weird read/write errors (with usb-storage), which seemed to be ultimately fixed by *firmly* pushing the cables all the way in. I'm now afraid to reboot or touch my xu4 because it has been rock solid for the past month...

I cleaned the USB3 ports twice, tried different cables plugged them in gently, plugged them in firmly, but all this doesn't help. So I think there could be two potential causes
1. There is a hardware design error with the USB3 ports.
2. There are some bugs in the kernel modules / drivers for the XU4 USB3 hardware.

The USB3 HDD works rock solid attached to my Sony Vaio Notebook running Ubuntu 16.04 with a recent HWE kernel (I think 4.8).

<RantMode>
When reading the marketing material about XU4 (http://www.hardkernel.com/main/products/prdt_info.php?g_code=G143452239825) now stating that kernel 4.9 is supported I get a very bad feeling. People tend to take that serious and trust that this is true. But reality is:
These problems put the great performance into perspective.
</RantMode>
rncwnd
 
Posts: 31
Joined: Tue Apr 11, 2017 11:18 pm
languages_spoken: english, german
ODROIDs: XU4

Re: Getting UAS working on HK 4.9

Unread postby mad_ady » Thu Apr 27, 2017 5:57 pm

HMP is supported in HK's kernel build. I proposed the cgroups workarounds before HMP was feasible (though I still use them myself because I want to manually assign certain processes to the big cores).
Regarding stable USB3 - it's a bit of a gamble. Some users have reported no USB problems. In my experience it depends...
User avatar
mad_ady
 
Posts: 2741
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 linuxest » Thu Apr 27, 2017 6:32 pm

XU4 USB 3.0 ports were quite picky until I used a much shorter and thicker cables.
Long and thin cables showed some random errors something like your result.
Once I changed it, it has been rock solid over several months.
linuxest
 
Posts: 37
Joined: Tue Nov 08, 2016 6:35 pm
languages_spoken: english
ODROIDs: 1 x HC1 and 2 x C2s with HiFi-Shield 2
And some RPi3 boards

Re: Getting UAS working on HK 4.9

Unread postby tkaiser » Thu Apr 27, 2017 8:50 pm

mad_ady wrote:Regarding stable USB3 - it's a bit of a gamble. Some users have reported no USB problems. In my experience it depends...


Not that much has changed the last decades. But 25 years ago it was SCSI cables/connectors that caused troubles, then we dealt with SATA cable/connector problems (always watch out for SMART attribute 199 here) and now we're doing the same with USB3. Well something has changed: people back then accepted to spend $50 or more on a single cable while today some folks even order cables directly from the other end of the world for less than $1 shipping included and surprisingly expect quality and not just trash.

USB3 PHY signaling rate is pretty high, USB3 still uses CRC-5/CRC-16 (cyclic redundancy check to detect data corruption on the wire) but I'm not aware of reading out error counters like this: http://lxr.free-electrons.com/source/in ... hcd.h#L584
tkaiser
 
Posts: 119
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 tmihai20 » Thu Apr 27, 2017 11:56 pm

I am using the cable that came with my external HDD. I expect that cable to be good and to not create issues. I have not yet tested 4.9.x kernel on my XU4 with the USB 3.0 external HDD.
tmihai20
 
Posts: 62
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 tkaiser » Fri Apr 28, 2017 1:05 am

tmihai20 wrote:I expect that cable to be good and to not create issues


I do it always the other way around. Expect that everything that newly arrives is broken until confirmed to work. 1st test with USB3 storage stuff is always to use a Samsung EVO840 connected to my MacBook and when sequential transfers are less than ~400MB/s I start to investigate. Bad performance (due to huge amounts of retransmits caused by CRC errors) or strange behaviour are way too often just the result of lousy hardware (eg. cables/connectors not exactly fitting or suffering from bad shielding and then interfering with stuff around and so on)
tkaiser
 
Posts: 119
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 tmihai20 » Fri Apr 28, 2017 1:12 am

@tkaiser: I transferred a lot of data from my older hard disks via the PC and it worked quite well, but I got around 80 to 90 MB/s. I do not think I did a benchmark test, if your numbers are coming from there.
tmihai20
 
Posts: 62
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 crashoverride » Fri Apr 28, 2017 11:18 am

FYI, I also had problems with my USB3 external HDD when the first 4.9 image was released. However, with the recent official Kernel, they are all gone. If you are testing with a "non-official" distro, try the official Ubuntu image (after applying all updates) and see if the issues persist. Other distros may have older or non-patched kernels.
crashoverride
 
Posts: 3101
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1

Re: Getting UAS working on HK 4.9

Unread postby mattrix » Fri Apr 28, 2017 12:06 pm

@rncwnd

I too has issues with UAS and my USB3 drives.

I ended up compiling the kernel with CONFIG_USB_UAS & CONFIG_USB_STORAGE as modules which allows for using modprobe.d rule to force usb-storage modes.
This fixed all my issues with my drives.

I have raised on issue on Github to see if HK want to set these to modules:
https://github.com/hardkernel/linux/issues/290

And I still get good 80-90 speeds even with usb-storage :)
mattrix
 
Posts: 88
Joined: Tue Jan 13, 2015 7:12 am
languages_spoken: english
ODROIDs: C1

Re: Getting UAS working on HK 4.9

Unread postby tmihai20 » Fri Apr 28, 2017 7:55 pm

@crashoverride: why should the official Beta Ubuntu image be better than the Debian image built with the same kernel? Upgrading to the latest kernel should fix the issues on tkaiser's debian image as well. tkaiser said that upgrading the kernel is done with a simple upgrade check, just as on Ubuntu. If I have enough time, I will try tkaiser's image this (prolonged) week-end. I really want to see if the newer kernel fixes the issues I have on OMV beta 3.0.x image.
tmihai20
 
Posts: 62
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 crashoverride » Fri Apr 28, 2017 8:12 pm

tmihai20 wrote:@crashoverride: why should the official Beta Ubuntu image be better than the Debian image built with the same kernel?

Other images may have customization (kernel config) or "optimizations" (such as IRQ affinity) that alter the operation of the system. The point of the post was not to say "other images are bad". It was simply "if you have issues, test on the official image".
crashoverride
 
Posts: 3101
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1

Re: Getting UAS working on HK 4.9

Unread postby rooted » Fri Apr 28, 2017 8:15 pm

Because Linux is not just a kernel, he is simply offering a suggestion that worked for him.

I'm running Debian with the latest 4.9.y from git and have issues with USB 3 still, technically it's USB to SATA in the CloudShell but all USB3 drives are using an adapter internally.
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 tkaiser » Sat Apr 29, 2017 1:56 am

tmihai20 wrote:Upgrading to the latest kernel should fix the issues on tkaiser's debian image as well.


Ok, the image has been built 8 days ago, just look at the timestamps: http://kaiser-edv.de/tmp/NumpU8/

In Armbian part of image creation is checking out latest kernel sources and building the kernel before debootstrapping Ubuntu or Debian from scratch. Now let's look at the commit history so we know what might be missing: https://github.com/hardkernel/linux/commits/odroidxu4-4.9.y

The branches I chose with the OMV builds are those we officially support for exactly one reason: Upstream kernel fixes will be automagically integrated into next Armbian major release and are then available through 'apt upgrade' -- so if there are real USB3 issues as soon as they get fixed in HK kernel they will appear some weeks later in these OMV installations too.

I'm out from now on since it gets a bit too absurd (blaming software for hardware flaws and believing in Voodoo like IRQ affinity would have more of an influence on USB misbehaviour than cheap/bad cabling/contacts :lol: )
tkaiser
 
Posts: 119
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 » Sat Apr 29, 2017 11:27 am

tkaiser wrote:blaming software for hardware flaws and believing in Voodoo

Testing with the official image reduces the problem set. Once the problem area has been narrowed, we have a better understand where unicorn spit needs to be applied to correct the issue(s).

I do development on the XU4 itself. Since I often need to re-flash the OS, I keep all source code and data on an external USB3 HDD. The HDD is plugged directly into the bottom USB3 port of the XU4 using the cable provided with the drive. On the top USB3, I have a (cheap) USB3 hub plugged in where I attach keyboard/mouse and other miscellaneous devices as needed. On the back USB2 port, I have a (cheap) CSR Bluetooth 4 adapter plugged in.

I routinely compile the linux kernel using the above setup. The repo is a 2G download. Compiling from new or after 'make clean' take a significant amount of time during which the HDD is in constant operation reading and writing. I have not observed any USB related errors during this process with a recent official Ubuntu image and kernel/device tree. This is in contrast to my early efforts where USB errors were seen using an older kernel version. Since the hardware in use has not changed, this narrows the issue to the kernel/OS/environment and/or the chicken sacrifice[*].

[*] Chicken sacrifices should only be attempted by certified, trained professionals using proper safety equipment and practices following all applicable guidelines.

[edit]
The HDD is using the EXT4 filesystem with journaling enabled. I have also used a different HDD (requiring external power supply) with LVM + XFS filesystem without issue.

[edit2]
Ironically, at this very moment I now have USB HDD errors. There are indeed mystical voodoo forces at work!
Code: Select all
[18760.179839] sd 0:0:0:0: [sda] tag#0 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD IN
[18760.179896] sd 0:0:0:0: [sda] tag#0 CDB: opcode=0x28 28 00 c6 46 ff 28 00 00 08 00
[18796.004838] sd 0:0:0:0: [sda] tag#1 uas_eh_abort_handler 0 uas-tag 2 inflight: CMD IN
[18796.004877] sd 0:0:0:0: [sda] tag#1 CDB: opcode=0x28 28 00 c6 47 00 c8 00 00 18 00
[18796.005134] scsi host0: uas_eh_bus_reset_handler start
[18796.007112] sd 0:0:0:0: [sda] tag#2 uas_zap_pending 0 uas-tag 3 inflight: CMD
[18796.007144] sd 0:0:0:0: [sda] tag#2 CDB: opcode=0x35 35 00 00 00 00 00 00 00 00 00
[18796.007180] sd 0:0:0:0: [sda] tag#3 uas_zap_pending 0 uas-tag 4 inflight: CMD
[18796.007209] sd 0:0:0:0: [sda] tag#3 CDB: opcode=0x28 28 00 c6 46 c2 c8 00 00 08 00
[18796.007242] sd 0:0:0:0: [sda] tag#4 uas_zap_pending 0 uas-tag 5 inflight: CMD
[18796.007268] sd 0:0:0:0: [sda] tag#4 CDB: opcode=0x28 28 00 c6 46 cd e0 00 00 08 00
[18796.007300] sd 0:0:0:0: [sda] tag#5 uas_zap_pending 0 uas-tag 6 inflight: CMD
[18796.007327] sd 0:0:0:0: [sda] tag#5 CDB: opcode=0x28 28 00 c6 46 ce 20 00 00 08 00
[18796.007358] sd 0:0:0:0: [sda] tag#6 uas_zap_pending 0 uas-tag 7 inflight: CMD
[18796.007383] sd 0:0:0:0: [sda] tag#6 CDB: opcode=0x28 28 00 c6 46 cd e8 00 00 08 00
[18796.007415] sd 0:0:0:0: [sda] tag#7 uas_zap_pending 0 uas-tag 8 inflight: CMD
[18796.007440] sd 0:0:0:0: [sda] tag#7 CDB: opcode=0x28 28 00 c6 46 c2 88 00 00 08 00
[18796.007472] sd 0:0:0:0: [sda] tag#8 uas_zap_pending 0 uas-tag 9 inflight: CMD
[18796.007496] sd 0:0:0:0: [sda] tag#8 CDB: opcode=0x28 28 00 c6 46 ce 10 00 00 08 00
[18796.007529] sd 0:0:0:0: [sda] tag#9 uas_zap_pending 0 uas-tag 10 inflight: CMD
[18796.007554] sd 0:0:0:0: [sda] tag#9 CDB: opcode=0x2a 2a 00 c1 44 d8 f8 00 00 08 00
[18796.089846] usb 4-1.2: reset SuperSpeed USB device number 4 using xhci-hcd
[18796.114231] scsi host0: uas_eh_bus_reset_handler success
[18829.299875] sd 0:0:0:0: [sda] tag#7 uas_eh_abort_handler 0 uas-tag 8 inflight: CMD IN
[18829.299915] sd 0:0:0:0: [sda] tag#7 CDB: opcode=0x28 28 00 c6 46 ce a8 00 00 08 00
[18829.300131] sd 0:0:0:0: [sda] tag#6 uas_eh_abort_handler 0 uas-tag 7 inflight: CMD IN
[18829.300162] sd 0:0:0:0: [sda] tag#6 CDB: opcode=0x28 28 00 c6 46 ce 90 00 00 10 00
[18829.300345] sd 0:0:0:0: [sda] tag#5 uas_eh_abort_handler 0 uas-tag 6 inflight: CMD IN
[18829.300373] sd 0:0:0:0: [sda] tag#5 CDB: opcode=0x28 28 00 c6 46 ce 80 00 00 10 00
[18829.300553] sd 0:0:0:0: [sda] tag#4 uas_eh_abort_handler 0 uas-tag 5 inflight: CMD IN
[18829.300582] sd 0:0:0:0: [sda] tag#4 CDB: opcode=0x28 28 00 c6 46 ce 60 00 00 10 00
[18829.300758] sd 0:0:0:0: [sda] tag#3 uas_eh_abort_handler 0 uas-tag 4 inflight: CMD IN
[18829.300785] sd 0:0:0:0: [sda] tag#3 CDB: opcode=0x28 28 00 c6 46 ce e8 00 00 08 00
[18829.300950] sd 0:0:0:0: [sda] tag#2 uas_eh_abort_handler 0 uas-tag 3 inflight: CMD IN
[18829.300978] sd 0:0:0:0: [sda] tag#2 CDB: opcode=0x28 28 00 c6 47 01 c0 00 00 08 00
[18829.301140] sd 0:0:0:0: [sda] tag#1 uas_eh_abort_handler 0 uas-tag 2 inflight: CMD IN
[18829.301167] sd 0:0:0:0: [sda] tag#1 CDB: opcode=0x28 28 00 c6 46 ce e0 00 00 08 00
[18829.301326] sd 0:0:0:0: [sda] tag#0 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD IN
[18829.301353] sd 0:0:0:0: [sda] tag#0 CDB: opcode=0x28 28 00 c6 46 cf d8 00 00 08 00
[18860.005062] sd 0:0:0:0: [sda] tag#8 uas_eh_abort_handler 0 uas-tag 9 inflight: CMD OUT
[18860.005123] sd 0:0:0:0: [sda] tag#8 CDB: opcode=0x2a 2a 00 74 44 1c 88 00 00 68 00
[18860.005439] scsi host0: uas_eh_bus_reset_handler start
[18860.090187] usb 4-1.2: reset SuperSpeed USB device number 4 using xhci-hcd
[18860.116444] scsi host0: uas_eh_bus_reset_handler success
[18893.299884] sd 0:0:0:0: [sda] tag#0 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD IN
[18893.299942] sd 0:0:0:0: [sda] tag#0 CDB: opcode=0x28 28 00 c6 46 b6 18 00 00 08 00
[18924.004963] sd 0:0:0:0: [sda] tag#1 uas_eh_abort_handler 0 uas-tag 2 inflight: CMD
[18924.005004] sd 0:0:0:0: [sda] tag#1 CDB: opcode=0x35 35 00 00 00 00 00 00 00 00 00
[18924.005051] scsi host0: uas_eh_bus_reset_handler start
[18924.007055] sd 0:0:0:0: [sda] tag#2 uas_zap_pending 0 uas-tag 3 inflight: CMD
[18924.007092] sd 0:0:0:0: [sda] tag#2 CDB: opcode=0x28 28 00 c6 46 cf 60 00 00 10 00
[18924.007129] sd 0:0:0:0: [sda] tag#3 uas_zap_pending 0 uas-tag 4 inflight: CMD
[18924.007157] sd 0:0:0:0: [sda] tag#3 CDB: opcode=0x28 28 00 c6 46 cf 80 00 00 10 00
[18924.007191] sd 0:0:0:0: [sda] tag#4 uas_zap_pending 0 uas-tag 5 inflight: CMD
[18924.007217] sd 0:0:0:0: [sda] tag#4 CDB: opcode=0x28 28 00 c6 46 cf 90 00 00 08 00
[18924.007248] sd 0:0:0:0: [sda] tag#5 uas_zap_pending 0 uas-tag 6 inflight: CMD
[18924.007274] sd 0:0:0:0: [sda] tag#5 CDB: opcode=0x28 28 00 c6 46 cf a0 00 00 08 00
[18924.007306] sd 0:0:0:0: [sda] tag#6 uas_zap_pending 0 uas-tag 7 inflight: CMD
[18924.007331] sd 0:0:0:0: [sda] tag#6 CDB: opcode=0x28 28 00 c6 46 cf b0 00 00 10 00
[18924.007362] sd 0:0:0:0: [sda] tag#7 uas_zap_pending 0 uas-tag 8 inflight: CMD
[18924.007388] sd 0:0:0:0: [sda] tag#7 CDB: opcode=0x28 28 00 c6 46 cf c8 00 00 08 00
[18924.089963] usb 4-1.2: reset SuperSpeed USB device number 4 using xhci-hcd
[18924.115505] scsi host0: uas_eh_bus_reset_handler success
[19487.220012] sd 0:0:0:0: [sda] tag#0 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD IN
[19487.220069] sd 0:0:0:0: [sda] tag#0 CDB: opcode=0x28 28 00 c6 44 44 d0 00 01 d0 00
[19491.045031] sd 0:0:0:0: [sda] tag#2 uas_eh_abort_handler 0 uas-tag 3 inflight: CMD OUT
[19491.045069] sd 0:0:0:0: [sda] tag#2 CDB: opcode=0x2a 2a 00 c6 04 d0 90 00 01 90 00
[19491.045309] scsi host0: uas_eh_bus_reset_handler start
[19491.046040] sd 0:0:0:0: [sda] tag#1 uas_zap_pending 0 uas-tag 2 inflight: CMD
[19491.046071] sd 0:0:0:0: [sda] tag#1 CDB: opcode=0x28 28 00 c6 04 c3 d8 00 00 08 00
[19491.046105] sd 0:0:0:0: [sda] tag#3 uas_zap_pending 0 uas-tag 4 inflight: CMD
[19491.046131] sd 0:0:0:0: [sda] tag#3 CDB: opcode=0x2a 2a 00 c6 45 1e 28 00 00 18 00
[19491.125231] usb 4-1.2: reset SuperSpeed USB device number 4 using xhci-hcd
[19491.153319] scsi host0: uas_eh_bus_reset_handler success
[19525.299980] sd 0:0:0:0: [sda] tag#0 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD IN
[19525.300019] sd 0:0:0:0: [sda] tag#0 CDB: opcode=0x28 28 00 c6 04 a6 60 00 00 28 00
[19530.085096] sd 0:0:0:0: [sda] tag#1 uas_eh_abort_handler 0 uas-tag 2 inflight: CMD OUT
[19530.085134] sd 0:0:0:0: [sda] tag#1 CDB: opcode=0x2a 2a 00 74 44 21 48 00 00 60 00
[19530.085301] scsi host0: uas_eh_bus_reset_handler start
[19530.170168] usb 4-1.2: reset SuperSpeed USB device number 4 using xhci-hcd
[19530.198639] scsi host0: uas_eh_bus_reset_handler success
[19566.579970] sd 0:0:0:0: [sda] tag#0 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD IN
[19566.580009] sd 0:0:0:0: [sda] tag#0 CDB: opcode=0x28 28 00 c6 44 7d e0 00 00 20 00
[19566.580351] scsi host0: uas_eh_bus_reset_handler start
[19566.660241] usb 4-1.2: reset SuperSpeed USB device number 4 using xhci-hcd
[19566.685045] scsi host0: uas_eh_bus_reset_handler success
[19598.260042] sd 0:0:0:0: [sda] tag#0 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD IN
[19598.260099] sd 0:0:0:0: [sda] tag#0 CDB: opcode=0x28 28 00 c6 44 5b e8 00 00 08 00
[19598.260456] scsi host0: uas_eh_bus_reset_handler start
[19598.345115] usb 4-1.2: reset SuperSpeed USB device number 4 using xhci-hcd
[19598.369023] scsi host0: uas_eh_bus_reset_handler success
[19630.259990] sd 0:0:0:0: [sda] tag#0 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD IN
[19630.260031] sd 0:0:0:0: [sda] tag#0 CDB: opcode=0x28 28 00 c6 44 61 d0 00 00 10 00
[19666.405200] sd 0:0:0:0: [sda] tag#2 uas_eh_abort_handler 0 uas-tag 3 inflight: CMD IN
[19666.405258] sd 0:0:0:0: [sda] tag#2 CDB: opcode=0x28 28 00 c6 44 72 f0 00 00 08 00
[19666.405540] scsi host0: uas_eh_bus_reset_handler start
[19666.407822] sd 0:0:0:0: [sda] tag#1 uas_zap_pending 0 uas-tag 2 inflight: CMD
[19666.407868] sd 0:0:0:0: [sda] tag#1 CDB: opcode=0x35 35 00 00 00 00 00 00 00 00 00
[19666.407917] sd 0:0:0:0: [sda] tag#3 uas_zap_pending 0 uas-tag 4 inflight: CMD
[19666.407956] sd 0:0:0:0: [sda] tag#3 CDB: opcode=0x28 28 00 c6 44 73 00 00 00 18 00
[19666.408002] sd 0:0:0:0: [sda] tag#4 uas_zap_pending 0 uas-tag 5 inflight: CMD
[19666.408039] sd 0:0:0:0: [sda] tag#4 CDB: opcode=0x28 28 00 c6 44 73 20 00 00 08 00
[19666.408087] sd 0:0:0:0: [sda] tag#5 uas_zap_pending 0 uas-tag 6 inflight: CMD
[19666.408124] sd 0:0:0:0: [sda] tag#5 CDB: opcode=0x28 28 00 c6 44 73 30 00 00 08 00
[19666.408171] sd 0:0:0:0: [sda] tag#6 uas_zap_pending 0 uas-tag 7 inflight: CMD
[19666.408206] sd 0:0:0:0: [sda] tag#6 CDB: opcode=0x28 28 00 c6 44 73 40 00 00 08 00
[19666.408251] sd 0:0:0:0: [sda] tag#7 uas_zap_pending 0 uas-tag 8 inflight: CMD
[19666.408288] sd 0:0:0:0: [sda] tag#7 CDB: opcode=0x28 28 00 c6 44 73 50 00 00 10 00
[19666.408332] sd 0:0:0:0: [sda] tag#8 uas_zap_pending 0 uas-tag 9 inflight: CMD
[19666.408368] sd 0:0:0:0: [sda] tag#8 CDB: opcode=0x28 28 00 c6 44 73 70 00 00 10 00
[19666.490369] usb 4-1.2: reset SuperSpeed USB device number 4 using xhci-hcd
[19666.516944] scsi host0: uas_eh_bus_reset_handler success
crashoverride
 
Posts: 3101
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1

Re: Getting UAS working on HK 4.9

Unread postby rooted » Sat Apr 29, 2017 12:14 pm

crashoverride wrote:I routinely compile the linux kernel using the above setup. The repo is a 2G download. Compiling from new or after 'make clean' take a significant amount of time during which the HDD is in constant operation reading and writing. I have not observed any USB related errors during this process with a recent official Ubuntu image and kernel/device tree. This is in contrast to my early efforts where USB errors were seen using an older kernel version. Since the hardware in use has not changed, this narrows the issue to the kernel/OS/environment and/or the chicken sacrifice[*].


This is exactly what I was doing when my external drive became unreadable. I pulled the git to my eMMC and compiled no problem.

I was on Debian running 4.9.y from hardkernel git, HMP disabled.
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 crashoverride » Sat Apr 29, 2017 12:18 pm

SMART has reported a read failure on my HDD. This may account for the USB error.
crashoverride
 
Posts: 3101
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1

Re: Getting UAS working on HK 4.9

Unread postby rooted » Sat Apr 29, 2017 12:19 pm

crashoverride wrote:SMART has reported a read failure on my HDD. This may account for the USB error.

I broke my kernel and for some odd reason I can't get my backup to boot fully.

I think it's my drive as well, got to take the top off the CloudShell and unplug it to see.
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 crashoverride » Sat Apr 29, 2017 5:25 pm

I have confirmed that my HDD has medium errors:
Code: Select all
$ sudo smartctl -t long /dev/sda

# (A long time later)

$ sudo smartctl -l selftest /dev/sda
=== START OF READ SMART DATA SECTION ===
SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Extended offline    Completed: read failure       90%      2135         30309408


Code: Select all
$ sudo dd if=/dev/sda of=/dev/null bs=512 count=1 skip=30309408
dd: error reading '/dev/sda': Input/output error
0+0 records in
0+0 records out
0 bytes copied, 8.22261 s, 0.0 kB/s


My theory is the USB errors seen are likely the SCSI commands timing out as the HDD controller attempts to read blocks that are in the process of failing.
crashoverride
 
Posts: 3101
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1

Re: Getting UAS working on HK 4.9

Unread postby rooted » Sat Apr 29, 2017 6:52 pm

What do you think caused your drive to begin failing? Or is that filesystem?
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 crashoverride » Sat Apr 29, 2017 7:14 pm

rooted wrote:What do you think caused your drive to begin failing?

My guess would be Linux kernel development! :shock:

The dev cycle usually means my board(s) lock up often. I have to cycle power often since there is no reset button on Odroids . As the HDD is USB powered, there is a lot of wear and tear on the hardware. This is why I put "reset button" on the "wish list" thread for Odroid-C3.

--- fun info follows. do not attempt at home. it will destroy your data. ---

SMART tests and reports errors on the HDD. The error I have is media related: sectors can not be read. All modern HDDs have "reserved" blocks that can be mapped over bad blocks. The HDD will only remap a bad block when a write operation fails. SMART reports this in the "Current_Pending_Sector" attribute.
Code: Select all
197 Current_Pending_Sector  0x0032   100   100   000    Old_age   Always       -       1


The failing sector number is show in the report:
Code: Select all
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Extended offline    Completed: read failure       90%      2135         30309408


Forcing a write of the sector causes the HDD to remap it:
Code: Select all
 dd if=/dev/zero of=/dev/sda bs=512 count=1 seek=30309408


Repeating the selftest shows the next bad sector. Repeating the above procedure for each bad sector reported causes them to be remapped:
Code: Select all
=== START OF READ SMART DATA SECTION ===
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%      2137         -

And my HDD is good as new! (there were only a few bad sectors)
crashoverride
 
Posts: 3101
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1

Re: Getting UAS working on HK 4.9

Unread postby mad_ady » Sat Apr 29, 2017 7:31 pm

Hmm, I never knew sectors were remapped only on write... Thanks
User avatar
mad_ady
 
Posts: 2741
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 rooted » Sat Apr 29, 2017 8:06 pm

I didn't either, I always abuse my drives until they die without thought of maintenance...now I know something to look for.

But seems I always wear out the bearings before anything else, I tend to leave my drives spinning all the time out of old habit.

I have no issue compiling the kernel from eMMC, never had a single failure like spinning media. I don't usually compile anything larger and I don't use swap.
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 crashoverride » Sat Apr 29, 2017 11:59 pm

Since I had to reformat my HDD, I decided to use the opportunity to experiment. I found a simple test that will reliably fault:
Code: Select all
$ sudo dd if=/dev/zero of=/dev/sdb bs=4M status=progress

Code: Select all
[  188.626557] sd 6:0:0:0: [sdb] Spinning up disk...
[  189.661724] ...ready
[  191.710039] sd 6:0:0:0: [sdb] 3907029167 512-byte logical blocks: (2.00 TB/1.82 TiB)
[  191.961363] sd 6:0:0:0: [sdb] Write Protect is off
[  191.961368] sd 6:0:0:0: [sdb] Mode Sense: 4f 00 00 00
[  191.961610] sd 6:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[  191.980875] sd 6:0:0:0: [sdb] Attached SCSI disk
[  225.922456] sd 6:0:0:0: [sdb] tag#9 data cmplt err -71 uas-tag 10 inflight: CMD
[  225.922459] sd 6:0:0:0: [sdb] tag#9 CDB: Write(10) 2a 00 00 00 24 00 00 04 00 00
[  225.925948] xhci_hcd 0000:00:14.0: ERROR Transfer event for disabled endpoint or incorrect stream ring
[  225.925953] xhci_hcd 0000:00:14.0: @000000026c1905a0 00000000 00000000 04000000 09048001
[  256.613127] sd 6:0:0:0: [sdb] tag#8 uas_eh_abort_handler 0 uas-tag 9 inflight: CMD OUT
[  256.613134] sd 6:0:0:0: [sdb] tag#8 CDB: Write(10) 2a 00 00 00 90 00 00 04 00 00
[  256.613224] sd 6:0:0:0: [sdb] tag#7 uas_eh_abort_handler 0 uas-tag 8 inflight: CMD OUT
[  256.613228] sd 6:0:0:0: [sdb] tag#7 CDB: Write(10) 2a 00 00 00 8c 00 00 04 00 00
[  256.613302] sd 6:0:0:0: [sdb] tag#6 uas_eh_abort_handler 0 uas-tag 7 inflight: CMD OUT
[  256.613305] sd 6:0:0:0: [sdb] tag#6 CDB: Write(10) 2a 00 00 00 88 00 00 04 00 00
[  256.613387] sd 6:0:0:0: [sdb] tag#5 uas_eh_abort_handler 0 uas-tag 6 inflight: CMD OUT
[  256.613390] sd 6:0:0:0: [sdb] tag#5 CDB: Write(10) 2a 00 00 00 84 00 00 04 00 00
[  256.613469] sd 6:0:0:0: [sdb] tag#4 uas_eh_abort_handler 0 uas-tag 5 inflight: CMD OUT
[  256.613472] sd 6:0:0:0: [sdb] tag#4 CDB: Write(10) 2a 00 00 00 80 00 00 04 00 00
[  256.613552] sd 6:0:0:0: [sdb] tag#3 uas_eh_abort_handler 0 uas-tag 4 inflight: CMD OUT
[  256.613555] sd 6:0:0:0: [sdb] tag#3 CDB: Write(10) 2a 00 00 00 7c 00 00 04 00 00
[  256.613635] sd 6:0:0:0: [sdb] tag#27 uas_eh_abort_handler 0 uas-tag 28 inflight: CMD OUT
[  256.613639] sd 6:0:0:0: [sdb] tag#27 CDB: Write(10) 2a 00 00 00 78 00 00 04 00 00
[  256.613719] sd 6:0:0:0: [sdb] tag#26 uas_eh_abort_handler 0 uas-tag 27 inflight: CMD OUT
[  256.613722] sd 6:0:0:0: [sdb] tag#26 CDB: Write(10) 2a 00 00 00 74 00 00 04 00 00
[  256.613802] sd 6:0:0:0: [sdb] tag#25 uas_eh_abort_handler 0 uas-tag 26 inflight: CMD OUT
[  256.613805] sd 6:0:0:0: [sdb] tag#25 CDB: Write(10) 2a 00 00 00 70 00 00 04 00 00
[  256.613879] sd 6:0:0:0: [sdb] tag#24 uas_eh_abort_handler 0 uas-tag 25 inflight: CMD OUT
[  256.613882] sd 6:0:0:0: [sdb] tag#24 CDB: Write(10) 2a 00 00 00 6c 00 00 04 00 00
[  256.613955] sd 6:0:0:0: [sdb] tag#23 uas_eh_abort_handler 0 uas-tag 24 inflight: CMD OUT
[  256.613958] sd 6:0:0:0: [sdb] tag#23 CDB: Write(10) 2a 00 00 00 68 00 00 04 00 00
[  256.614030] sd 6:0:0:0: [sdb] tag#22 uas_eh_abort_handler 0 uas-tag 23 inflight: CMD OUT
[  256.614033] sd 6:0:0:0: [sdb] tag#22 CDB: Write(10) 2a 00 00 00 64 00 00 04 00 00
[  256.614106] sd 6:0:0:0: [sdb] tag#21 uas_eh_abort_handler 0 uas-tag 22 inflight: CMD OUT
[  256.614109] sd 6:0:0:0: [sdb] tag#21 CDB: Write(10) 2a 00 00 00 60 00 00 04 00 00
[  256.614180] sd 6:0:0:0: [sdb] tag#20 uas_eh_abort_handler 0 uas-tag 21 inflight: CMD OUT
[  256.614184] sd 6:0:0:0: [sdb] tag#20 CDB: Write(10) 2a 00 00 00 5c 00 00 04 00 00
[  256.614255] sd 6:0:0:0: [sdb] tag#19 uas_eh_abort_handler 0 uas-tag 20 inflight: CMD OUT
[  256.614258] sd 6:0:0:0: [sdb] tag#19 CDB: Write(10) 2a 00 00 00 58 00 00 04 00 00
[  256.614328] sd 6:0:0:0: [sdb] tag#18 uas_eh_abort_handler 0 uas-tag 19 inflight: CMD OUT
[  256.614332] sd 6:0:0:0: [sdb] tag#18 CDB: Write(10) 2a 00 00 00 54 00 00 04 00 00
[  256.614401] sd 6:0:0:0: [sdb] tag#2 uas_eh_abort_handler 0 uas-tag 3 inflight: CMD OUT
[  256.614404] sd 6:0:0:0: [sdb] tag#2 CDB: Write(10) 2a 00 00 00 50 00 00 04 00 00
[  256.614476] sd 6:0:0:0: [sdb] tag#17 uas_eh_abort_handler 0 uas-tag 18 inflight: CMD OUT
[  256.614479] sd 6:0:0:0: [sdb] tag#17 CDB: Write(10) 2a 00 00 00 4c 00 00 04 00 00
[  256.614550] sd 6:0:0:0: [sdb] tag#16 uas_eh_abort_handler 0 uas-tag 17 inflight: CMD OUT
[  256.614553] sd 6:0:0:0: [sdb] tag#16 CDB: Write(10) 2a 00 00 00 48 00 00 04 00 00
[  256.614625] sd 6:0:0:0: [sdb] tag#1 uas_eh_abort_handler 0 uas-tag 2 inflight: CMD OUT
[  256.614628] sd 6:0:0:0: [sdb] tag#1 CDB: Write(10) 2a 00 00 00 44 00 00 04 00 00
[  256.614696] sd 6:0:0:0: [sdb] tag#0 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD OUT
[  256.614700] sd 6:0:0:0: [sdb] tag#0 CDB: Write(10) 2a 00 00 00 40 00 00 04 00 00
[  256.614770] sd 6:0:0:0: [sdb] tag#15 uas_eh_abort_handler 0 uas-tag 16 inflight: CMD OUT
[  256.614773] sd 6:0:0:0: [sdb] tag#15 CDB: Write(10) 2a 00 00 00 3c 00 00 04 00 00
[  256.614843] sd 6:0:0:0: [sdb] tag#14 uas_eh_abort_handler 0 uas-tag 15 inflight: CMD OUT
[  256.614847] sd 6:0:0:0: [sdb] tag#14 CDB: Write(10) 2a 00 00 00 38 00 00 04 00 00
[  256.614915] sd 6:0:0:0: [sdb] tag#13 uas_eh_abort_handler 0 uas-tag 14 inflight: CMD OUT
[  256.614918] sd 6:0:0:0: [sdb] tag#13 CDB: Write(10) 2a 00 00 00 34 00 00 04 00 00
[  256.614985] sd 6:0:0:0: [sdb] tag#12 uas_eh_abort_handler 0 uas-tag 13 inflight: CMD OUT
[  256.614989] sd 6:0:0:0: [sdb] tag#12 CDB: Write(10) 2a 00 00 00 30 00 00 04 00 00
[  256.615057] sd 6:0:0:0: [sdb] tag#11 uas_eh_abort_handler 0 uas-tag 12 inflight: CMD OUT
[  256.615060] sd 6:0:0:0: [sdb] tag#11 CDB: Write(10) 2a 00 00 00 2c 00 00 04 00 00
[  256.615129] sd 6:0:0:0: [sdb] tag#10 uas_eh_abort_handler 0 uas-tag 11 inflight: CMD OUT
[  256.615132] sd 6:0:0:0: [sdb] tag#10 CDB: Write(10) 2a 00 00 00 28 00 00 04 00 00
[  256.615201] sd 6:0:0:0: [sdb] tag#9 uas_eh_abort_handler 0 uas-tag 10 inflight: CMD
[  256.615204] sd 6:0:0:0: [sdb] tag#9 CDB: Write(10) 2a 00 00 00 24 00 00 04 00 00
[  256.615264] scsi host6: uas_eh_bus_reset_handler start
[  256.737346] usb 2-1: reset SuperSpeed USB device number 3 using xhci_hcd
[  256.763224] scsi host6: uas_eh_bus_reset_handler success
[  256.947084] sd 6:0:0:0: [sdb] tag#14 data cmplt err -71 uas-tag 15 inflight: CMD
[  256.947092] sd 6:0:0:0: [sdb] tag#14 CDB: Write(10) 2a 00 00 00 58 00 00 04 00 00
[  256.950407] xhci_hcd 0000:00:14.0: ERROR Transfer event for disabled endpoint or incorrect stream ring
[  256.950418] xhci_hcd 0000:00:14.0: @000000026c1901c0 00000000 00000000 04000000 09048000


So what is interesting about the above? Its from a Core i5 PC, not an XU4. It faults identically on both.

So what can we infer from this? UAS is just broken on Linux. :lol:
(Above test was conducted on Ubuntu Gnome 16.04 : Linux PC 4.8.0-49-generic #52~16.04.1-Ubuntu SMP Thu Apr 20 10:55:59 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux)
crashoverride
 
Posts: 3101
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1

Re: Getting UAS working on HK 4.9

Unread postby tkaiser » Sun Apr 30, 2017 1:05 am

With how many different harddisks did you try to proof that 'UAS is just broken on Linux'? Still only the one that is already failing or at least 3 different disks in 3 different UAS capable enclosures?

Just some examples:

* http://www.spinics.net/lists/linux-usb/msg119432.html
* http://www.cnx-software.com/2017/03/16/suptronics-x800-2-5-sata-drive-expansion-board-and-cases-for-raspberry-pi-23-and-odroid-c2-boards/#comment-540247
* https://www.smartmontools.org/ticket/552#comment:6

So we have hardware vendors that are too stupid to allow differentiation of their different chipsets (some of them totally broken, some partially, others just slightly), we have completely broken chips that are known to destroy data (this horrible GL830 thingie for example), we have 'firmware' updates that fix stuff and we have some updates that break stuff. Then we have a mindset on the user side to not care about any details and buy the cheapest stuff possible. So we're dealing with a confusing mixture of bad/broken hardware and software that tries to compensate somehow from some flaws and an amazing level of complexity paired with an also amazing high level of ignorance :)

And final conclusions then are amazingly simple: 'UAS is broken'. Great! ;)

Data I love or need receives special handling here which boils down to three principles:

* use reliable connection methods and equipment that allow monitoring of failures (that's CRC errors on the cables, media errors on storage and so on)
* reduce complexity (if you want to connect a disk to a host do it directly and not adding many layers of complexity. If you've a SATA disk, then search for a host featuring a SATA controller and let them talk directly, there's no need to add an USB-to-SATA bridge especially not behind an internal USB hub that features an amazing count of own problems)
* take care about data integrity (use only filesystems that allow end-to-end data integrity through checksums, let scrubs run regularly, let SMART selftests run, monitor SMART health data and act on accordingly)

Obviously an ODROID-XU4 especially when paired with USB3 storage + anachronistic filesystems like ext4 + stupid RAID implementation (RAID-1 on the Cloudshell 2) is quite the opposite :)

But if you combine the XU4 with USB-to-SATA bridges that are known to work well (JMS567 or ASM1153), use good/short cables and put a btrfs on it then this will also work well. I did a test using two JMS567 with two Samsung SSD using 'mkfs.btrfs -m raid1 -d raid0 /dev/sda1 /dev/sdb1' (data striped but metadata mirrored) and could even recover from worst case situation (unplugged one of the two USB enclosures while running a benchmark). Duplicated checksums allowed the filesystem to recover.
tkaiser
 
Posts: 119
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 » Sun Apr 30, 2017 1:32 am

tkaiser wrote:With how many different harddisks did you try to proof that 'UAS is just broken on Linux'?

I opened up the drive enclosure and removed the drive (Its a Samsung drive inside the Seagate enclosure). I removed the USB adapter board and connected it up via SATA to the same PC. I used the same command to test and its working perfectly.

The original premise was that this is an XU4 issue. The evidence so far strongly suggests it is not since its reproducible on "first class" Intel hardware. Therefore, there is nothing that be done to fix the issue on XU4 until its first fixed (or worked around) in Linux proper.

[edit]
See also:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1584557
crashoverride
 
Posts: 3101
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1

Re: Getting UAS working on HK 4.9

Unread postby crashoverride » Sun Apr 30, 2017 4:28 am

In another test I connected an Intel SSD drive to the USB3 to SATA adapter from the Seagate drive. Performing the /dev/zero copy test produces the same errors as with the Samsung drive originally connected. This should eliminate the "bad drive" (that works perfectly over SATA) from consideration.

[edit]
I create a MBR partition table with a single linux partition and formatted it as EXT4 checking for errors (read only). This completed without any USB errors:
Code: Select all
$ sudo mkfs.ext4 /dev/sda1 -c


I then started a copy from /dev/zero to a file on the filesystem. This also did not produce any USB errors:
Code: Select all
$ cp /dev/zero nothing

Code: Select all
$ sudo dd if=/dev/zero of=empty bs=4M


[edit 2]
Cloned and compile XU4 kernel without any USB errors.
crashoverride
 
Posts: 3101
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1

Re: Getting UAS working on HK 4.9

Unread postby crashoverride » Sun Apr 30, 2017 3:23 pm

To conclude this adventure:
1) Whether you are running a $6,000 Intel server or a $60 XU4, UAS works (or doesn't) identically. There is no XU4 specific UAS issue that I have found (using official kernel+config on official Ubuntu image). Failures are consistent on both x86-64 and XU4.
2) We need to allow end users to disable UAS. There is already an issue for this here: https://github.com/hardkernel/linux/issues/290

The information I based my personal conclusion is openly presented in this thread. Others are encourage to perform their own tests to validate or disprove my conclusion.
crashoverride
 
Posts: 3101
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1

Re: Getting UAS working on HK 4.9

Unread postby odroid » Sun Apr 30, 2017 3:35 pm

@crashoverride
Can you tell me the chipset in your USB-SATA bridge?
Anyway, we will change the UAS driver to a module after some tests.
User avatar
odroid
Site Admin
 
Posts: 24992
Joined: Fri Feb 22, 2013 11:14 pm
languages_spoken: English
ODROIDs: ODROID

Re: Getting UAS working on HK 4.9

Unread postby crashoverride » Sun Apr 30, 2017 3:48 pm

The chip is Asmedia ASM1153 (observed on the disassembled unit). It is customized by Seagate in the Seagate Expansion Portable Drive - 2TB
http://www.seagate.com/www-content/datasheets/pdfs/expansion-portable-ds1842-4-1509us.pdf
http://www.asmedia.com.tw/eng/e_show_products.php?item=132&
crashoverride
 
Posts: 3101
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1

Re: Getting UAS working on HK 4.9

Unread postby odroid » Sun Apr 30, 2017 3:52 pm

Thank you for the answer.
We will buy one and test it early next week.
User avatar
odroid
Site Admin
 
Posts: 24992
Joined: Fri Feb 22, 2013 11:14 pm
languages_spoken: English
ODROIDs: ODROID

Re: Getting UAS working on HK 4.9

Unread postby crashoverride » Sun Apr 30, 2017 4:17 pm

crashoverride wrote:2) We need to allow end users to disable UAS. There is already an issue for this here: https://github.com/hardkernel/linux/issues/290

I discovered you can do this as a parameter on the kernel command line in boot.ini
Code: Select all
usb-storage.quirks=0x0bc2:0x2322:u


Note that it is device specific. The numbers are the USB VID:PID of the device to disable UAS on:
Code: Select all
$ lsusb
Bus 004 Device 004: ID 0bc2:2322 Seagate RSS LLC


I tried blacklisting UAS, but the kernel does not not load any driver (mass storage) at all.
Code: Select all
modprobe.blacklist=uas
Last edited by crashoverride on Sun Apr 30, 2017 4:21 pm, edited 1 time in total.
crashoverride
 
Posts: 3101
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1

Re: Getting UAS working on HK 4.9

Unread postby crashoverride » Sun Apr 30, 2017 4:20 pm

crashoverride wrote:The chip is Asmedia ASM1153

https://github.com/hardkernel/linux/blob/odroidxu4-4.9.y/drivers/usb/storage/uas-detect.h#L78
Code: Select all
    * ASM1153 - with working uas support
crashoverride
 
Posts: 3101
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1

Re: Getting UAS working on HK 4.9

Unread postby odroid » Sun Apr 30, 2017 4:35 pm

Can you check the firmware version of your HDD enclosure?
Some people reported the ASM1153 issue could be resolved after firmware update.
User avatar
odroid
Site Admin
 
Posts: 24992
Joined: Fri Feb 22, 2013 11:14 pm
languages_spoken: English
ODROIDs: ODROID

Re: Getting UAS working on HK 4.9

Unread postby crashoverride » Sun Apr 30, 2017 4:40 pm

I did check the Seagate site, and they do not offer any firmware updates for the drive.
crashoverride
 
Posts: 3101
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1

PreviousNext

Return to Linux Kernel 4.14 Debugging Party

Who is online

Users browsing this forum: No registered users and 1 guest