Automatic Spin-Down of SATA Drive

gnulebin · Unread post by **gnulebin** » Sun Oct 01, 2017 9:47 pm

Hello,

I just received the HC1, and started with the setting up my "home NAS" ... but run into a potential issue ...

It seems that the HC1 triggers automatically a spin-down of the attached hard disk after 3 minutes of inactivity? I tried 2 different drives, and tested as well with the Ubuntu Image, and ArchLinux - same behavior.
The drives itself have no automatic spindown configured (verified with another system), so it must be triggered by the USB/SATA bridge on the HC1 I suspect.

So if this spindown is indeed triggered by the JMS578 chip used on the HC1, is there any known way how to disable this function, or to change the interval (30 min would be fine for me, but 3 min is way too short)?

Thanks,
Andreas.

mad_ady · Unread post by **mad_ady** » Mon Oct 02, 2017 3:51 am

What OS image are you using? It may be a setting from the GUI to put the drives to sleep when idle. Can you try with lightdm stopped or with the minimal image?

phaseshifter · Unread post by **phaseshifter** » Mon Oct 02, 2017 1:06 pm

this is the first instance i have seen of the fault you present....
i have to wonder if it is a hardware fault...

do you have a sufficient power supply connected to the hc1
e.g 4 amp 5 volt 20 w..or a 6 amp 30w

gnulebin · Unread post by **gnulebin** » Mon Oct 02, 2017 2:54 pm

Hi,

I tried with 2 different Images:
- Minimal Ubuntu (ubuntu-16.04.3-4.9-minimal-odroid-xu4-20170824.img.xz)
- Arch Linux ARM (ArchLinuxARM-odroid-xu3-latest.tar.gz, as of 2017-Sep-10)

I.e. there is no GUI running (and no "lightdm"), those should be pretty plain OS images. Also no "hd-idle" is installed. So I suspect that the spin-down is indeed triggered by the USB/SATA bridge chip, resp. it's firmware - like some drives in external USB enclosures do.

I tried also 2 different power supplies (with 4 Amps - one of it powers my XU4 with 2 drives connected without any problems).

After some search I found that the JMicron chip indeed has a spin-down (power Management) function, and seems the interval is defined in the firmware. But couldn't find if it is possible to change this parameter at all from Linux.

I would be curious to hear if other HC1 users made the same observation of a spin-down after 3 minutes - or do their drives remain up even after longer idle time (wondering if it is just my HC1 that might have a defect).

Thanks,
Andreas.

phaseshifter · Unread post by **phaseshifter** » Mon Oct 02, 2017 5:12 pm

have a look here..????

https://askubuntu.com/questions/891173/ ... d-in-16-04

gnulebin · Unread post by **gnulebin** » Mon Oct 02, 2017 9:47 pm

Hi phaseshifter,

Well, that talks about "hdparm" to configure ATA parameters and drive Status. I am familar with hdparm, and have indeed set the standby (spindown) timeout on my drives to 30 min with option -S 240.
And connected to another USB/SATA bridge (connected to my XU4), the drives correctly spindown after the configured 30 min.

So "hdparm" doesn't help here ... a timeout of more than 3 min set on the drive itself will never be reached, when the bridge chip or something else sends an idle command to the drive before.
Indeed I can set a timeout of less than 3 min (e.g. with hdparm -S 30 for 2.5 min), and then the drive will correctly spin down by itself.

I still suspect the bridge chip is causing this behavior ...

Andreas.

phaseshifter · Unread post by **phaseshifter** » Tue Oct 03, 2017 1:39 am

i suspect the same..

wait for odroid to see this post..it may be some time however..there on holidays atm....

Unread post by **odroid** » Tue Oct 03, 2017 12:59 pm

Can you show me hdparm -I /dev/sda output?
Let me know what happens with hdparm -B255 -S255 /dev/sda

gnulebin · Unread post by **gnulebin** » Tue Oct 03, 2017 6:37 pm

Hi odroid,

Thanks a lot already in advance for looking into this!

Please find below the "hdparm -I" output, after "hdparm -B255 -S255", from both Arch Linux and Ubuntu Minimal images. For Ubuntu I also included the output of "lsusb -v 4:2".

