Automatic Spin-Down of SATA Drive
-
- Posts: 7
- Joined: Sun Oct 01, 2017 9:29 pm
- languages_spoken: English, German
- ODROIDs: U3, C1, XU4, HC1
- Has thanked: 0
- Been thanked: 0
- Contact:
Automatic Spin-Down of SATA Drive
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.
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.
-
- Posts: 9095
- Joined: Wed Jul 15, 2015 5:00 pm
- languages_spoken: english
- ODROIDs: XU4, C1+, C2, C4, N1, N2, H2, Go, Go Advance
- Location: Bucharest, Romania
- Has thanked: 597 times
- Been thanked: 584 times
- Contact:
Re: Automatic Spin-Down of SATA Drive
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?
-
- Posts: 3560
- Joined: Fri May 08, 2015 9:12 am
- languages_spoken: english
- ODROIDs: U-2,U3+,,XU-3,,XU3-LITE,,XU-4
C1+,,C-2,,,n2+2G and n2 4G
cloudshell I and shell II
N-1,,N-2,...other odroid acc`s as well..vu7 etc.. - Has thanked: 51 times
- Been thanked: 47 times
- Contact:
Re: Automatic Spin-Down of SATA Drive
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
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
Build It And They Will Come...Be Bold And Mighty Forces Will Come To Your Aid..!!!
-
- Posts: 7
- Joined: Sun Oct 01, 2017 9:29 pm
- languages_spoken: English, German
- ODROIDs: U3, C1, XU4, HC1
- Has thanked: 0
- Been thanked: 0
- Contact:
Re: Automatic Spin-Down of SATA Drive
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.
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.
-
- Posts: 3560
- Joined: Fri May 08, 2015 9:12 am
- languages_spoken: english
- ODROIDs: U-2,U3+,,XU-3,,XU3-LITE,,XU-4
C1+,,C-2,,,n2+2G and n2 4G
cloudshell I and shell II
N-1,,N-2,...other odroid acc`s as well..vu7 etc.. - Has thanked: 51 times
- Been thanked: 47 times
- Contact:
Re: Automatic Spin-Down of SATA Drive
Build It And They Will Come...Be Bold And Mighty Forces Will Come To Your Aid..!!!
-
- Posts: 7
- Joined: Sun Oct 01, 2017 9:29 pm
- languages_spoken: English, German
- ODROIDs: U3, C1, XU4, HC1
- Has thanked: 0
- Been thanked: 0
- Contact:
Re: Automatic Spin-Down of SATA Drive
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.
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.
-
- Posts: 3560
- Joined: Fri May 08, 2015 9:12 am
- languages_spoken: english
- ODROIDs: U-2,U3+,,XU-3,,XU3-LITE,,XU-4
C1+,,C-2,,,n2+2G and n2 4G
cloudshell I and shell II
N-1,,N-2,...other odroid acc`s as well..vu7 etc.. - Has thanked: 51 times
- Been thanked: 47 times
- Contact:
Re: Automatic Spin-Down of SATA Drive
i suspect the same..
wait for odroid to see this post..it may be some time however..there on holidays atm....
wait for odroid to see this post..it may be some time however..there on holidays atm....
Build It And They Will Come...Be Bold And Mighty Forces Will Come To Your Aid..!!!
- odroid
- Site Admin
- Posts: 36478
- Joined: Fri Feb 22, 2013 11:14 pm
- languages_spoken: English, Korean
- ODROIDs: ODROID
- Has thanked: 1459 times
- Been thanked: 991 times
- Contact:
Re: Automatic Spin-Down of SATA Drive
Can you show me
Let me know what happens with
hdparm -I /dev/sda
output?Let me know what happens with
hdparm -B255 -S255 /dev/sda
-
- Posts: 7
- Joined: Sun Oct 01, 2017 9:29 pm
- languages_spoken: English, German
- ODROIDs: U3, C1, XU4, HC1
- Has thanked: 0
- Been thanked: 0
- Contact:
Re: Automatic Spin-Down of SATA Drive
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.
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
- Posts: 244
- Joined: Fri Apr 14, 2017 10:02 am
- languages_spoken: Korean, English
- Has thanked: 9 times
- Been thanked: 18 times
- Contact:
Re: Automatic Spin-Down of SATA Drive
How about this hd-idle tool? Did you try it?
# ./hd-idle -i 1800 /dev/sda
# ./hd-idle -i 1800 /dev/sda
-
- Posts: 7
- Joined: Sun Oct 01, 2017 9:29 pm
- languages_spoken: English, German
- ODROIDs: U3, C1, XU4, HC1
- Has thanked: 0
- Been thanked: 0
- Contact:
Re: Automatic Spin-Down of SATA Drive
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.
"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.
-
- Posts: 533
- Joined: Sun Jun 05, 2016 11:04 pm
- languages_spoken: english
- ODROIDs: C2, C4, H2
- Has thanked: 0
- Been thanked: 54 times
- Contact:
Re: Automatic Spin-Down of SATA Drive
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.

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.
-
- Posts: 3560
- Joined: Fri May 08, 2015 9:12 am
- languages_spoken: english
- ODROIDs: U-2,U3+,,XU-3,,XU3-LITE,,XU-4
C1+,,C-2,,,n2+2G and n2 4G
cloudshell I and shell II
N-1,,N-2,...other odroid acc`s as well..vu7 etc.. - Has thanked: 51 times
- Been thanked: 47 times
- Contact:
Re: Automatic Spin-Down of SATA Drive
@ fvolk pls open your own thread we will help you ...
Build It And They Will Come...Be Bold And Mighty Forces Will Come To Your Aid..!!!
-
- Posts: 7
- Joined: Sun Oct 01, 2017 9:29 pm
- languages_spoken: English, German
- ODROIDs: U3, C1, XU4, HC1
- Has thanked: 0
- Been thanked: 0
- Contact:
Re: Automatic Spin-Down of SATA Drive
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.
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.
-
- Posts: 673
- Joined: Mon Nov 09, 2015 12:30 am
- languages_spoken: english
- ODROIDs: C1+, C2, XU4, HC1
- Has thanked: 0
- Been thanked: 5 times
- Contact:
Re: Automatic Spin-Down of SATA Drive
Another confirmation + workaround: https://forum.armbian.com/index.php?/to ... ment=41109
-
- Posts: 533
- Joined: Sun Jun 05, 2016 11:04 pm
- languages_spoken: english
- ODROIDs: C2, C4, H2
- Has thanked: 0
- Been thanked: 54 times
- Contact:
Re: Automatic Spin-Down of SATA Drive
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.
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.
-
- Posts: 673
- Joined: Mon Nov 09, 2015 12:30 am
- languages_spoken: english
- ODROIDs: C1+, C2, XU4, HC1
- Has thanked: 0
- Been thanked: 5 times
- Contact:
Re: Automatic Spin-Down of SATA Drive
Huh? No.fvolk wrote:A workaround with a cronjob is not acceptable, you get regular disruptions in your read/write operations.
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)
-
- Posts: 7
- Joined: Sun Oct 01, 2017 9:29 pm
- languages_spoken: English, German
- ODROIDs: U3, C1, XU4, HC1
- Has thanked: 0
- Been thanked: 0
- Contact:
Re: Automatic Spin-Down of SATA Drive
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.
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.
-
- Posts: 673
- Joined: Mon Nov 09, 2015 12:30 am
- languages_spoken: english
- ODROIDs: C1+, C2, XU4, HC1
- Has thanked: 0
- Been thanked: 5 times
- Contact:
Re: Automatic Spin-Down of SATA Drive
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
BTW: Underpowering is not related to UASP but more to... underpowering

[1] https://forum.armbian.com/index.php?/to ... ment=29569
-
- Posts: 533
- Joined: Sun Jun 05, 2016 11:04 pm
- languages_spoken: english
- ODROIDs: C2, C4, H2
- Has thanked: 0
- Been thanked: 54 times
- Contact:
Re: Automatic Spin-Down of SATA Drive
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?

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?
-
- Posts: 673
- Joined: Mon Nov 09, 2015 12:30 am
- languages_spoken: english
- ODROIDs: C1+, C2, XU4, HC1
- Has thanked: 0
- Been thanked: 5 times
- Contact:
Re: Automatic Spin-Down of SATA Drive
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.fvolk wrote:Anyone tested with a SSD yet and found any problems at the 3 mins with the sleep and resume, is it noticeable?
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...
- odroid
- Site Admin
- Posts: 36478
- Joined: Fri Feb 22, 2013 11:14 pm
- languages_spoken: English, Korean
- ODROIDs: ODROID
- Has thanked: 1459 times
- Been thanked: 991 times
- Contact:
Re: Automatic Spin-Down of SATA Drive
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.
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.
-
- Posts: 673
- Joined: Mon Nov 09, 2015 12:30 am
- languages_spoken: english
- ODROIDs: C1+, C2, XU4, HC1
- Has thanked: 0
- Been thanked: 5 times
- Contact:
Re: Automatic Spin-Down of SATA Drive
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.
- odroid
- Site Admin
- Posts: 36478
- Joined: Fri Feb 22, 2013 11:14 pm
- languages_spoken: English, Korean
- ODROIDs: ODROID
- Has thanked: 1459 times
- Been thanked: 991 times
- Contact:
Re: Automatic Spin-Down of SATA Drive
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.
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.
-
- Posts: 673
- Joined: Mon Nov 09, 2015 12:30 am
- languages_spoken: english
- ODROIDs: C1+, C2, XU4, HC1
- Has thanked: 0
- Been thanked: 5 times
- Contact:
Re: Automatic Spin-Down of SATA Drive
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.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.
- neal
- Posts: 244
- Joined: Fri Apr 14, 2017 10:02 am
- languages_spoken: Korean, English
- Has thanked: 9 times
- Been thanked: 18 times
- Contact:
Re: Automatic Spin-Down of SATA Drive
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
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.
You can check through this link.
https://wiki.odroid.com/odroid-xu4/soft ... _fw_update
This only has the function f/w update and setting spin-down timer. There is no new F/W binary file.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.
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
-
- Posts: 673
- Joined: Mon Nov 09, 2015 12:30 am
- languages_spoken: english
- ODROIDs: C1+, C2, XU4, HC1
- Has thanked: 0
- Been thanked: 5 times
- Contact:
Re: Automatic Spin-Down of SATA Drive
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-42563neal wrote:There is no new F/W binary file.
- neal
- Posts: 244
- Joined: Fri Apr 14, 2017 10:02 am
- languages_spoken: Korean, English
- Has thanked: 9 times
- Been thanked: 18 times
- Contact:
Re: Automatic Spin-Down of SATA Drive
Yes, I agree with you.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
so, Is your ROCK64 USB 3.0 to SATA working correctly?
Can you see the drive state correctly when you tried "# hdparm -C "?
Thanks
-
- Posts: 533
- Joined: Sun Jun 05, 2016 11:04 pm
- languages_spoken: english
- ODROIDs: C2, C4, H2
- Has thanked: 0
- Been thanked: 54 times
- Contact:
Re: Automatic Spin-Down of SATA Drive
For scripted drive power management hdparm -C and -S and -y should work - on the HC1 and future SBCs..... thank you 

