Helios64 cute spindown sound from hdd head when turn off

[n3o]

Dear to all, I'm new on linux environment so be patience with me. I have a helios64 unit with installed Openmediavault 6. When I reboot or turn-off helios64 (both from webgui interface that from power button) the hard disk ( 2 wd60efrx) make a cute sound from head. How can I check that heads are parked correctly? I don't want damage my hard disks

 

Best regards

[n3o]

nobody can answer me?

[RockBian]

On modern disks (modern as in the last 25+ years) the heads don't have to be parked. When you remove the power, the heads are automatically parked. The momentum of the rotating disk is used to provide the energy.

[n3o]

11 minutes ago, RockBian said:

On modern disks (modern as in the last 25+ years) the heads don't have to be parked. When you remove the power, the heads are automatically parked. The momentum of the rotating disk is used to provide the energy.

Thank You for the answer...the problem is that sometimes (so not always) I hear a cute sound from hdd. I have 2 hdd WD60EFRX, at one of two, I have disabled the parking heads after idle timer. When I will have possibility, I'll disable the idle timer also for the other hdd. However, the next time that I turn-off helios64, I'll make a video and I'll share it here.

[n3o]

Problem still occurs: I have tried to search and I have found this threads

https://forum.openmediavault.org/index.php?thread/43161-safely-power-down-usb-hdd-s-on-system-shutdown/#post337071

 

and

 

https://wiki.odroid.com/odroid-xu4/troubleshooting/shutdown_script

 

the script in odroid works also on helios64?

[prahal]

@n3o thanks for the script. I will try it. The script is generic (it will work on any box), nothing Odroid specific.

I followed https://wiki.odroid.com/odroid-xu4/troubleshooting/shutdown_script instructions to install.

I do not know if it is necessary or if as told above as the head automatically parks with no need for the script. Still, the noise is too high and if I can get rid of it, I will.

[prahal]

Note that monitoring the serial console on reboot I can hear the HDD sound not on power off but on power on from reboot (ie if I enter `poweroff` on the helios64 and then press the power on button, no HDD sound ensues).

Only when entering the `reboot` command or a crash that make the kernel restart the box do I hear the sound ... but only when the box starts, not when it stops.

I believe this is due to the U-Boot power rails management code. Probably that it turns off all the rails before turning on one of the rails, then the other rail. This is as it turns off all rails. Then the Power-Off_Retract_Count increase. Note that running the `reset` command on the U-Boot prompt does produce the click (but does not increase the  Power-Off_Retract_Count  S.M.A.R.T. attribute). And that only the Power-Off_Retract_Count  for the PCIe plugged HDDs increases (contrary to the Odroid issue the USB are not affected ... because the HDD power rails are only for the PCIe ones).

 

So poweroff does not produce the HDD noise, nor does it increases the Power-Off_Retract_Count .

Reboot produces the HDD noise and increases the Power-Off_Retract_Count but on startup from reboot.

U-Boot reset produces the HDD noise but does not increase the Power-Off_Retract_Count (which I do not understand).

 

The odroid shutdown scripts fixes the HDD noise on reboot and Power-Off_Retract_Count  increase (but does not help when the kernel auto reboot due to a crash ... because then the systemd shutdown scripts are not called).

 

The odroid script helps but I believe the issue should be handled in the helios64-specific U-Boot code. But I do not know this code, nor do I know how power rails should be handled to avoid the noise on startup from reboot and U-Boot reset command, nor do I know how to avoid the Power-Off_Retract_Count  increasing (which seems related to the HDD noise but not in all cases). Maybe fixing one will fix both issues.

 

```

U-Boot TPL 2022.07-armbian (Nov 22 2022 - 02:23:55)                                                                                                                                                                
Channel 0: LPDDR4, 50MHz
BW=32 Col=10 Bk=8 CS0 Row=16/15 CS=1 Die BW=16 Size=2048MB
Channel 1: LPDDR4, 50MHz
BW=32 Col=10 Bk=8 CS0 Row=16/15 CS=1 Die BW=16 Size=2048MB
256B stride
lpddr4_set_rate: change freq to 400000000 mhz 0, 1
lpddr4_set_rate: change freq to 800000000 mhz 1, 0
Trying to boot from BOOTROM
Returning to boot ROM...

U-Boot SPL 2022.07-armbian (Nov 22 2022 - 02:23:55 +0000)
Trying to boot from SPI
Trying to boot from MMC1
Card did not respond to voltage select! : -110
spl: mmc init failed with error: -95
Trying to boot from MMC2
NOTICE:  BL31: v2.6(release):a1f02f4f-dirty
NOTICE:  BL31: Built : 02:23:49, Nov 22 2022


<HDD sound>


U-Boot 2022.07-armbian (Nov 22 2022 - 02:23:55 +0000)

SoC: Rockchip rk3399
Reset cause: RST
DRAM:  3.9 GiB
(...)

```