The drive spins down after 3 minutes of inactivity (maybe 5-10 seconds more) even after "hdparm -B255 -S255". The output of the commands is for a Fujitsu 500GB drive, but I tried before also a Toshiba 2TB drive (MA01ABB200) and an actual Seagate 4TB (ST4000LM024) - all show the same behavior when connected to the HC1. (And all 3 drives do not spin down when connected to a XU4 USB3 port via an external drive enclosure (which has an ASMedia USB/SATA Bridge).

Andreas.

Code: Select all

Arch Linux 4.9.51-1-ARCH (ttySAC2)

alarm login: root
Password:
Last login: Sun Oct  1 12:13:18 on ttySAC2
[root@alarm ~]# hdparm -B255 -S255 /dev/sda 2>/dev/null

/dev/sda:
 setting Advanced Power Management level to disabled
 setting standby to 255 (21 minutes + 15 seconds)
 APM_level      = off
[root@alarm ~]# hdparm -I /dev/sda 2>/dev/null

/dev/sda:

ATA device, with non-removable media
        Model Number:       FUJITSU MHZ2500BT G1
        Serial Number:      K701T8825FYR
        Firmware Revision:  0000000C
        Transport:          Serial, ATA8-AST, SATA 1.0a, SATA II Extensions, SATA Rev 2.5; Revision: ATA8-AST T13 Project D1697 Revision 0b
Standards:
        Used: ATA-8-ACS revision 3f
        Supported: 8 7 6 5
Configuration:
        Logical         max     current
        cylinders       16383   16383
        heads           16      16
        sectors/track   63      63
        --
        CHS current addressable sectors:    16514064
        LBA    user addressable sectors:   268435455
        LBA48  user addressable sectors:   976773168
        Logical  Sector size:                   512 bytes
        Physical Sector size:                   512 bytes
        device size with M = 1024*1024:      476940 MBytes
        device size with M = 1000*1000:      500107 MBytes (500 GB)
        cache/buffer size  = 8192 KBytes (type=DualPortCache)
Capabilities:
        LBA, IORDY(can be disabled)
        Queue depth: 32
        Standby timer values: spec'd by Standard, no device specific minimum
        R/W multiple sector transfer: Max = 16  Current = 16
        Advanced power management level: disabled
        Recommended acoustic management value: 254, current value: 254
        DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5
             Cycle time: min=120ns recommended=120ns
        PIO: pio0 pio1 pio2 pio3 pio4
             Cycle time: no flow control=120ns  IORDY flow control=120ns
Commands/features:
        Enabled Supported:
           *    SMART feature set
                Security Mode feature set
           *    Power Management feature set
           *    Write cache
           *    Look-ahead
                Host Protected Area feature set
           *    WRITE_BUFFER command
           *    READ_BUFFER command
           *    DOWNLOAD_MICROCODE
                Advanced Power Management feature set
                SET_MAX security extension
           *    Automatic Acoustic Management feature set
           *    48-bit Address feature set
           *    Device Configuration Overlay feature set
           *    Mandatory FLUSH_CACHE
           *    FLUSH_CACHE_EXT
           *    SMART error logging
           *    SMART self-test
           *    General Purpose Logging feature set
           *    WRITE_{DMA|MULTIPLE}_FUA_EXT
           *    64-bit World wide name
           *    IDLE_IMMEDIATE with UNLOAD
                Disable Data Transfer After Error Detection
           *    WRITE_UNCORRECTABLE_EXT command
           *    {READ,WRITE}_DMA_EXT_GPL commands
           *    Segmented DOWNLOAD_MICROCODE
           *    Gen1 signaling speed (1.5Gb/s)
           *    Native Command Queueing (NCQ)
           *    Host-initiated interface power management
           *    Phy event counters
                DMA Setup Auto-Activate optimization
                Device-initiated interface power management
                Software settings preservation
           *    SMART Command Transport (SCT) feature set
           *    SCT Write Same (AC2)
           *    SCT Error Recovery Control (AC3)
           *    SCT Features Control (AC4)
           *    SCT Data Tables (AC5)
Security:
        Master password revision code = 65534
                supported
        not     enabled
        not     locked
        not     frozen
        not     expired: security count
        not     supported: enhanced erase
        500min for SECURITY ERASE UNIT.
Logical Unit WWN Device Identifier: 500000e0427d68ce
        NAA             : 5
        IEEE OUI        : 00000e
        Unique ID       : 0427d68ce
Checksum: correct



Ubuntu 16.04.3 LTS odroid ttySAC2

odroid login: root
Password:
Last login: Tue Oct  3 08:44:26 UTC 2017 on ttySAC2
Welcome to Ubuntu 16.04.3 LTS (GNU/Linux 4.9.44-56 armv7l)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/advantage
root@odroid:~# hdparm -B255 -S255 /dev/sda

/dev/sda:
 setting Advanced Power Management level to disabled
 setting standby to 255 (21 minutes + 15 seconds)
 APM_level      = off
root@odroid:~# hdparm -I /dev/sda

/dev/sda:

ATA device, with non-removable media
        Model Number:       FUJITSU MHZ2500BT G1
        Serial Number:      K701T8825FYR
        Firmware Revision:  0000000C
        Transport:          Serial, ATA8-AST, SATA 1.0a, SATA II Extensions, SATA Rev 2.5; Revision: ATA8-AST T13 Project D1697 Revision 0b
Standards:
        Used: ATA-8-ACS revision 3f
        Supported: 8 7 6 5
Configuration:
        Logical         max     current
        cylinders       16383   16383
        heads           16      16
        sectors/track   63      63
        --
        CHS current addressable sectors:   16514064
        LBA    user addressable sectors:  268435455
        LBA48  user addressable sectors:  976773168
        Logical  Sector size:                   512 bytes
        Physical Sector size:                   512 bytes
        device size with M = 1024*1024:      476940 MBytes
        device size with M = 1000*1000:      500107 MBytes (500 GB)
        cache/buffer size  = 8192 KBytes (type=DualPortCache)
Capabilities:
        LBA, IORDY(can be disabled)
        Queue depth: 32
        Standby timer values: spec'd by Standard, no device specific minimum
        R/W multiple sector transfer: Max = 16  Current = 16
        Advanced power management level: disabled
        Recommended acoustic management value: 254, current value: 254
        DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5
             Cycle time: min=120ns recommended=120ns
        PIO: pio0 pio1 pio2 pio3 pio4
             Cycle time: no flow control=120ns  IORDY flow control=120ns
Commands/features:
        Enabled Supported:
           *    SMART feature set
                Security Mode feature set
           *    Power Management feature set
           *    Write cache
           *    Look-ahead
                Host Protected Area feature set
           *    WRITE_BUFFER command
           *    READ_BUFFER command
           *    DOWNLOAD_MICROCODE
                Advanced Power Management feature set
                SET_MAX security extension
           *    Automatic Acoustic Management feature set
           *    48-bit Address feature set
           *    Device Configuration Overlay feature set
           *    Mandatory FLUSH_CACHE
           *    FLUSH_CACHE_EXT
           *    SMART error logging
           *    SMART self-test
           *    General Purpose Logging feature set
           *    WRITE_{DMA|MULTIPLE}_FUA_EXT
           *    64-bit World wide name
           *    IDLE_IMMEDIATE with UNLOAD
                Disable Data Transfer After Error Detection
           *    WRITE_UNCORRECTABLE_EXT command
           *    {READ,WRITE}_DMA_EXT_GPL commands
           *    Segmented DOWNLOAD_MICROCODE
           *    Gen1 signaling speed (1.5Gb/s)
           *    Native Command Queueing (NCQ)
           *    Host-initiated interface power management
           *    Phy event counters
                DMA Setup Auto-Activate optimization
                Device-initiated interface power management
                Software settings preservation
           *    SMART Command Transport (SCT) feature set
           *    SCT Write Same (AC2)
           *    SCT Error Recovery Control (AC3)
           *    SCT Features Control (AC4)
           *    SCT Data Tables (AC5)
Security:
        Master password revision code = 65534
                supported
        not     enabled
        not     locked
        not     frozen
        not     expired: security count
        not     supported: enhanced erase
        500min for SECURITY ERASE UNIT.
Logical Unit WWN Device Identifier: 500000e0427d68ce
        NAA             : 5
        IEEE OUI        : 00000e
        Unique ID       : 0427d68ce
Checksum: correct
root@odroid:~# lsusb
Bus 006 Device 002: ID 0bda:8153 Realtek Semiconductor Corp.
Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 002: ID 152d:0578 JMicron Technology Corp. / JMicron USA Technology Corp.
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
root@odroid:~# lsusb -v -s 4:2

Bus 004 Device 002: ID 152d:0578 JMicron Technology Corp. / JMicron USA Technology Corp.
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               3.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0         9
  idVendor           0x152d JMicron Technology Corp. / JMicron USA Technology Corp.
  idProduct          0x0578
  bcdDevice            1.05
  iManufacturer           1 JMicron
  iProduct                2 USB to SATA bridge
  iSerial                 3 DB00000000013B
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength          121
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0xc0
      Self Powered
    MaxPower                2mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass         8 Mass Storage
      bInterfaceSubClass      6 SCSI
      bInterfaceProtocol     80 Bulk-Only
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0400  1x 1024 bytes
        bInterval               0
        bMaxBurst              15
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0400  1x 1024 bytes
        bInterval               0
        bMaxBurst              15
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       1
      bNumEndpoints           4
      bInterfaceClass         8 Mass Storage
      bInterfaceSubClass      6 SCSI
      bInterfaceProtocol     98
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x01  EP 1 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0400  1x 1024 bytes
        bInterval               0
        bMaxBurst               0
        Command pipe (0x01)
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0400  1x 1024 bytes
        bInterval               0
        bMaxBurst               0
        MaxStreams             32
        Status pipe (0x02)
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0400  1x 1024 bytes
        bInterval               0
        bMaxBurst              15
        MaxStreams             32
        Data-in pipe (0x03)
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x04  EP 4 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0400  1x 1024 bytes
        bInterval               0
        bMaxBurst               7
        MaxStreams             32
        Data-out pipe (0x04)
Binary Object Store Descriptor:
  bLength                 5
  bDescriptorType        15
  wTotalLength           22
  bNumDeviceCaps          2
  USB 2.0 Extension Device Capability:
    bLength                 7
    bDescriptorType        16
    bDevCapabilityType      2
    bmAttributes   0x00000f0e
      Link Power Management (LPM) Supported
  SuperSpeed USB Device Capability:
    bLength                10
    bDescriptorType        16
    bDevCapabilityType      3
    bmAttributes         0x00
    wSpeedsSupported   0x000e
      Device can operate at Full Speed (12Mbps)
      Device can operate at High Speed (480Mbps)
      Device can operate at SuperSpeed (5Gbps)
    bFunctionalitySupport   1
      Lowest fully-functional device speed is Full Speed (12Mbps)
    bU1DevExitLat          10 micro seconds
    bU2DevExitLat          32 micro seconds
Device Status:     0x0001
  Self Powered
root@odroid:~#

neal · Unread post by **neal** » Thu Oct 05, 2017 6:43 pm

How about this hd-idle tool? Did you try it?
# ./hd-idle -i 1800 /dev/sda

hd-idle.zip: (5.99 KiB) Downloaded 119 times

gnulebin · Unread post by **gnulebin** » Fri Oct 06, 2017 1:44 pm

Hi neal,

"hd-idle" will not help here ... "hd-idle -i 1800" would be a software-based alternative to "hdparm -S 241" - but the drive was sent to sleep and spun down already 27 minutes before by the USB/SATA bridge.

Andreas.

fvolk · Unread post by **fvolk** » Sun Oct 08, 2017 6:20 am

I also have the same problem, this makes the HC1 unusable for me

Ubuntu minimal 16.04.3,
4.9.52-66 with a WD10JPLX,
after 3 min idle drive goes to sleep,
hdparm -S xxx has no effect.

I have used this drive in many different settings/PCs, it has never done this before, it must be the HC1.

phaseshifter · Unread post by **phaseshifter** » Sun Oct 08, 2017 10:35 am

@ fvolk pls open your own thread we will help you ...

gnulebin · Unread post by **gnulebin** » Tue Oct 10, 2017 4:35 am

I found the following interesting forum posting by odroid: viewtopic.php?f=54&t=28041#p200016

It shows power consumption measurements of the HC1 in different operations states with a 5 TB 2.5" drive (I guess it must be a Seagate ST5000LM).
Also in that measurement the drive spins down after a little bit more than 3 minutes of idle time (similar to my finding of 3 minutes + 5-10 seconds).

There is no detailed Information on the exact setup, but assuming it was the standard Odroid Ubuntu image (especially without running "hdparm" or "hd-idle" in addition), it would confirm the behavior that I and fvolk encountered. (I tried a Seagate ST4000LM, as shipped that drive type doesn't spin down on its own)

Andreas.

tkaiser · Unread post by **tkaiser** » Tue Oct 10, 2017 8:42 pm

Another confirmation + workaround: https://forum.armbian.com/index.php?/to ... ment=41109

fvolk · Unread post by **fvolk** » Wed Oct 11, 2017 1:44 am

I also initially did not notice it because I created a new ext4 fs on the 1 TB. The mkfs.ext4 command returns immediately, but creating the fs structures on the whole disk is a background job of the kernel, which continues for quite some time. If that is not fully finished it just resumes next time the fs is mounted again until it is done.
However after creation of the fs there are no more accesses and then disk spins down after ~3 mins when idle. Always.

What I want to replicate on the HC1 is what works fine with the C2: A cronjob sets HD spin-down (via hdparm -S ...) at midnight to 30 mins and in the morning to 2 hours. This is perfect to keep the disk spinning when I'm working during the day or a script is running, but let it sleep on idle and even more quickly in the night.

A workaround with a cronjob is not acceptable, you get regular disruptions in your read/write operations.

tkaiser · Unread post by **tkaiser** » Wed Oct 11, 2017 2:04 am

fvolk wrote:A workaround with a cronjob is not acceptable, you get regular disruptions in your read/write operations.

Huh? No.

Curious how a 'solution' could look like since in case JMS578 is capable of firmware upgrades we'll need most probably a solder iron on HC1 to get this thing connected to a Windows box

I'm hoping for either some magic or Hardkernel providing a nice daemon as workaround acting intelligently using /proc/diskstats to do nothing if not necessary and do $something to keep a HDD spinning as long as the user wants and let it enter standby/sleeping state after an user defined amount of time ideally using a single/simple config file where we specify wanted spindown time in minutes (ideally not using the weird hdparm -S convention)

gnulebin · Unread post by **gnulebin** » Wed Oct 11, 2017 4:19 pm

Hi tkaiser,

Thanks a lot for the link to the armbian forum, and your review there ... an interesting thread also because of other Information provided ...

So seems the spin-down is indeed triggered by the JMS578 USB/SATA bridge, and sad to say that is a design flaw. The HC1 is intended especially for the use case of a NAS, and for that use case one don't want to have such behavior, or at least it should be configurable. (I can understand why manufacturers of external drives/enclosures want to have aggressive short spin-down times, as it might reduce the number of disk damages when users ignore the physics of mass inertia

)

A simple workaround to keep the drives spinning permanently through regular disk access is also not serving the needs, resp. it must have a more sophisticated solution that also checks for access counters as suggested. Of course might be possible.
Or there should be a way to upgrade the firmware of the JMS578 in-place under Linux, or do that already in the manufacturing process (seems there is a JMicron tool, but only for Windows as you indicated

)

For now I will stick myself to the XU4 and returned the HC1 ... luckily I have external enclosures that don't spin-down (that was also a past journey to find those), and so far I was not suffering from underpowering using external drives (maybe because the ones I have don't support UASP, that was my hope to improve with migrating to the HC1 ...)

