DSM-G600, DNS-3xx and NSA-220 Hack Forum

Mijzelf · 2008-09-29 14:43:41

My NSA-220 spins down it's disks after about 3 minutes of inactivity. That is too short. I couldn't find how to extend this period (the NAS doesn't have an option for this, and hdparm and sdparm don't work for me). So I wrote next script:

Code:

#!/ffp/bin/sh

#Spindown in minutes
SPINDOWN=60
# 'size'of touch
TOUCHSIZE=72

RUNNING=0
LASTBT=0
NOTACTIVE=-1
EXPECTED=0
LOGFILE='/ffp/var/log/spindown.log'
STATUSFILE='/var/log/spindown'

echo "spindown.sh starting" >> $LOGFILE

cat /proc/scsi/mvSata/0 >> $LOGFILE

while [ true ]
do
    BT=`head -13 /proc/scsi/mvSata/0 | tail -1 | awk '{print $6}' `
    DIFF=$( expr ${BT} - ${LASTBT} )
    KA=''

    if [ ${DIFF} -gt ${EXPECTED} ]
    then
        NOTACTIVE=0
        if [ $RUNNING -eq 0 ]
        then
            RUNNING=1
            echo Spinup >> $LOGFILE
            date >> $LOGFILE
        fi
    else
        NOTACTIVE=$( expr ${NOTACTIVE} + 1 )
        EXPECTED=0
        if [ ${NOTACTIVE} -lt ${SPINDOWN} ]
        then
            EXPECTED=${TOUCHSIZE}
            KA='Keep alive'
            touch /i-data/md0/.keepalive
        else
            if [ ${RUNNING} -eq 1 ]
            then
                RUNNING=0
                echo Spindown >> $LOGFILE
                date >> $LOGFILE
            fi
        fi
    fi

    echo sectors ${BT} diff ${DIFF} na ${NOTACTIVE} $KA > $STATUSFILE
    LASTBT=${BT}

    sleep 60
done

The idea is that it reads /proc/scsi/mvSata/0 once a minute, extracts the number of accessed sectors, compares it to the value of 1 minute ago, decides if the disk has been active the last minute.
Then it keeps the disk awake by touching .keepalive on the harddisk when it has been active in the last hour.
Of course touching is an activity too, so the script has to face that. On my disk this touch accesses 64-72 sectors, so the disk is only flagged active when the number of accessed sectors is higher.

This script works. The weird part is it doesn't work when I start it from /ffp/etc/fun_plug.local. The file /var/log/spindown then contains:

Code:

sectors diff - na 14 Keep alive

while it should be something like:

Code:

sectors 16472 diff 72 na 14 Keep alive

It seems it can't extract line 13 word 6 from mvSata/0. The LOGFILE contains a mvSata/0 like it should be:

Code:

Version_1_1

TimeStamp :
-23481  100

Number of interrupts generated by the adapter is :
3873

Integrated Sata adapterId 0,  channel 0

Adapter Channel Id      LUN     TO      TS      Vendor          Mode    LBA48
--------------------------------------------------------------------------------
0       0       0       0       1898    15152   Hitach          NCQ     1



TO           - Total Outstanding commands accumulated
TSA          - Total number of IOs accumulated
TS           - Total number of sectors transferred (both read/write)
Mode         - EDMA mode (TCQ|NCQ|Normal)
LBA48        - Large Block Address 48 feature set enabled

so when the script starts this file(?) already has the right contents.

Can somebody shine a light on this?

//sala edit
I did change topic subject

Last edited by sala (2009-03-14 19:39:00)

Mijzelf · 2008-09-29 15:19:20

I found it. I forgot to add

export PATH=/ffp/sbin:/ffp/bin:/usr/sbin:/sbin:/usr/bin:/bin

to /ffp/etc/fun_plug.local. So my script used different versions of head, tail, awk...

sala · 2009-03-14 20:20:57

In kernel source, there is
arch/arm/mach-mv88fxx81/Board/SATA/CoreDriver/mvStorageDev.c

Code:

unsigned short time_to_power_save = 3*60;               //default 3mins

But this will be later changed in EnablePowerSaving function which will be called from:
arch/arm/mach-mv88fxx81/LSP/mvSata/mvLinuxIalHt.c

Code:

EnablePowerSaving(3);               //default suspending time

2.30 firmware has web interface option to change default spindown parameter. I might dig around to find out how they manipulate this. But I am not surprised if they are using similar solution as Mijzelf script does.