-
- Posts: 673
- Joined: Mon Nov 09, 2015 12:30 am
- languages_spoken: english
- ODROIDs: C1+, C2, XU4, HC1
- Has thanked: 0
- Been thanked: 5 times
- Contact:
Re: Automatic Spin-Down of SATA Drive
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).neal wrote:Is your ROCK64 USB 3.0 to SATA working correctly?
Can you see the drive state correctly when you tried "# hdparm -C "?
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
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
Last edited by tkaiser on Thu Nov 16, 2017 4:10 pm, edited 1 time in total.
- neal
- Posts: 244
- Joined: Fri Apr 14, 2017 10:02 am
- languages_spoken: Korean, English
- Has thanked: 9 times
- Been thanked: 18 times
- Contact:
Re: Automatic Spin-Down of SATA Drive
I have the enclosure and had the same result this morning(Korea time). and I reported to the JMicron.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 hope that we have new F/W soon.
Thanks, tkaiser
-
- Posts: 673
- Joined: Mon Nov 09, 2015 12:30 am
- languages_spoken: english
- ODROIDs: C1+, C2, XU4, HC1
- Has thanked: 0
- Been thanked: 5 times
- Contact:
Re: Automatic Spin-Down of SATA Drive
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).neal wrote:I hope that we have new F/W soon.
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.
-
- Posts: 673
- Joined: Mon Nov 09, 2015 12:30 am
- languages_spoken: english
- ODROIDs: C1+, C2, XU4, HC1
- Has thanked: 0
- Been thanked: 5 times
- Contact:
Re: Automatic Spin-Down of SATA Drive
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...
They're currently investigating the SAT issue and are testing...
- neal
- Posts: 244
- Joined: Fri Apr 14, 2017 10:02 am
- languages_spoken: Korean, English
- Has thanked: 9 times
- Been thanked: 18 times
- Contact:
Re: Automatic Spin-Down of SATA Drive
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
You can check it through the link.
https://wiki.odroid.com/odroid-xu4/soft ... _fw_update
-
- Posts: 673
- Joined: Mon Nov 09, 2015 12:30 am
- languages_spoken: english
- ODROIDs: C1+, C2, XU4, HC1
- Has thanked: 0
- Been thanked: 5 times
- Contact:
Re: Automatic Spin-Down of SATA Drive
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?
At least I have some hope that JMicron might now also solve the remaining issues with JMS561 on the Cloudshell 2?
-
- Posts: 4
- Joined: Thu Jan 11, 2018 11:53 pm
- languages_spoken: english
- ODROIDs: HC1
- Has thanked: 0
- Been thanked: 0
- Contact:
Re: Automatic Spin-Down of SATA Drive
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.
-
- Posts: 524
- Joined: Mon May 18, 2015 12:13 am
- languages_spoken: english, german
- ODROIDs: C1, C1+, C2, HC1, HC2, VU8C
- Location: Germany
- Has thanked: 0
- Been thanked: 0
- Contact:
Re: Automatic Spin-Down of SATA Drive
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
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
-
- Posts: 2
- Joined: Sat Jan 27, 2018 5:43 pm
- languages_spoken: english, german
- ODROIDs: HC1
- Has thanked: 0
- Been thanked: 0
- Contact:
Re: Automatic Spin-Down of SATA Drive
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?
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?
-
- Posts: 2
- Joined: Sat Jan 27, 2018 5:43 pm
- languages_spoken: english, german
- ODROIDs: HC1
- Has thanked: 0
- Been thanked: 0
- Contact:
Re: Automatic Spin-Down of SATA Drive
That sounds good, thank you!Yes, it's stored in the sata chipset, independent of os
-
- Posts: 2
- Joined: Mon Feb 19, 2018 5:18 pm
- languages_spoken: english, german
- ODROIDs: HC2
- Has thanked: 0
- Been thanked: 0
- Contact:
Re: Automatic Spin-Down of SATA Drive
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)?
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
- Posts: 244
- Joined: Fri Apr 14, 2017 10:02 am
- languages_spoken: Korean, English
- Has thanked: 9 times
- Been thanked: 18 times
- Contact:
Re: Automatic Spin-Down of SATA Drive
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.massaquah wrote:With the new firmware both commands "smartctl -i -n standby....." and "hdparm -C..." wake the hard disk from sleep/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.
-
- Posts: 2
- Joined: Mon Feb 19, 2018 5:18 pm
- languages_spoken: english, german
- ODROIDs: HC2
- Has thanked: 0
- Been thanked: 0
- Contact:
Re: Automatic Spin-Down of SATA Drive
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?
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
- Posts: 244
- Joined: Fri Apr 14, 2017 10:02 am
- languages_spoken: Korean, English
- Has thanked: 9 times
- Been thanked: 18 times
- Contact:
Re: Automatic Spin-Down of SATA Drive
I didn't know that. Thank you to inform me.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 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.massaquah wrote:Does setting the firmware timer to a value other than 0 lead to hdparm being ignored?
-
- Posts: 3
- Joined: Thu Nov 29, 2018 4:18 pm
- languages_spoken: english, german
- ODROIDs: HC-2
- Has thanked: 0
- Been thanked: 0
- Contact:
Re: Automatic Spin-Down of SATA Drive
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!
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
- Posts: 244
- Joined: Fri Apr 14, 2017 10:02 am
- languages_spoken: Korean, English
- Has thanked: 9 times
- Been thanked: 18 times
- Contact:
Re: Automatic Spin-Down of SATA Drive
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.
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*
-
- Posts: 3
- Joined: Thu Nov 29, 2018 4:18 pm
- languages_spoken: english, german
- ODROIDs: HC-2
- Has thanked: 0
- Been thanked: 0
- Contact:
Re: Automatic Spin-Down of SATA Drive
Hey neal,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*
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
- Posts: 244
- Joined: Fri Apr 14, 2017 10:02 am
- languages_spoken: Korean, English
- Has thanked: 9 times
- Been thanked: 18 times
- Contact:
Re: Automatic Spin-Down of SATA Drive
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
Just try that following this how to.
https://wiki.odroid.com/odroid-xu4/soft ... _fw_update
-
- Posts: 3
- Joined: Thu Nov 29, 2018 4:18 pm
- languages_spoken: english, german
- ODROIDs: HC-2
- Has thanked: 0
- Been thanked: 0
- Contact:
Re: Automatic Spin-Down of SATA Drive
Thank you very much it finally worked. I formatted my disk, logged in via ssh-default root and now it updated.
-
- Posts: 2
- Joined: Tue Feb 12, 2019 8:12 am
- languages_spoken: english
- ODROIDs: HC2
- Has thanked: 0
- Been thanked: 0
- Contact:
Re: Automatic Spin-Down of SATA Drive
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.
Who is online
Users browsing this forum: No registered users and 0 guests