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

I could not come up with a set of steps which would faithfully reproduce the TWSI problem at will.  However I do get it within 24 hours if I enable ntpd and fanctrl.

This is my current setup which has now been up for 5 days without TWSI problems.
I am not running ntpd.
adjtimex is set to 9968
fanctrl is running at an interval of 15 sec (I want the fan to start quickly if it is off and the temp starts to rise or the drives turn on)
ffp 0.5 is running from a usb drive (/mnt/usb1/ffp)
I've added the following to crontab:

/bin/echo "37 * * * */ffp/bin/ntpdate ca.pool.ntp.org >>/ffp/log/ntpd.log 2>&1" >> $CRONTXT

which required the following fix:

echo 'ntp             123/tcp' >>/etc/services
echo 'ntp             123/udp' >>/etc/services

This results in a step change of approx -2.85~-2.90 seconds at 37 minutes past every hour.

Cheers,
Dave

jesbo wrote:

I changed my fanctl.config interval down from 300 seconds to 120 seconds and I am now seeing TWSI errors in less than 24 hours.

fonz wrote:

Maybe it's simultaneous accesses to the TWSI that creates the problems.

Still looks like what fonz said.

I use the ntpd option '-x', this works so far.

no adjtimex modification, no complaint in the syslog from the ntpd at all.
I had some TWSI errors before, but I could not reproduce them.

I can't test things right now because my seagate SD15 disks are beeing replaced by WDs at the moment.

the debian etch manpage is a little bit more verbose:

-x     Ordinarily, if the time is to be adjusted more than 128 ms, it is stepped, not gradually slewed.  This option forces the time to  be  slewed  in
              all  cases.   Note:  Since the slew rate is limited to 0.5 ms/s, each second of adjustment requires an amortization interval of 2000 s.  Thus an
              adjustment of many seconds can take hours or days to amortize.

one thing needs to be evaluated:
if adusting the time (kernel/software time or rtc/hardware time?) uses the TWSI and could trigger conflicts with the fan regulation
then this might caus problem too because the process of slewing is (or seems to me) just adusting the time every second.
mean: It is adjusted much more often and every time it could lock up the TWSI.
I do not have a decent understanding of the TWSI and what the rtc and kernel clock has to do with it.

the ntpd that comes with ffp0.5 states the x option will raise the slew limit to 600seconds.

there is one thing:
I synced the raid1 several times with a running ntpd (no modifications and no adjtimex). I've never noticed a TWSI error. (room temp was about 20°C)
(for one time I'm not sure as the fan kept running at high speed even after the rebuild was done. I did not check the log.
but it could also be the residual heat)

then I moved the unit to a warmer place (my apartment, ~25°C) and put it in a rather closed cupboard so the unit went rather hot while syncing and this was the first time I noticed the TWSI errors.

so.. unless prooven otherwise, I think this might also be a temperature related issue.

theory: when the unit gets hot, the fan is set to 10.000 but it will never reach 10k, Ive seen only ~6k.
as far as I know, the regulation software tries to reset the speed if the current speed does not match the required speed.
maybe.. this uses the TWSI excessively an causes the error alsong with the ntpd working hard to keep the clock (it might actually be a decent /dev/urandom ;-) ) in sync.

can anyone proof this? (doesn't matter if you proof it true or wrong )

after >1week of continous operation with the -x option:

root@CH3SNAS:~# cat /ffp/etc/ntp.drift 
5.997
root@CH3SNAS:~# adjtimex 
    mode:         0
-o  offset:       0
-f  frequency:    585826
    maxerror:     16384000
    esterror:     16384000
    status:       64 (UNSYNC)
-p  timeconstant: 0
    precision:    1
    tolerance:    33554432
-t  tick:         9960
    time.tv_sec:  1227743503
    time.tv_usec: 515711
    return value: 5 (clock not synchronized)
root@CH3SNAS:~#

no TWSI errors either.
and there are also no log messages from the ntpd about the time beeing reset.
it just stays in sync.
works great.

maybe the -x switch should be set per default with the ntpd package for the ch3nas/dns323

Just curious.... when using the "-x" flag on ntpd, are you also running the fanctl program?  I initially (several weeks ago) tried the -x flag and when fanctl was running I still saw TWSI errors.  I'll try it again, though.

BTW... I run ffp from my USB drive so I still use the -f /ffp/etc/ntp.drift option.  So drive spinup is avoided.

perssinaasappel wrote:

nope, running the standard fancontrol that comes with the box. (Don't understand why people want to change this, it's good as it is.)

Thanks.   

I liked (and tried) fanctl for 2 reasons:

1) Shuts off fan when DNS is completely idle and temps drop below 100F.
2) Allows fan to spin at higher speeds quicker when NAS starts heating up (good for me because my WD Caviar Black drives get pretty warm when spinning).

With all the different answers in this thread I kinda lost track of the definite solutiuon for this problem.

TWSI: mvTwsiStartBitSet ERROR - Start Clear bit TimeOut .
TWSI: mvTwsiStopBitSet ERROR - Stop bit TimeOut .

I'm running funplug 0.5.x on a USB Stick on a CH3SNAS with firmware 1.05.