Andreas.

tkaiser · Unread post by **tkaiser** » Wed Oct 11, 2017 6:21 pm

In the meantime I tested with another JMS578 [1] and there it's also the same: connected HDD spinning down after few minutes and hdparm -C not working correctly.

BTW: Underpowering is not related to UASP but more to... underpowering

[1] https://forum.armbian.com/index.php?/to ... ment=29569

fvolk · Unread post by **fvolk** » Thu Oct 12, 2017 2:13 am

Sending my HC1 back is not an option because what would I say "it works, yes, but well it doesn't work like expected, but ..."

More seriously, I'm thinking to use the cheapest old SSD I can buy and be happy with less space.
Anyone tested with a SSD yet and found any problems at the 3 mins with the sleep and resume, is it noticeable?

tkaiser · Unread post by **tkaiser** » Thu Oct 12, 2017 2:48 am

fvolk wrote:Anyone tested with a SSD yet and found any problems at the 3 mins with the sleep and resume, is it noticeable?

Huh? If you follow the links in this thread it should be obvious that I only tested with SSDs so far (otherwise I might have noticed the 'problem'). And why/how should SSDs be affected by stuff that affects only spinning rust? Most SSDs don't give a sh*t about the host trying to educate them about their behavior since they know they're not made of rotating platters not having to spin stuff up/down.