Edited February 14, 2023 by prahal

[prahal]

OK, I revert part of my statement. U-Boot reset command indeed increase Power-Off_Retract_Count  S.M.A.R.T. attribute, be it happening after a Linux kernel power down

reboot: Power down

or after a Linux kernel plain reboot

reboot: Restarting system

only not in all cases.

With the odroid shutdown script U-boot reset command increases the Power-Off_Retract_Count in all cases (but never for the initial U-Boot boot which never makes noise).

After power off, an initial U-boot boot, and 3 U-boot boots reset I get an increase of 3 for the Retract Count.

After a reboot which makes the initial U-Boot boot and 3 U-Boot resets that also makes a 4 increase of Retract Count.

 

But without the odroid shutdown script, if I power off the board and then power on it, on the U-boot prompt the first reset makes the noise but does not increase the Power-Off_Retract_Count.

Then if I do more reset in a row in U-Boot the Power-Off_Retract_Count increases those extra number of times. The initial U-Boot boot after power off makes no noise and does not increase this Retract Count number,  so for the initial U-Boot boot and 3 resets, I get an increase of 2.

Also without the odroid shutdown script, if I reboot and enter reset 3 times in U-Boot I get an increase of 4 of the Retract Count (initial U-Boot makes HDD noise and increases the Retract Count, then the 3 U-Boot resets also make the HDD noise and increase the Retract Count by 1 each).

 

So the only special case is a startup after powering off without the odroid script. That the initial U-Boot boot makes no noise and does not increase the Retract Count is logical. But that the first U-Boot reset after a U-Boot boot from power off makes HDD noise but does not increase the HDD Retract Count that I did not expect (and that was the case I initially tested with and with only one reset, thus my previous analysis).

 

 

Note that on further attempts it behaved as usual: poweroff without odroid script, 1 initial U-Boot + 5 U-Boot resets made an increase of 5 of the Retract Count (maybe Retract Count is not increased in 100% of the U-Boot resets though it is at least the common case).

 

 

[n3o]

I have read your posts but I'm a little confused:

1. how can I find the version of u-boot? Updating kernel implies update u-boot ? (sorry, but I'm a newbie in linux environment)

2. hdd noise and Power-Off_Retract_Count are You sure that are event indipendent? I ask this because I have 2 WD60EFRX, I have disabled the parking head timer whit wdidle utility, but the noise of parking head was less sharp then noise that I'll get when turnoff nas (I don't know if this happens also on reboot or not): seems that here is something that screeches

. So, for my opinion, the problem is that the head should be parked only when turnoff the system (before shut down the power to hdd) and the sharp noise is related to this 

3. can You share an audio record of the noise?

 

I don't know if this happens also for hdd enclousere usb, but the best thing is parking head and turn-off hdd before power off for both sata hdd and usb hdd.

[n3o]

Maybe the script isn't complete. From here:

https://man7.org/linux/man-pages/man8/hdparm.8.html

 

--idle-unload

              Issue an ATA IDLE_IMMEDIATE_WITH_UNLOAD command, to unload
              or park the heads and put the drive into a lower power
              state.  Usually the device remains spun-up.

 

Before hdparm -Y should be added "--idle-unload" in the script

[n3o]

@prahal when You check Power-Off_Retract_Count do You use ssh console or webgui? It's better ssh console because sometimes can happen that browser don't update data e show case result

[prahal]

@n3o I use ssh to check Power-Off_Retract_Count

 

about the Odroid shutdown script I do not know if '--idle-unload' is needed. But the script already works. The only issue is that it does not run in U-Boot space (on U-Boot reset) or even when the kernel crashes. SO I believe this is only a bandaid. A proper fix should be made in the helios64 U-Boot code.

 

About the U-boot. No U-Boot is not updated on a kernel upgrade (U-Boot is like the BIOS). It is not even updated when you upgrade the u-boot package linux-u-boot-helios64-current (or linux-u-boot-helios64-edge if runnign armbian edge).