Also... when I install ntpd according to the following howto: http://nas-tweaks.net/CH3SNAS:Tutorials/ntp
I wonder where the line timeserv=de.pool.ntp.org (in my case nl.pool.ntp.org) should end up. My fun_plug.local currently looks like this:

#!/ffp/bin/sh
PATH=/ffp/sbin:/usr/sbin:/sbin:/ffp/bin:/usr/bin:/bin

# Adjust clock speed to reduce drift
# See 'adjtimex -h' for available options.
# 9965 works for my DNS-323, ymmv.
adjtimex -t 9960

# Set local timezone
# For a list of timezone strings see:
# http://www.nas-tweaks.net/CH3SNAS:Tutor … ne_Strings

# Europe/Berlin
echo 'CET-1CEST-2,M3.5.0/02:00:00,M10.5.0/03:00:00' >/etc/TZ
timeserv=nl.pool.ntp.org

# This removes firmware cronjobs that interfere with ntpd.
#crontab -l | grep -vw '/usr/sbin/daylight' | grep -vw '/usr/sbin/rtc' | crontab -

# Clear root password for convenient login (won't work with ssh)
#usermod -p '' root

# You might want to ensure that sshd is started.
#chmod a+x /ffp/start/sshd.sh

When starting ntpd.sh from the shell I also get the following warning/error

grep: illegal option -- w
BusyBox v1.00-pre1 (2008.09.02-11:43+0000) multi-call binary

Usage: grep [-ihHnqvs] PATTERN [FILEs...]

grep: illegal option -- w
BusyBox v1.00-pre1 (2008.09.02-11:43+0000) multi-call binary

Usage: grep [-ihHnqvs] PATTERN [FILEs...]

grep: illegal option -- w
BusyBox v1.00-pre1 (2008.09.02-11:43+0000) multi-call binary

Usage: grep [-ihHnqvs] PATTERN [FILEs...]

Starting /ffp/bin/ntpd -g -f /ffp/etc/ntp.drift

My ntpd.sh is default and looks like this

#!/ffp/bin/sh

# PROVIDE: ntpd
# REQUIRE: SERVERS
# BEFORE: LOGIN

. /ffp/etc/ffp.subr

name="ntpd"
command="/ffp/bin/ntpd"
ntpd_flags="-g -f /ffp/etc/ntp.drift"
required_files="/ffp/etc/ntp.conf"
start_cmd="ntpd_start"

ntpd_start()
{
        # fix /etc/services
        if ! grep -w ntp /etc/services >/dev/null; then
                echo "ntp 123/udp" >>/etc/services

        fi

        # remove rtc and daylight cron jobs
        crontab -l | grep -vw '/usr/sbin/daylight' | grep -vw '/usr/sbin/rtc' | crontab -

        proc_start $command
}

run_rc_command "$1"

The time seems to be adjusted ok.

fonz wrote:

1) A power cycle is the only rebliable option to make this error disappear. It is still unknown what the original cause is.
2) IIrc, timeserv is an old variable, and nas-tweaks should be updated on this.

1. In my blog, many reported that stopping the ntp-service and setting the time every x minutes solves the problem
2. I will change the tutorial over the next few days to reflect the findings of 1.) (Still will preserve the Timezones, not to worry)

fonz wrote:

1) A power cycle is the only rebliable option to make this error disappear. It is still unknown what the original cause is.
2) IIrc, timeserv is an old variable, and nas-tweaks should be updated on this.
3) You're $PATH is wrong and doesn't include /ffp/bin before /bin. Are you using the modified firmware?

1] Recycled power and everything is back to normal again. ntpd is still running
2] ...
3] I installed funplug from the manual by Dennis ( http://www.aroundmyroom.com/2009/01/27/ … laces-all/ ) and used the fun_plug.tgz from http://www.inreto.de/dns323/fun-plug/0.5/fun_plug.tgz. Somewhere in some other manual I used along the way I was instructed to copy /ffp/etc/examples/fun_plug.local to /ffp/etc which led to the current $PATH.

Here's the content from the example fun_plug.local contained in the tgz file.

#!/ffp/bin/sh
PATH=/ffp/sbin:/ffp/bin

# Adjust clock speed to reduce drift
# See 'adjtimex -h' for available options.
# 9965 works for my DNS-323, ymmv.
adjtimex -t 9965

# Set local timezone
# For a list of timezone strings see:
# http://www.nas-tweaks.net/CH3SNAS:Tutor … ne_Strings

# Europe/Berlin
echo 'CET-1CEST-2,M3.5.0/02:00:00,M10.5.0/03:00:00' >/etc/TZ

# This removes firmware cronjobs that interfere with ntpd.
#crontab -l | grep -vw '/usr/sbin/daylight' | grep -vw '/usr/sbin/rtc' | crontab -

# Clear root password for convenient login (won't work with ssh)
#usermod -p '' root

# You might want to ensure that sshd is started.
#chmod a+x /ffp/start/sshd.sh

I think it should be 'PATH=/ffp/sbin:/usr/sbin:/sbin:/ffp/bin:/usr/bin:/bin'. I have edited it in my fun_plug.local but somehow it seems to get changed after every reboot.