BTW: If Hardkernel folks (or someone else) would've realized this JMS578 behaviour a bit earlier I guess they would've simply written such a simple 'hc1-drive-spindown-behaviour' service combined with a small config file where you could adjust default sleep settings defaulting to 30 min and no one would've noticed.

At least I look forward to something like that to include it into next OMV image. Even better would be a more generic systemd service since then we could integrate this into an existing Armbian package and provide this for all OMV/Armbian users out there with next update (due in a few weeks). OMV downloads for XU4/HC1 have more than doubled since HC1 is available...

Unread post by **odroid** » Thu Oct 12, 2017 9:56 am

There are two known issues with JMS578 so far.
1. Uncontrollable storage sleep in 3 minutes
2. Trim function doesn't work

We reported those issues to JMicron and sent a toolchain to build a firmware update tool for XU4/HC1.
It may need a couple of weeks to have new firmware binary with update tool. Please be patient.

tkaiser · Unread post by **tkaiser** » Thu Oct 12, 2017 3:04 pm

That's good news! But 'hdparm -C' behaviour is also an issue since usually we (or our scripts/tools) use this to determine whether the drive is in standby/sleeping state or idle/active to determine to query it or not (eg. periodic SMART checks). With JMS578 now every hdparm -C query ends up waking up a connected disk and returns then 'unknown' instead of idle/active/standby/sleeping. I hope you report this to JMicron too.

Unread post by **odroid** » Thu Oct 12, 2017 3:15 pm

Thank you for the suggestion.
We will report the issue too.
But JMicron's response is quite slow and I don't like to interrupt them at this moment.
So the hdparm query issue will be fixed eventually.

tkaiser · Unread post by **tkaiser** » Thu Oct 12, 2017 4:07 pm

odroid wrote:But JMicron's response is quite slow and I don't like to interrupt them at this moment.
So the hdparm query issue will be fixed eventually.

It's directly related with the sleep issue (not only affecting -C for queries but of course also -y or -Y for example) so when JMicron wants to implement a proper fix for the sleep issue they must also fix the hdparm issue at the same time.

neal · Unread post by **neal** » Wed Nov 01, 2017 3:00 pm

JMS578 F/W updater under ODROID-HC1 is now available. and it also has the function of setting spin-down timer.
You can check through this link.
https://wiki.odroid.com/odroid-xu4/soft ... _fw_update

That's good news! But 'hdparm -C' behaviour is also an issue since usually we (or our scripts/tools) use this to determine whether the drive is in standby/sleeping state or idle/active to determine to query it or not (eg. periodic SMART checks). With JMS578 now every hdparm -C query ends up waking up a connected disk and returns then 'unknown' instead of idle/active/standby/sleeping. I hope you report this to JMicron too.

This only has the function f/w update and setting spin-down timer. There is no new F/W binary file.
Unfortunately "# hdparm -C " behavior is also the same as before but without the drive is waking up when its spin-down state. I think it depends on hard disk driver.

Code: Select all

root@odroid:~# hdparm -C /dev/sda

/dev/sda:
SG_IO: bad/missing sense data, sb[]:  70 00 01 00 00 00 00 0a 00 00 00 00 00 1d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 drive state is:  unknown

tkaiser · Unread post by **tkaiser** » Thu Nov 02, 2017 3:41 am

neal wrote:There is no new F/W binary file.

The firmware file is different (check with 'diff -a') only the version is the same. But JMS578 is still broken so let's wait for a real fix. Unless SAT is not working correctly the USB-to-SATA bridge can't be called 'working correctly': https://forum.armbian.com/topic/4983-od ... ment-42563

neal · Unread post by **neal** » Thu Nov 02, 2017 11:38 am

tkaiser wrote: The firmware file is different (check with 'diff -a') only the version is the same. But JMS578 is still broken so let's wait for a real fix. Unless SAT is not working correctly the USB-to-SATA bridge can't be called 'working correctly': https://forum.armbian.com/topic/4983-od ... ment-42563

Yes, I agree with you.
so, Is your ROCK64 USB 3.0 to SATA working correctly?
Can you see the drive state correctly when you tried "# hdparm -C "?

Thanks

fvolk · Unread post by **fvolk** » Thu Nov 02, 2017 4:13 pm

For scripted drive power management hdparm -C and -S and -y should work - on the HC1 and future SBCs..... thank you

tkaiser · Unread post by **tkaiser** » Thu Nov 02, 2017 4:53 pm

neal wrote:Is your ROCK64 USB 3.0 to SATA working correctly?
Can you see the drive state correctly when you tried "# hdparm -C "?

No, since this is a JMS578 firmware issue JMicron might still not be aware of (it does not need some custom spindown fancyness but full 'SCSI / ATA translation' compatibility so we can talk directly to the drive and not a firmware layer in between).

Just checked it with an older JMS567 enclosure:

Code: Select all

root@odroidxu4:~/JMS578FwUpdater# ./JMS578FwUpdate -d /dev/sdc -v
Bridge Firmware Version: v46.3.0.2

root@odroidxu4:~/JMS578FwUpdater# hdparm -C /dev/sdc

/dev/sdc:
SG_IO: bad/missing sense data, sb[]:  70 00 01 00 00 00 00 0a 00 00 00 00 00 1d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 drive state is:  unknown

Also broken. Below how it has to look like (ASM1153E enclosure which is also UAS capable and performs more or less identical to JMS567 and JMS578):

Code: Select all

root@odroidxu4:~/JMS578FwUpdater# lsusb | grep ASMe
Bus 001 Device 004: ID 174c:55aa ASMedia Technology Inc. ASMedia 2105 SATA bridge
root@odroidxu4:~/JMS578FwUpdater# hdparm -C /dev/sdc

/dev/sdc:
 drive state is:  active/idle

neal · Unread post by **neal** » Thu Nov 02, 2017 5:32 pm

tkaiser wrote: Below how it has to look like (ASM1153E enclosure which is also UAS capable and performs more or less identical to JMS567 and JMS578):
Code: Select all
root@odroidxu4:~/JMS578FwUpdater# lsusb | grep ASMe
Bus 001 Device 004: ID 174c:55aa ASMedia Technology Inc. ASMedia 2105 SATA bridge
root@odroidxu4:~/JMS578FwUpdater# hdparm -C /dev/sdc

/dev/sdc:
 drive state is:  active/idle

I have the enclosure and had the same result this morning(Korea time). and I reported to the JMicron.
I hope that we have new F/W soon.

Thanks, tkaiser

tkaiser · Unread post by **tkaiser** » Thu Nov 02, 2017 9:31 pm

neal wrote:I hope that we have new F/W soon.

Well, that would require JMicron thinking about the issue being a bug or at least unwanted behaviour (and not a feature which is obviously the case since why would they want their firmware interfere with host to device communication and implement an own spindown policy? Most probably the request for this originated from HDD vendors having external disk enclosures in mind --> a sleeping disk is magnitudes more shock resistant than a spinning).

Currently they're only aware that there are people out there who don't like their 3 minutes spindown default, they're most probably not aware that we're wanting what we get with direct SATA access (or 'SCSI / ATA translation' fully working like with ASMedia bridges): the ability to talk directly to the disk in question.

tkaiser · Unread post by **tkaiser** » Fri Nov 17, 2017 3:08 am

Some JMicron info wrt JMS578 firmware naming: https://forum.armbian.com/topic/3317-or ... ment=43735

They're currently investigating the SAT issue and are testing...

neal · Unread post by **neal** » Tue Dec 05, 2017 12:34 pm

New firmware version v173.01.00.01 for JMS578 under HC1 now available.
You can check it through the link.
https://wiki.odroid.com/odroid-xu4/soft ... _fw_update

tkaiser · Unread post by **tkaiser** » Tue Dec 12, 2017 2:57 am