You have to run armbian-config, choose "System", then "Install" then finally "5 Install /Update the bootloader on SD/eMMC" (or short, run nand-sata-install and choose "5 Install /Update the bootloader on SD/eMMC") and even then if you run Armbian on an SD card it will update the U-Boot on the SD card but not on the eMMC. And I believe Helios64 boots on the eMMC U-Boot even if an SD card is installed (you can add a jumper on the board to switch to SD card boot but it is not the default), so the previous U-Boot update command will have no effect on user with an SD card root. To me in such case you have to run in (valid for in a Bourne shell) (you have to replace the placeholders!):
 

source /usr/lib/u-boot/platform_install.sh
write_uboot_platform <your uboot directory>  <your emmc device file>

 

You can find the emmc device by:

dmesg | "mmc.*: SDHCI controller on fe330000.mmc \[fe330000.mmc\] using ADMA"

if you see mmc1 then the eMMC device will be /dev/mmcblk1

 

to get the u-boot directory, first find you u-boot debian package:

dpkg -l "linux-u-boot-helios64*"
Souhait=inconnU/Installé/suppRimé/Purgé/H=à garder
| État=Non/Installé/fichier-Config/dépaqUeté/échec-conFig/H=semi-installé/W=attend-traitement-déclenchements
|/ Err?=(aucune)/besoin Réinstallation (État,Err: majuscule=mauvais)
||/ Nom                        Version       Architecture Description
+++-==========================-=============-============-=================================
ii  linux-u-boot-helios64-edge 23.02.0-trunk arm64        Uboot loader 2022.07

in the result you see linux-u-boot-helios64-edge, then run "dpkg -L <your u-boot debian package name>:

dpkg -L linux-u-boot-helios64-edge | grep /usr/lib/linux-u-boot-
/usr/lib/linux-u-boot-edge-helios64_23.02.0-trunk_arm64
/usr/lib/linux-u-boot-edge-helios64_23.02.0-trunk_arm64/idbloader.img
/usr/lib/linux-u-boot-edge-helios64_23.02.0-trunk_arm64/u-boot.itb

then you know your u-boot directory name is /usr/lib/linux-u-boot-edge-helios64_23.02.0-trunk_arm64

 

which gives for an edge u-boot for armbian 23.02.0 install with an emmc on /dev/mmcblk1:

write_uboot_platform /usr/lib/linux-u-boot-current-helios64_23.02.0-trunk_arm64 /dev/mmcblk1

 

you can replace the write_uboot-platform call with its commands you can read in /usr/lib/u-boot/platform_install.sh but they vary.

 

 

 

 

Last about the U-Boot version I believe you can only get the currently installed version from the serial console log when the box startup. Maybe you could read the storage blocks where U-boot is stored but this is hard to guide through. For the above setup, it would give :
 

sudo strings /dev/mmcblk1 |grep "U-Boot"

U-Boot TPL 2022.07-armbian (Feb 15 2023 - 11:06:06)
U-Boot SPL 2022.07-armbian (Feb 15 2023 - 11:06:06 +0000)
U-Boot
FIT image for U-Boot with bl31 (TF-A)
U-Boot (64-bit)
%U-Boot

(...)

which will give U-Boot version 2022-07-armbian (the date is new because it is an U-Boot install of a  local build Armbian build).

Note you should terminate the above command before it completes else it will read the whole storage which can take a while (this with Ctrl+C).

 

 

About the HDD noise. Do you really get it on poweroff? Here it only happens on power on from reboot. Poweroff does not call into U-Boot. So maybe the issue is with your parking head timer removal being at fault or something specific you did. And nothing in code could help with that be it kernel or U-Boot. That is if you prevent the head from being parked by the kernel before it turns the power off then this might be a case where Retract Count will happen and only a custom script like the Odroid one could help you workaround the issue with your tweaking.

 