sala · 2009-03-26 15:47:56

Seems like zyxel has released incorrect GPL sources for NSA-220+ (plus). It's just copy of regular NSA-220 outdated kernel source, and seems like other source files are just renamed as well (nsa220build.tar.gz -> nsa220plusbuild.tar.gz).

In NSA-220+ 3.10 and NSA-220 with 3.11 firmware has special kernel patch for disk suspending (d_suspdtime), but released GPL sources has no trace about d_suspdtime in them.

//edit
I will try to get some more recent sources, but It will not be easy...
http://www.zyxelforum.de/viewtopic,p,2880.html

sala · 2009-04-01 16:57:05

This GPL issue is heating up pretty fast. Looks to me like they are not interested to release any new GPL code...

chorus · 2009-05-20 20:14:42

opensource for NSA-220 PLUS is available ftp://opensource.zyxel.com/NSA-220%20PLUS/v3.12/

sala · 2009-05-21 09:02:37

chorus wrote:
opensource for NSA-220 PLUS is available ftp://opensource.zyxel.com/NSA-220%20PLUS/v3.12/

Thanks. I know.
I have loaded new kernel to flash and make it to boot system from hdd. Although I have some problems with d_suspdtime. From original firmware it will take parameters and use them correctly but in gentoo it reset's parameters back to 0 (unlimited) as soon as disk state changes.

//edit 1
I have started to suspect that once again they have released in-proper kernel source which has incomplete or broken functions in it. Not pointing any fingers yet...
Will compare kernel binaries soon and trying to find it out.

//edit 2
All string based data seems to be matching but binary code got bunch of differences in them.
Using same kernel source code, using same .config & Makefile, using same make parameter, using same cross-compiler should generate very-very similar kernel binaries.
Now I might try to use built kernel with zyxel firmware and see if d_suspdtime works properly.

Last edited by sala (2009-05-21 15:49:12)

chorus · 2009-05-30 16:05:14

sala wrote:
chorus wrote:
opensource for NSA-220 PLUS is available ftp://opensource.zyxel.com/NSA-220%20PLUS/v3.12/
Thanks. I know.
I have loaded new kernel to flash and make it to boot system from hdd. Although I have some problems with d_suspdtime. From original firmware it will take parameters and use them correctly but in gentoo it reset's parameters back to 0 (unlimited) as soon as disk state changes.

//edit 1
I have started to suspect that once again they have released in-proper kernel source which has incomplete or broken functions in it. Not pointing any fingers yet...
Will compare kernel binaries soon and trying to find it out.

//edit 2
All string based data seems to be matching but binary code got bunch of differences in them.
Using same kernel source code, using same .config & Makefile, using same make parameter, using same cross-compiler should generate very-very similar kernel binaries.
Now I might try to use built kernel with zyxel firmware and see if d_suspdtime works properly.

It may be required to set it every time it boot up because I think zero is the default value when system is up.

The way to set it is to echo the number of minute to /proc/d_suspdtime

Last edited by chorus (2009-05-30 16:07:13)

sala · 2009-05-31 20:46:56

chorus wrote:
It may be required to set it every time it boot up because I think zero is the default value when system is up.

I know already all of this. Problem is that when disk state changes it resets it back to zero.
This state is also stated at d_suspdtime. There are 4 states - no disk, reading, not reading, standby.

I was trying to compile kernel and boot up zyxel firmware but this kernel source they offer is not even booting firmware user-space.
Now when I got some time I will look up if I can fix this time reset problem by debugging all related parameters with printk.
I must say that this is very frustrating. I might also setup a cron script which could renew d_suspdtime parameter with rule "cron script interval = d_suspdtime - 1".

chorus wrote:
The way to set it is to echo the number of minute to /proc/d_suspdtime

Actually zyxel firmware does not use echo method. Zyxel uses ioctl's to communicate with /dev/btncpy, which will set d_suspdtime time.

Code:

ioctl(dev_file_desc, GADGETFS_FIFO_FLUSH, minutes);

I have also tried this but resetting back to zero behavior is still present.

adrianaitken · 2009-06-02 01:01:11

If you upgrade to firmware 3.12 under the admin screen (normal setup, not ffp), you can set the timeout - I use 0 (zero) and it doesn't seem to power down the disks at all.
Either that or my disks don't make their click sound as they power down and my website is held in virtual memory somewhere.

sala · 2009-06-02 09:31:13

adrianaitken wrote:
If you upgrade to firmware 3.12 under the admin screen (normal setup, not ffp), you can set the timeout - I use 0 (zero) and it doesn't seem to power down the disks at all.
Either that or my disks don't make their click sound as they power down and my website is held in virtual memory somewhere.

0 (zero) means unlimited time and no standby will never happen.
Standby time problem I am describing is only happening when using kernel built from 3.12 gpl sources available from zyxel.

Mijzelf · 2009-10-09 13:08:12

The provided 2.10 kernelsources doesn't equal to the fw 2.10 kernel either. I build a kernel following the readme directions, but after booting it I get a line '//--- power saving time = 180 ---//' in dmesg, repeating each 3 minutes as long as the drive isn't spinned down.
Never saw that line before.

sala · 2009-10-09 16:16:06

I know, the source is somewhere between.
But in my case I did find out that after umounting my 2TB hdd, d_suspdtime started working correctly, so it must be some incompatibility or issue with two separate drives, as zyxel does not support this mode (just rair1, raid0 and jbod is supported).
Weird think is that disconecting 2TB WD and using just 750GB samsung then d_suspdtime is not working again.

Mijzelf · 2009-11-23 10:55:40

On my box d_suspdtime seems to work correctly. I have two disks, one 500GB containing a singledisk raid1 array to satisfy the firmware neediness, and a 1TB disk, which is mostly unmounted. It's only mounted once a week to make an rsnapshot.
The box is running the 3.12 kernel, without your hd patches, compiled with the codesourcery compiler. Firmware 2.10 is running on top of it.

Mijzelf · 2009-11-23 23:39:37

The 'echo nnn >/proc/d_suspdtime' function has two functions.
echo n >/proc/d_suspdtime sets the suspension time to n minutes, and
echo n,m >/proc/d_suspdtime sets channel n to state m, where the only valid value for m is 0. The action done when called is

Code:

hd_flag[channelIndex]  = 0;
SATA_hd_read_write[channelIndex] = 0;   // SATA_HD_NO_ACTIVE
SATA_State_Counter[channelIndex] = 0;
SendPowerSavingModeCommand(channelIndex);

So far so good. The problem is that in this file (linux/arch/arm/mach-mv88fxx81/LSP/mvSata/mvLinuxIalHt.c ) SATA_State_Counter is declared as extern unsigned long [4], while the implementation in linux/arch/arm/mach-mv88fxx81/Board/SATA/CoreDriver/mvStorageDev.c is unsigned short [2].
So putting channel 1 asleep using /proc/d_suspdtime has a nasty side effect.

Maybe this is the source of your problem, sala?

sala · 2009-11-24 17:02:38

Thanks for looking into it. I was using echo nnn >/proc/d_suspdtime and ioctl(dev_file_desc, GADGETFS_FIFO_FLUSH, minutes) to /dev/btncpy bethod to set suspend time but I did never figured out why it did get reseted back to 0. So I gave up on this because lack of time and its hard for me to restart debugging when a lot of time has passed.

I probably try to run vanialla kernel on it. I think it is more useful thing to do and hopefully not to painful since many 88F5182 devices are already supported

DSM-G600, DNS-3xx and NSA-220 Hack Forum

Announcement

#1 2008-09-29 14:43:41

HDD spindown

Code:

Code:

Code:

Code:

#2 2008-09-29 15:19:20

Re: HDD spindown

#3 2009-03-14 20:20:57

Re: HDD spindown

Code:

Code:

#4 2009-03-26 15:47:56

Re: HDD spindown

#5 2009-04-01 16:57:05

Re: HDD spindown

#6 2009-05-20 20:14:42

Re: HDD spindown

#7 2009-05-21 09:02:37

Re: HDD spindown

chorus wrote:

#8 2009-05-30 16:05:14

Re: HDD spindown

sala wrote:

chorus wrote:

#9 2009-05-31 20:46:56

Re: HDD spindown

chorus wrote:

chorus wrote:

Code:

#10 2009-06-02 01:01:11

Re: HDD spindown

#11 2009-06-02 09:31:13

Re: HDD spindown

adrianaitken wrote:

#12 2009-10-09 13:08:12

Re: HDD spindown

#13 2009-10-09 16:16:06

Re: HDD spindown

#14 2009-11-23 10:55:40

Re: HDD spindown

#15 2009-11-23 23:39:37

Re: HDD spindown

Code:

#16 2009-11-24 17:02:38

Re: HDD spindown

Board footer