For me (and others) the last upgrade fixes all open issues: full SAT compliance (so we're able to talk directly to the disk and apply spindown parameters there, we can also query the disks with hdparm). Also another issue is already fixed with this firmware version: the drive's serial numbers are now correctly reported to the host which solved another related problem: https://forum.openmediavault.org/index. ... post162208

At least I have some hope that JMicron might now also solve the remaining issues with JMS561 on the Cloudshell 2?

moe · Unread post by **moe** » Thu Jan 25, 2018 3:18 am

The guide https://wiki.odroid.com/odroid-xu4/soft ... _fw_update was very helpful. It could be mentioned more prominently and be summarized which problems this solves.

Jojo · Unread post by **Jojo** » Thu Jan 25, 2018 9:45 pm

Hi,

I just stopped by to say THANK YOU to you people who raised this issue and also to team HK for your care and your effort!

Greetings

derschorsch · Unread post by **derschorsch** » Sat Jan 27, 2018 6:07 pm

I installed ARMBIAN on my Odroid HC1 and the firmware upgrade described here

https://wiki.odroid.com/odroid-xu4/soft ... _fw_update

also worked for me! Thanks a lot!

Does this firmware update persist, even if i reflash the os image?

mad_ady · Unread post by **mad_ady** » Sat Jan 27, 2018 8:51 pm

Yes, it's stored in the sata chipset, independent of os

derschorsch · Unread post by **derschorsch** » Sat Jan 27, 2018 11:24 pm

Yes, it's stored in the sata chipset, independent of os

That sounds good, thank you!

massaquah · Unread post by **massaquah** » Thu Feb 22, 2018 5:49 pm

Hello everyone,

I received my odroid HC2 a few days ago (which didn't ship with the new JMICRON firmware), immediately noticed the 3-minute spindown behaviour, found this thread and successfully applied the new firmware.

So far so good.

But I noticed one issue:

With the "old" firmware I was able to query the hard disk power state with "smartctl -i -n standby....." without waking up the device.
With the new firmware both commands "smartctl -i -n standby....." and "hdparm -C..." wake the hard disk from sleep/standby.

Can anyone confim this?
Is there another way of checking the spin down state without waking up the hard disk (which defeats the purpose)?

neal · Unread post by **neal** » Fri Feb 23, 2018 3:19 pm

massaquah wrote:With the new firmware both commands "smartctl -i -n standby....." and "hdparm -C..." wake the hard disk from sleep/standby.

Any case spin-down timer set by firmware update tool, even before hard disk is standby state by hdparm, it could be wake the hard disk from standby.
Let me assume this situation,
Once you've set spin-down timer 5 minutes by firmware update tool on your HC2.
Now your HDD is in the active state. After 3 minutes, you make HDD standby state by "hdparm -y" command manually. Then 2 minutes later JMS578 will try standby state to go again.

The above case, if you want to check HDD state using hdparm something like this happened to wake the hard disk from standby.
so, I recommended that disable spin-time timer by "-t 0(zero)" option. Instead of it use hdparm or something.

massaquah · Unread post by **massaquah** » Thu Mar 01, 2018 5:41 pm

I just made the following observation:

1. Spin-Down timer set by firmware to 20 minutes.
2. Setting hdparm to APM_level=127, Spindown time=120 --> expected: spin down after 10 minutes, actual: spin down after 20 minutes
3. Setting hdparm to APM_level=255, Spindown time=120 --> expected: spin down after 10 minutes, actual: spin down after 20 minutes

So hdparm settings are completely ignored although there shouldn't be any conflict with different timers from firmware and hdparm.

Does setting the firmware timer to a value other than 0 lead to hdparm being ignored?

neal · Unread post by **neal** » Fri Mar 02, 2018 6:32 pm

massaquah wrote: 1. Spin-Down timer set by firmware to 20 minutes.
2. Setting hdparm to APM_level=127, Spindown time=120 --> expected: spin down after 10 minutes, actual: spin down after 20 minutes
3. Setting hdparm to APM_level=255, Spindown time=120 --> expected: spin down after 10 minutes, actual: spin down after 20 minutes

I didn't know that. Thank you to inform me.

massaquah wrote:Does setting the firmware timer to a value other than 0 lead to hdparm being ignored?

I just wanted to say that 'standby' mode using firmware timer is always wake the hard disk from standby when you'd try "hdpram -C". whereas using hdparm to go "standby" case, doesn't wake from it.

DerSchnelle · Unread post by **DerSchnelle** » Thu Nov 29, 2018 4:24 pm

Hello guys,

I recently got my first HC2 and stumbled across this thread because of the spindown-issue.

So I tried to update my firmware, but I always get a "open device FAIL" message when trying to update. In the wiki there is a note to check the device path, apparently I am too stupid to do so

.

Can someone help me out here?

Thanks in advance!

neal · Unread post by **neal** » Thu Nov 29, 2018 4:35 pm

Hi @DerSchnelle,

Did you try it by root?
where your disk mount under /dev/sda? or /dev/sdb?
You can check it follow this command. after that, you should put it with "-d" option.

Code: Select all

# ls /dev/sd*

DerSchnelle · Unread post by **DerSchnelle** » Thu Nov 29, 2018 6:38 pm

neal wrote:Hi @DerSchnelle,

Did you try it by root?
where your disk mount under /dev/sda? or /dev/sdb?
You can check it follow this command. after that, you should put it with "-d" option.
Code: Select all
# ls /dev/sd* 

Hey neal,

thank you very much for your quick reply. I check (with root) with ls /dev/sb* and the output is indeed /dev/sda and dev/sda1. I think I might have a rights-problem with my hdd, as I formatted it outside of OMV and just read that this may cause problems.

So I guess my best solution might be formatting the hdd in OMV and try again?

neal · Unread post by **neal** » Thu Nov 29, 2018 6:59 pm

Your disk device path is /dev/sda. If there isn't anything wrong, you would be done with no issue.
Just try that following this how to.
https://wiki.odroid.com/odroid-xu4/soft ... _fw_update

DerSchnelle · Unread post by **DerSchnelle** » Thu Nov 29, 2018 10:14 pm

Thank you very much it finally worked. I formatted my disk, logged in via ssh-default root and now it updated.

wultna · Unread post by **wultna** » Tue Feb 12, 2019 8:23 am

Had the same problem with my brand new shipped hc2 on WD Red 4TB and did the update like discribed and it worked well for me also. Maybe better ship the device with updated fw and spin down timer of something like 7 days since nearly everyone will use the hc2 for nas purpose? Anyway very thank you for your support work in this case and avoiding a shitty workaround with cron job triggered keep alive write job.