I find "HDD noise and Power-Off_Retract_Count" being independent really weird. But I noticed it (but only in a specific process ... maybe it was not exactly the *same noise* in that it indeed make a similar noise but maybe the head had more time to park. As told above I was able to reproduce it though with a very specific process told above but not always (as I added in an edit of the above post I can not always reproduce so maybe you missed it).

Also, I believe the Retract Count increasing only happening on power on from reboot is due to the power being kept on by the kernel on the HDD on reboot and the helios64 U-Boot code turning them off before turning first rails A HDD on then rails B HDD on. Maybe Retract Count only happens because the head has no time to park before being turned on. Though that is unlikely as both rails A HDDs and rails B HDDs get their retract count increase while rail B has a bigger delay before being started up (but maybe this delay is still too short, this requires work to find out).

Also, the head should be parked on poweron from reboot per kernel somehow does not trigger this parking on reboot and the U-Boot helios64 code turns their power off on boot (thus the HW triggered head parking on no power). I believe parking the head on the off case is not safe (the kernel can crash and then the head will not be parked whatever the script of kernel code). This has to be done before turning their power off in the U-Boot (per the helios64 has to turn only one rail on before the other it has to turn at least one off at boot. Maybe it could turn off only one instead of turning both off then turn one on and then the other, but that will still increase the Retract Count for the HDD on the rail it turned off which is not great).

 

About a recording of the noise I cannot do it right now but I will try when time permits. But I believe the noise only depends on the hardware involved but there will always be noise. It turns out I have a mix of WD30EFRX and WD60EFZX so the noise should be pretty close to yours. I will still provide mine if and when time permits. Could you also share a recording of the noise you get?

 

 

Note that USB HDD does not need handling with helios64. They are already turned off when needed. The only issue is with PCIe SATA HDD on helios64. Because U-Boot turns them off on startup. If they are already off (because one poweroff the helios64) that is not an issue as they are already off and parked. Only when reboot they are not turned off and then the HDD park with their firmware because their power has been turned off by U-Boot to keep enough power to turn the HDD on (which make me believe a simple fix would be not to turn off then on the rails in case of reboot because ... well the HDD are already on, no need to take into account that we do not have enough power to turn them all on at once by powering rails 1 then rails B).

 

I start to believe you made a tweak with wdidle that is wrong for the hardware (or at least not supported by Linux kernel) because you get the noise on poweroff. So someway you are preventing the kernel to park the head on poweroff thus it is logical that you get an HW head parking triggered by no power to the HDDs. Having this wdidle setting supported is not a downstream issue (Armbian), this is an upstream feature request. Armbian could develop it if they can. This could even be rejected by upstream as an unsupported configuration. Hard to tell. But it would definitely not be a bug. You cannot mix any combination of hardware settings. These even have to be supported by the other hardware on the HW platform.

 

I believe if you make the same tweak you did with wdidle to USB enclose the same noise and parking head issue will arise. But this is due to the setting, not a bug in the kernel or U-boot I guess.

Can you reproduce the HDD noise on poweroff without any wdidle tweak?

[Gammel]

In this tread @aprayoga confirmed U-Boot needs to be changed. But AFAIK this never happend.

[n3o]

@praha hi, sorry for the long time, but I have got many problem. Can You tell me how switch from Zsh shell to Bourne shell and viceversa ? I have tried to follow dmesg | "mmc.*: SDHCI controller on fe330000.mmc \[fe330000.mmc\] using ADMA" and dpkg -l "linux-u-boot-helios64*" some times ago but result isn't so clear, moreover I remember linux u-boot was of about 2021.

 

On 2/16/2023 at 7:29 PM, prahal said:

About the HDD noise. Do you really get it on poweroff? Here it only happens on power on from reboot. Poweroff does not call into U-Boot. So maybe the issue is with your parking head timer removal being at fault or something specific you did. And nothing in code could help with that be it kernel or U-Boot. That is if you prevent the head from being parked by the kernel before it turns the power off then this might be a case where Retract Count will happen and only a custom script like the Odroid one could help you workaround the issue with your tweaking.

 

 

I have hear it on power off only... in the last time, before add odroid script, I have no more hear it but however, for security, I have added the script. Hope that the absence of hdd noise isn't caused but a fault or incoming fault of the drive. I don't think that issue is related to parking head timer because even before of dsable idle timer I have heard that scare sound

 

On 2/16/2023 at 7:29 PM, prahal said:

Also, I believe the Retract Count increasing only happening on power on from reboot is due to the power being kept on by the kernel on the HDD on reboot and the helios64 U-Boot code turning them off before turning first rails A HDD on then rails B HDD on

 

Yes, can be that the reason: it's possible keep poweron mechanical motor and turnoff and turnon electronic board as well as it's possible poweroff mechanical motor and keep turnon electronic board (this last case happen when put a pc in standby mode).... are You sure that kernel keep the power before reboot and helios64 U-Boot before turning off and after turning on hdd?

 

On 2/16/2023 at 7:29 PM, prahal said:

Maybe Retract Count only happens because the head has no time to park before being turned on.

 

I think that if Retract Count is increased than the head has been parked.

On 2/16/2023 at 7:29 PM, prahal said:

Also, the head should be parked on poweron from reboot per kernel somehow does not trigger this parking on reboot and the U-Boot helios64 code turns their power off on boot (thus the HW triggered head parking on no power).

 

I haven't understood this phrase.

 

On 2/16/2023 at 7:29 PM, prahal said:

I believe parking the head on the off case is not safe (the kernel can crash and then the head will not be parked whatever the script of kernel code). This has to be done before turning their power off in the U-Boot (per the helios64 has to turn only one rail on before the other it has to turn at least one off at boot. Maybe it could turn off only one instead of turning both off then turn one on and then the other, but that will still increase the Retract Count for the HDD on the rail it turned off which is not great).

 

 

ok, but it's always better that turnoff helios64 without script. For rail do You mean a drive unit ? ( so we have a max of 5 drive unit)

 

On 2/16/2023 at 7:29 PM, prahal said:

Because U-Boot turns them off on startup.

 

in reboot case ... right?

 

On 2/16/2023 at 7:29 PM, prahal said:

If they are already off (because one poweroff the helios64) that is not an issue as they are already off and parked.

 

I'm not sure of this, because I hear a scared noise ... I think that the noise was caused by a turnoff without parking of the head, because with all the other hdd and system I have never hear that sound

 

On 2/16/2023 at 7:29 PM, prahal said:

Only when reboot they are not turned off and then the HDD park with their firmware because their power has been turned off by U-Boot to keep enough power to turn the HDD on (which make me believe a simple fix would be not to turn off then on the rails in case of reboot because ... well the HDD are already on, no need to take into account that we do not have enough power to turn them all on at once by powering rails 1 then rails B).

 

 

yes

 

On 2/16/2023 at 7:29 PM, prahal said:

I start to believe you made a tweak with wdidle that is wrong for the hardware (or at least not supported by Linux kernel) because you get the noise on poweroff.

 

no, wdidle tweak disable head parking timer ... in wd red series after 5 minutes of drive wasn't been used the head parking automatically. Tweak disable only head parking timer. 

On 2/16/2023 at 7:29 PM, prahal said:

. So someway you are preventing the kernel to park the head on poweroff thus it is logical that you get an HW head parking triggered by no power to the HDDs

 

wdidle tweak work on hdd firmware, if the kernel want park the head it can make without problem (rather, I force with script the head parking). I think that script is executed on the kernel before poweroff.

On 2/16/2023 at 7:29 PM, prahal said:

Having this wdidle setting supported is not a downstream issue (Armbian), this is an upstream feature request.

 

why feature request? the kernel can work as it want, simply it must parking heads before turnoff

 

On 2/16/2023 at 7:29 PM, prahal said:

I believe if you make the same tweak you did with wdidle to USB enclose the same noise and parking head issue will arise

 

This is related on how kernel work... if I disable timer and before turnoff parking the head, all should work fine

 

p.s: do You have u-boot helios64 source code?

[prahal]

@n3o note that I did not tell you to upgrade the u-boot. I told you a fix in U-boot would be the proper fix. But this patch does not exist.

I only told you how to update it as you asked.

[prahal]

On 5/16/2023 at 7:52 PM, n3o said:

I have tried to follow dmesg | "mmc.*: SDHCI controller on fe330000.mmc \[fe330000.mmc\] using ADMA"

sorry I meant

dmesg | grep "mmc.*: SDHCI controller on fe330000.mmc \[fe330000.mmc\] using ADMA"

I cannot edit the post anymore.

[prahal]

On 5/16/2023 at 7:52 PM, n3o said:

are You sure that kernel keep the power before reboot and helios64 U-Boot before turning off and after turning on hdd?

I do not understand. Can you be more explicit?

[prahal]

On 5/16/2023 at 7:52 PM, n3o said:

On 2/16/2023 at 7:29 PM, prahal said:

Also, I believe the Retract Count increasing only happening on power on from reboot is due to the power being kept on by the kernel on the HDD on reboot and the helios64 U-Boot code turning them off before turning first rails A HDD on then rails B HDD on

 

Yes, can be that the reason: it's possible keep poweron mechanical motor and turnoff and turnon electronic board as well as it's possible poweroff mechanical motor and keep turnon electronic board (this last case happen when put a pc in standby mode).... are You sure that kernel keep the power before reboot and helios64 U-Boot before turning off and after turning on hdd?

As far as I remind the turn SATA power rails off then on sequence is U-Boot only. As U-Boot is not run on poweroff this sequence is not run on poweroff (poweroff managed by the kernel only).