Hd-idle for Lamobo-R1

[Virgus]

Hello I've just started struggling with Lamobo-R1 SATA problems and I'm facing the well-known bad customer service from SinoVoip.

With the help of this forum I got finally the HD spinning but I've not seen anything yet related to hd-idle package.

 

I'd like to know if anybody uses it and if the instructions on http://hd-idle.sourceforge.net/ are correct to recompile for the BPI-R1 board.

As a matter of fact I'm stuck at the line saying "Run "dpkg...."

 

Thanks!

V.

[Igor]

Hard drive idling is build in. Use a package hdparm.

 

Example:

 

http://www.howtoeverything.net/linux/hardware/permanently-configure-hard-drives-spin-down-after-given-idle-time

[tkaiser]

Use a package hdparm.

 

 

Unfortunately there are a couple of drives that simply ignore "hdparm -B" settings. Then a daemon approach might help: http://pastebin.com/issrNdcP

[Virgus]

Many thanks!

It worked with "hdparm -B255 ..." command and after I gave power to the battery connector (it was needed otherwise the HD did not spin up again after spin down).

 

May I ask another hint? I noticed that on shutdown the BPI-R1 HD spins down and then reboots

while on reboot it doesn't spin down, it just shuts off the HD and the BPI-R1 reboots.

Is it normal behaviour?

 

Could you please suggest me a way to make it not reboot at shutdown?

Is there a way also to make it spin down the HD prior to rebooting?

 

Thanks again and have a nice day!

V.

[Igor]

Power handling is buggy in legacy kernel. I don't know if you can do much about without driver rework.

 

Perhaps this is helpful:

https://www.olimex.com/forum/index.php?topic=4739.0

[Virgus]

Many thanks Igor!

I'm having a major issue with Sata power but it's better I post it to the BPI-RI Sata topic.

 

V.

[Igor]

One are driver issues - Those are common but R1 have some extra, "bonus" problems 

[Virgus]

you're right, what a "gift" I've made to myself buying this crappy board!!!

[Virgus]

Hello Igor and tkaiser,

I'm posting here my question for you as it is related to both hd sleeping and to tkaiser's RPiMonitor temp-daemon script.

 

I noticed that when the script is running the Sata HD never goes to sleep and if I turn the script off it does.

 

So I tried modifying the script in this way:

          # HDD/SSD temp
          DiskStatus=$(hdparm -C /dev/sda)
          substr=standby
          if [[ "$DiskStatus" =~ "$substr" ]]; then
              echo -n >/run/hdd-temp
              echo $DiskStatus
          else
              DiskTemp=$(hddtemp -n /dev/sda)
              if [ "X${DiskTemp}" != "X" ]; then
                  echo -n ${DiskTemp} >/run/hdd-temp
                  echo $DiskStatus
              fi
          fi

but still, if the script is running the Sata HD never goes to sleep.

If the script is launched after the HD is sleeping there's no problem, but once accessed the drive the script inhibits it from going to sleep again.

 

So I tested doing manually the following sequence:

 hdparm -Y /dev/sda                 #the drive goes to sleep manually

 hdparm -C /dev/sda                 #drive is asleep

 hdparm -C /dev/sda                 #drive is spinning again

 

Alternatively I set the sleeping timeout to 5 minutes with:

hdparm -B255 -S60 /dev/disk/by-id/ata-ST9750420AS_5WS2FWKN

And after spin down:

 hdparm -C /dev/sda                 #drive is asleep

 hdparm -C /dev/sda                 #drive is still asleep

 

How come the hdparam -C wakes up the hard disk in the first case and doesn't wake it up in the second case?!?!

How could I modify the script exactly to have HD sleeping and RPiMonitor coexist?

 

Thanks,

V.

 

BTW To avoid RPiMonitor report a wrong temperature when the drive is asleep I added

echo -n >/run/hdd-temp to the script. I couldn't test it for the aforementioned issues;

do you think it's fine like this?

[tkaiser]

How come the hdparam -C wakes up the hard disk in the first case and doesn't wake it up in the second case?!?!

 

Seems like 'special logic' implemented in the drive's firmware. The drive differentiates between 'sleeping by idle timeout' (using 'hdparm -B') and a state where you sent the drive to sleep manually (no, I don't get the logic behind).

 

It does not work if you add 'hdparm -B255 -S60 /dev/disk/by-id/ata-ST9750420AS_5WS2FWKN' to /etc/rc.local?

 

Currently I can not test the behaviour of RPi-Monitor when reading empty files. IIRC it will be reported as 0 then (0°C as a sign that the disk is sleeping)

 

But you should keep in mind that the temperature of a sleeping disk is below an idle disk. The last disk I tested with had an internal temperature of approx. 4°C above the enclosure's internal temp when sleeping. When it was totally off the temperature reported was the same as the enclosure's internal. But this might differ from disk to disk (in the case of the Samsung I tested with the internal thermal sensor must be nearby electronic circuits otherwise I don't get it why there are 4°C difference between sleeping/standby and totally off. In both cases the disk's surface felt identical.)

[Virgus]

It does not work if you add 'hdparm -B255 -S60 /dev/disk/by-id/ata-ST9750420AS_5WS2FWKN' to /etc/rc.local?

 

No, infact that's why I started examining this issue.

 

I'll try other two HDs I have to check if with different brands/models I have a different behaviour.

But I won't be able to check this before 15 days as I'm abroad now. I'll let you know how it goes...

 

Thanks for sharing your experiences, 0°C is clearly a false value, I would rather prefer a "greyed out" icon in RPiMonitor, but before solving this I have to make the script work correctly.

 

BTW I sent the Lamobo-R1 back to Sinovoip, they promised to check my board and send me a fully tested one working with a 0.7A HD!

...and the parcel to china was not so expensive at the end.