Re: SOLVED: Debian ARM install on a QNAP HS-210
On Wed, 2015-01-21 at 07:46 +1300, mw@wiimail.com wrote:
> Hi Ian
>
> Thanks for that.
>
> I'm happy to help bugtest a proper long term solution for this, or
> whatever I can do to help...
Thank you, I'm overdue to have a look into this stuff.
I've CC'd #712841 so this info ends up in a safe place (also not
trimming quotes for the same reason).
> # cat /proc/cpuinfo
> processor : 0
> model name : Feroceon 88FR131 rev 1 (v5l)
> Features : swp half thumb fastmult edsp
> CPU implementer : 0x56
> CPU architecture: 5TE
> CPU variant : 0x2
> CPU part : 0x131
> CPU revision : 1
>
> Hardware : QNAP TS-119/TS-219
> Revision : 0000
> Serial : 0000000000000000
>
> I'm running sid by the way...
> The actual model name is "HS-210", just as a reminder...
> And I did not change the serial to zero, that is what it actually shows.
Ack, thanks for making it clear.
> qcontrol is a symlink indeed, and originally pointed to ts219.lua
> I have since hacked my own cute hs210.lua to stop the beeps and temp
> checks.
FYI ths is the right thing to have done for the time being, you could
also have safely have edited ts219.lua directly since Debian won't
overwrite your changes.
> There are no files in /etc/qcontrol.d
>
> Ah, just before I forget...
> Any idea if one should be concerned with the longevity of the flash mem?
> Like should I try to minimise writes to it, like avoiding updating the
> kernel too often etc?
Unless by "too often" you mean several thousand times a day I wouldn't
worry about it ;-)
> It seems reinstalling qcontrol triggers a flash mem update too...
This is because qcontrol is included in the initramfs so that it can
disable the h/w watchdog early on boot, specifically before any
potentially long running fsck's etc start.
> Also, in my initial attempt to stop the beeping I fiddled with the
> runlevels (via systemctl),
> and then later had troubles to get qcontrol to consistently start again
> on boot.
> It seems there is both a qcontrol and qcontrold, which I took a while to
> realise.
Correct. qcontrold starts the daemon in the background early on so it
can get going, while qcontrol happens at the end to beep and signal the
end of boot, it also changes the LEDs from flashing red to green etc.
> I had to resort to rc.update.d to get the runlevels for both back to
> normal
> (it was complaining about non LSB defaults or something - btw, I have no
> idea what is the state of systemd in sid or in debian in general?)
>
> But something is still amiss... qcontrol seems to come up rather
> randomly...
> It did not come up two boots ago, but it came up on this last boot, and
> I haven't touched any conf in between...
> This seems to be a recurring theme...
> Maybe it's the start up timing? I think qcontrol.d needs to go first...
Yes, it does. On my system qcontrold happens in rcS.d and qcontrol in rc
$runlevel.d. I suppose there is some update-rc.d invocation which would
restore the defaults?
> Finally, the contents of ts219.lua:
Thanks,
Ian.
>
> # cat ts219.lua
> --[[
> Debian configuration file for qcontrol (LUA syntax)
> Supports QNAP TS-110, TS-119, TS-210, TS-219 and TS-219P.
> --]]
>
> register("ts219")
>
> -- Requires CONFIG_KEYBOARD_GPIO enabled in the kernel and
> -- the kernel module gpio_keys to be loaded.
> register("evdev", "/dev/input/by-path/platform-gpio-keys-event",
> 408, "restart_button",
> 133, "media_button")
>
> register("system-status")
>
> -- Set to "false" to suppress the sounding of the buzzer
> buzzer = true
>
> function system_status( status )
> logprint("System status: "..status)
> if status == "start" then
> piccmd("statusled", "greenon")
> piccmd("powerled", "on")
> if buzzer then piccmd("buzzer", "short") end
> elseif status == "stop" then
> piccmd("statusled", "redon")
> piccmd("powerled", "1hz")
> if buzzer then piccmd("buzzer", "short") end
> else
> logprint("Unknown system status")
> end
> end
>
> function power_button( time )
> os.execute("poweroff")
> end
>
> function restart_button( time )
> os.execute("reboot")
> end
>
> function media_button( time )
> piccmd("usbled", "8hz")
> end
>
> fanfail = 0
>
> function fan_error( )
> fanfail = fanfail + 1
> if fanfail == 3 then
> logprint("ts219: fan error")
> piccmd("statusled", "red2hz")
> piccmd("buzzer", "long")
> else
> if fanfail == 10 then
> fanfail = 0
> end
> end
> end
>
> function fan_normal( )
> piccmd("statusled", "greenon")
> fanfail = 0
> end
>
> last_temp_log = nil
> last_temp_value = 0
>
> function logtemp( temp )
> local now = os.time()
>
> local function should_log( )
> local delta_temp = math.abs(temp - last_temp_value)
> local delta_time = os.difftime(now, last_temp_log)
>
> -- Haven't previously logged, log now for the first time
> if ( not last_temp_log ) then
> return true
> end
> -- Temperature has changed by more than 5
> if ( delta_temp >= 5 ) then
> return true
> end
> -- More than 5 minutes have elapsed...
> if ( delta_time >= 300 ) then
> if ( delta_temp > 1 ) then
> --- ...and the change is by more than +/-1
> return true
> else
> --- ...insignificant change, wait another 5 minutes
> last_temp_log = now
> return false
> end
> end
> -- Otherwise no need to log
> return false
> end
>
> if ( should_log() ) then
> logprint(string.format("ts219: temperature %d", temp))
> last_temp_log = now
> last_temp_value = temp
> end
> end
>
> last_fan_setting = nil
>
> function setfan( temp, speed )
> if ( ( not last_fan_setting ) or
> ( last_fan_setting ~= speed ) ) then
> logprint(string.format("ts219: temperature %d setting fan to \"%s\"",
> temp, speed))
> end
> piccmd("fanspeed", speed)
> last_fan_setting = speed
> end
>
> -- hysteresis implementation:
> -- - - > 35 > - - - > 40 > - - - > 50 > - - - > 65 > - - -
> -- silence -- low -- medium -- high -- full |
> -- - - < 32 < - - - < 35 < - - - < 45 < - - - < 55 < - - -
> function temp( temp )
> logtemp(temp)
> if last_fan_setting == "full" then
> if temp < 55 then
> setfan(temp, "high")
> end
> elseif last_fan_setting == "high" then
> if temp > 65 then
> setfan(temp, "full")
> elseif temp < 45 then
> setfan(temp, "medium")
> end
> elseif last_fan_setting == "medium" then
> if temp > 50 then
> setfan(temp, "high")
> elseif temp < 35 then
> setfan(temp, "low")
> end
> elseif last_fan_setting == "low" then
> if temp > 40 then
> setfan(temp, "medium")
> elseif temp < 32 then
> setfan(temp, "silence")
> end
> elseif last_fan_setting == "silence" then
> if temp > 35 then
> setfan(temp, "low")
> end
> else
> setfan(temp, "high")
> end
> end
>
> confdir("/etc/qcontrol.d")
> --
> -- Local variables:
> -- mode: lua
> -- indent-level: 8
> -- End:
>
>
> Thanks again...
>
> Max
>
>
>
> On 2015-01-20 21:40, Ian Campbell wrote:
> > On Mon, 2015-01-19 at 11:55 +0800, Paul Wise wrote:
> >> On Mon, Jan 19, 2015 at 11:47 AM, Max wrote:
> >>
> >> > One quick question...
> >> > qcontrol is complaining about a fan error every couple of minutes which
> >> > includes a beep.
> >> > But the HS-210 is passively cooled and doesn't have a fan.
> >> > What is the proper way to address this?
> >>
> >> That sounds like a bug in qcontrol to me, possibly the same one as
> >> this, even though it is different hardware:
> >>
> >> https://bugs.debian.org/712841
> >>
> >> qcontrol maintainer, can you advise what should happen here?
> >
> > Rereading the buglog it seems like I should follow through on whatever
> > plan I had in mind a year ago and then forgot about (my memory stopped
> > about halfway through that log...).
> >
> > The main unresolved issue is how to detect fanless vs fan systems, in
> > the absence of an ability to autodetect that I'd always want to err on
> > the side of defaulting to controlling the fans, so some sort of manual
> > intervention would be needed on a fanless system, but it could be made
> > easier.
> >
> > In the meantime some more info on the HS-210 would be useful please
> > Max:
> >
> > * What does the hardware line in /proc/cpuinfo say?
> > * /etc/qcontrol.conf should be a symlink, what does it point to?
> > * Can you paste the contents of /etc/qcontrol.conf (whether it is
> > a link or not) please?
> > * Are there any files in /etc/qcontrol.d?
> >
> > As a workaround until it can be fixed properly you can just edit out
> > the
> > lines which cause the buzzing from the config. Debian will preserve
> > those changes on upgrade etc as usual.
> >
> > Thanks,
> > Ian.
>
>
Reply to: