Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#712841: qcontrol: Fan error reported on TS109
108 views
Skip to first unread message
Dermot O'Dwyer
Jun 19, 2013, 9:00:02 PM6/19/13
to
Package: qcontrol
Version: 0.5.1-3
Severity: important
Tags: upstream
On a TS109, after upgrading from 0.4.2-7+wheezy2 to 0.5.1-3 qcontrol then
reports fan error in syslog and beeping every minute approximately.
Setting SOUND_BUZZER=no in /etc/default/qcontrol does not stop the beeping.
I have linked /etc/qcontrol.conf to a new conf with the section commented out
stop the errors/beeping.
--[[
logprint("ts209: fan error")
piccmd("statusled", "red2hz")
piccmd("buzzer", "long")
--]]
But this is only half the work as the fan_error function is still being
triggered.
As there does not seem to be a way to easily distinguish the TS109 and TS209
using /proc/cpuinfo there are a few choices:
a) ask the user at install time which they have and create the appropriate
symlink /etc/qcontrol.conf -> qcontrol/ts109.lua
b) Check for the presence of fan/2nd disk to determine if the QNAP is a TS209
This was reported upstream but doesn't appear to be active really -
http://code.google.com/p/qcontrol/issues/detail?id=5
-- System Information:
Debian Release: jessie/sid
APT prefers testing
APT policy: (550, 'testing'), (500, 'oldstable')
Architecture: armel (armv5tel)
Kernel: Linux 3.2.0-4-orion5x
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages qcontrol depends on:
ii libc6 2.17-3
ii liblua5.1-0 5.1.5-4
ii udev 175-7.2
qcontrol recommends no packages.
qcontrol suggests no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Version: 0.5.1-3
Severity: important
Tags: upstream
On a TS109, after upgrading from 0.4.2-7+wheezy2 to 0.5.1-3 qcontrol then
reports fan error in syslog and beeping every minute approximately.
Setting SOUND_BUZZER=no in /etc/default/qcontrol does not stop the beeping.
I have linked /etc/qcontrol.conf to a new conf with the section commented out
stop the errors/beeping.
--[[
logprint("ts209: fan error")
piccmd("statusled", "red2hz")
piccmd("buzzer", "long")
--]]
But this is only half the work as the fan_error function is still being
triggered.
As there does not seem to be a way to easily distinguish the TS109 and TS209
using /proc/cpuinfo there are a few choices:
a) ask the user at install time which they have and create the appropriate
symlink /etc/qcontrol.conf -> qcontrol/ts109.lua
b) Check for the presence of fan/2nd disk to determine if the QNAP is a TS209
This was reported upstream but doesn't appear to be active really -
http://code.google.com/p/qcontrol/issues/detail?id=5
-- System Information:
Debian Release: jessie/sid
APT prefers testing
APT policy: (550, 'testing'), (500, 'oldstable')
Architecture: armel (armv5tel)
Kernel: Linux 3.2.0-4-orion5x
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages qcontrol depends on:
ii libc6 2.17-3
ii liblua5.1-0 5.1.5-4
ii udev 175-7.2
qcontrol recommends no packages.
qcontrol suggests no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Ian Campbell
Jun 30, 2013, 11:10:01 AM6/30/13
to
On Thu, 2013-06-20 at 01:54 +0100, Dermot O'Dwyer wrote:
> Package: qcontrol
> Version: 0.5.1-3
> Severity: important
> Tags: upstream
>
> On a TS109, after upgrading from 0.4.2-7+wheezy2 to 0.5.1-3 qcontrol then
> reports fan error in syslog and beeping every minute approximately.
How annoying!
> Package: qcontrol
> Version: 0.5.1-3
> Severity: important
> Tags: upstream
>
> On a TS109, after upgrading from 0.4.2-7+wheezy2 to 0.5.1-3 qcontrol then
> reports fan error in syslog and beeping every minute approximately.
> Setting SOUND_BUZZER=no in /etc/default/qcontrol does not stop the beeping.
boot.
> I have linked /etc/qcontrol.conf to a new conf with the section commented out
> stop the errors/beeping.
place -- Debian handles modifications of this sort very well on upgrade.
> --[[
> logprint("ts209: fan error")
> piccmd("statusled", "red2hz")
> piccmd("buzzer", "long")
> --]]
>
> But this is only half the work as the fan_error function is still being
> triggered.
you know for sure it wasn't being triggered previously too?
> As there does not seem to be a way to easily distinguish the TS109 and TS209
> using /proc/cpuinfo there are a few choices:
>
> a) ask the user at install time which they have and create the appropriate
> symlink /etc/qcontrol.conf -> qcontrol/ts109.lua
alternative.
> b) Check for the presence of fan/2nd disk to determine if the QNAP is a TS209
TS-219 via GPIO 44. Unless you've got a 209 to compare your 109 against
though I'm not sure how to find out.
Perhaps Martin (CCd) has a 209 and/or can ask QNAP?
>
> This was reported upstream but doesn't appear to be active really -
> http://code.google.com/p/qcontrol/issues/detail?id=5
https://gitorious.org/qcontrol . I'm using the Debian bugtracker for
upstream too so this report is already in the right place.
Ian.
Dermot O'Dwyer
Jul 5, 2013, 9:50:02 PM7/5/13
to
On 30 June 2013 15:58, Ian Campbell <i...@hellion.org.uk> wrote:
> In 0.4.2-7+wheezy2 the fan_error function would have been empty, so do
> you know for sure it wasn't being triggered previously too?
I reinstalled 0.4.2-7+wheezy2 and added beep to the fan error
> In 0.4.2-7+wheezy2 the fan_error function would have been empty, so do
> you know for sure it wasn't being triggered previously too?
function. Got plenty of beeps so it would appear that it was always
triggered originally. There did not appear to be any ill effects
resulting from the original version so I suppose having it blank for a
TS109 it later ones will probably have qcontrol run OK. A few of the
other things could probably be cleared out again for a TS-109 too.
> > As there does not seem to be a way to easily distinguish the TS109 and TS209
> > using /proc/cpuinfo there are a few choices:
> >
> > a) ask the user at install time which they have and create the appropriate
> > symlink /etc/qcontrol.conf -> qcontrol/ts109.lua
>
> I'd rather not do this (ask the user) unless there is absolutely no
> alternative.
>
> > b) Check for the presence of fan/2nd disk to determine if the QNAP is a TS209
>
> It's possible that there is a GPIO e.g. you can distinguish TS-119 from
> TS-219 via GPIO 44. Unless you've got a 209 to compare your 109 against
> though I'm not sure how to find out.
>
> Perhaps Martin (CCd) has a 209 and/or can ask QNAP?
>
Thanks,
Dermot
Martin Michlmayr
Jul 10, 2013, 11:00:03 AM7/10/13
to
* Dermot O'Dwyer <der...@gmail.com> [2013-07-06 02:38]:
I cannot remember whether GPIO 44 also works on the Orion models.
--
Martin Michlmayr
http://www.cyrius.com/
> > It's possible that there is a GPIO e.g. you can distinguish TS-119 from
> > TS-219 via GPIO 44. Unless you've got a 209 to compare your 109 against
> > though I'm not sure how to find out.
> >
> > Perhaps Martin (CCd) has a 209 and/or can ask QNAP?
>
> The only other QNAP I have is a TS-119 so can't really help too much.
I have a TS-209 and will try to find the time to check. Unfortuntely,
> > TS-219 via GPIO 44. Unless you've got a 209 to compare your 109 against
> > though I'm not sure how to find out.
> >
> > Perhaps Martin (CCd) has a 209 and/or can ask QNAP?
>
> The only other QNAP I have is a TS-119 so can't really help too much.
I cannot remember whether GPIO 44 also works on the Orion models.
--
Martin Michlmayr
http://www.cyrius.com/
Ian Campbell
Aug 15, 2013, 5:30:02 AM8/15/13
to
On Wed, 2013-07-10 at 15:42 +0100, Martin Michlmayr wrote:
> * Dermot O'Dwyer <der...@gmail.com> [2013-07-06 02:38]:
> > > It's possible that there is a GPIO e.g. you can distinguish TS-119 from
> > > TS-219 via GPIO 44. Unless you've got a 209 to compare your 109 against
> > > though I'm not sure how to find out.
> > >
> > > Perhaps Martin (CCd) has a 209 and/or can ask QNAP?
> >
> > The only other QNAP I have is a TS-119 so can't really help too much.
>
> I have a TS-209 and will try to find the time to check. Unfortuntely,
> I cannot remember whether GPIO 44 also works on the Orion models.
Did you have any luck with this?
> * Dermot O'Dwyer <der...@gmail.com> [2013-07-06 02:38]:
> > > It's possible that there is a GPIO e.g. you can distinguish TS-119 from
> > > TS-219 via GPIO 44. Unless you've got a 209 to compare your 109 against
> > > though I'm not sure how to find out.
> > >
> > > Perhaps Martin (CCd) has a 209 and/or can ask QNAP?
> >
> > The only other QNAP I have is a TS-119 so can't really help too much.
>
> I have a TS-209 and will try to find the time to check. Unfortuntely,
> I cannot remember whether GPIO 44 also works on the Orion models.
Ian.
Martin Michlmayr
Aug 17, 2013, 9:20:02 AM8/17/13
to
* Ian Campbell <i...@hellion.org.uk> [2013-08-15 10:19]:
yet.
> > I have a TS-209 and will try to find the time to check. Unfortuntely,
> > I cannot remember whether GPIO 44 also works on the Orion models.
>
> Did you have any luck with this?
I sent an email to QNAP a few days ago but haven't received a reply
> > I cannot remember whether GPIO 44 also works on the Orion models.
>
> Did you have any luck with this?
yet.
Ian Campbell
Jan 2, 2014, 7:30:03 PM1/2/14
to
On Sat, 2013-08-17 at 14:05 +0100, Martin Michlmayr wrote:
> * Ian Campbell <i...@hellion.org.uk> [2013-08-15 10:19]:
> > > I have a TS-209 and will try to find the time to check. Unfortuntely,
> > > I cannot remember whether GPIO 44 also works on the Orion models.
> >
> > Did you have any luck with this?
>
> I sent an email to QNAP a few days ago but haven't received a reply
> yet.
I suppose you never heard back?
> * Ian Campbell <i...@hellion.org.uk> [2013-08-15 10:19]:
> > > I have a TS-209 and will try to find the time to check. Unfortuntely,
> > > I cannot remember whether GPIO 44 also works on the Orion models.
> >
> > Did you have any luck with this?
>
> I sent an email to QNAP a few days ago but haven't received a reply
> yet.
Looking back at the original report it occurs to me now (a bit late)
that even if we suppress the beep etc the fact that the PIC is
(apparently) generating 0x73 bytes (fan1 error) is still a bit
annoying/wasteful. I wonder if there is some way to stop it. Or is it
the fact that we have tried to set the fan which is the issue?
Dermon, does commenting out the content of temp_high and temp_low in
qcontrol.conf and rebooting still end up with fan_error getting called
lots?
Ian.
Martin Michlmayr
Jan 3, 2014, 2:40:02 AM1/3/14
to
* Ian Campbell <i...@hellion.org.uk> [2014-01-03 00:19]:
> I suppose you never heard back?
Correct; I'll ask again.
Dermot O'Dwyer
Jan 9, 2014, 5:00:02 AM1/9/14
to
On 3 January 2014 00:19, Ian Campbell <i...@hellion.org.uk> wrote:
> Dermon, does commenting out the content of temp_high and temp_low in
> qcontrol.conf and rebooting still end up with fan_error getting called
> lots?
Yes, fan_error still gets called when there are empty temp_high and
> Dermon, does commenting out the content of temp_high and temp_low in
> qcontrol.conf and rebooting still end up with fan_error getting called
> lots?
temp_low functions.
Dermot
Ian Campbell
Jan 9, 2014, 3:10:02 PM1/9/14
to
On Thu, 2014-01-09 at 09:46 +0000, Dermot O'Dwyer wrote:
> On 3 January 2014 00:19, Ian Campbell <i...@hellion.org.uk> wrote:
> > Dermon, does commenting out the content of temp_high and temp_low in
> > qcontrol.conf and rebooting still end up with fan_error getting called
> > lots?
>
> Yes, fan_error still gets called when there are empty temp_high and
> temp_low functions.
I suppose there are few other things which could be tried if you are
> On 3 January 2014 00:19, Ian Campbell <i...@hellion.org.uk> wrote:
> > Dermon, does commenting out the content of temp_high and temp_low in
> > qcontrol.conf and rebooting still end up with fan_error getting called
> > lots?
>
> Yes, fan_error still gets called when there are empty temp_high and
> temp_low functions.
able, there are some #defines for PIC commands relating to fans in the
QNAP kernel headers which are not currently used by qcontrol:
include/qnap/pic.h:#define QNAP_PIC_FAN_STOP 0x30
include/qnap/pic.h:#define QNAP_PIC_FAN_ENABLE 0x71
include/qnap/pic.h:#define QNAP_PIC_FAN_DISABLE 0x72
(these aren't used elsewhere in the kernel, so I can't see how qnap's
firmware uses them -- I guess this header is consumed by their
userspace)
Probably the easiest way to test these is to edit ts219.c and where
there is:
call_function("fan_error", "");
instead add (untested):
{
unsigned char code = 0x30;
serial_write(&code, 1);
}
Try this for 0x72 as well. I don't imagine 0x71 would be much use.
Hrm... qcontrol could really use a way to send arbitrary bytes to the
PIC from LUA code.
Ian.
Ian Campbell
Jan 9, 2014, 3:10:02 PM1/9/14
to
On Thu, 2014-01-09 at 09:46 +0000, Dermot O'Dwyer wrote:
> On 3 January 2014 00:19, Ian Campbell <i...@hellion.org.uk> wrote:
> > Dermon, does commenting out the content of temp_high and temp_low in
> > qcontrol.conf and rebooting still end up with fan_error getting called
> > lots?
>
> Yes, fan_error still gets called when there are empty temp_high and
> temp_low functions.
Thanks. Looks like we are reliant on qnap telling us what should be done
> > Dermon, does commenting out the content of temp_high and temp_low in
> > qcontrol.conf and rebooting still end up with fan_error getting called
> > lots?
>
> Yes, fan_error still gets called when there are empty temp_high and
> temp_low functions.
in this case then.
Ian.
Dermot O'Dwyer
Jan 15, 2014, 6:20:02 PM1/15/14
to
The following appears to work OK in ts209.c:
case 0x73:
/* call_function("fan_error", ""); */
No errors in logs.
The rest of qcontrol continues working OK (manual led/buzzer commands).
Dermot
case 0x73:
/* call_function("fan_error", ""); */
{
unsigned char code = 0x30;
serial_write(&code, 1);
}
break;
unsigned char code = 0x30;
serial_write(&code, 1);
}
No errors in logs.
The rest of qcontrol continues working OK (manual led/buzzer commands).
Dermot
Ian Campbell
Jan 16, 2014, 3:40:01 AM1/16/14
to
Thanks for the info, I'll figure some way to integrate that.
Unless we can determine how to distinguish a 209 from a 109 it might
still have to be something which is enabled locally. Martin -- still no
word from QNAP I take it?
I do have some code (in experimental) to ask via debconf when the system
can't be probed (I intended this for use on x86 QNAP boxes), I'd really
much prefer to keep autodetecting on ARM though.
Ian.
Unless we can determine how to distinguish a 209 from a 109 it might
still have to be something which is enabled locally. Martin -- still no
word from QNAP I take it?
I do have some code (in experimental) to ask via debconf when the system
can't be probed (I intended this for use on x86 QNAP boxes), I'd really
much prefer to keep autodetecting on ARM though.
Ian.
Ian Campbell
Jan 16, 2014, 3:40:02 AM1/16/14
to
On Thu, 2014-01-16 at 08:29 +0000, Ian Campbell wrote:
> Unless we can determine how to distinguish a 209 from a 109 it might
> still have to be something which is enabled locally.
It took me about 2s from pressing send to wake up and realise that
> Unless we can determine how to distinguish a 209 from a 109 it might
> still have to be something which is enabled locally.
stopping the fan in the fan error hook might be the right thing to do on
the 209 as well.
Although on the 209 you'd probably want some sort of loud warning, while
on the 109 you would want it to happen silently. So maybe it is still
worth detecting...
Ian.
Martin Michlmayr
Jan 16, 2014, 4:40:02 AM1/16/14
to
* Ian Campbell <i...@hellion.org.uk> [2014-01-16 08:29]:
> Unless we can determine how to distinguish a 209 from a 109 it might
> still have to be something which is enabled locally. Martin -- still no
> word from QNAP I take it?
Unfortunately, I haven't heard from QNAP.
> still have to be something which is enabled locally. Martin -- still no
> word from QNAP I take it?
Axel Sommerfeldt
Apr 14, 2018, 4:10:02 PM4/14/18
to
Just a reminder that this bug is still a thing. And yes, the model can be found in uLinux.conf:
root@qnap119:~# mount -o ro -t ext2 /dev/mtdblock5 /mnt
root@qnap119:~# more /mnt/uLinux.conf
[System]
Model = TS-119
Internal Model = TS-119
...
BTW: Martin, thanks a lot for all the work. Having Debian on a qnap really rocks.
root@qnap119:~# mount -o ro -t ext2 /dev/mtdblock5 /mnt
root@qnap119:~# more /mnt/uLinux.conf
[System]
Model = TS-119
Internal Model = TS-119
...
BTW: Martin, thanks a lot for all the work. Having Debian on a qnap really rocks.
Ian Campbell
Apr 15, 2018, 11:10:03 AM4/15/18
to
On Sun, 2018-04-15 at 16:03 +0200, Martin Michlmayr wrote:
> * Axel Sommerfeldt <axel.som...@f-m.fm> [2018-04-14 22:07]:
> an update for this in stable?
I think it is premature to consider that question without a specific
fix in unstable to be backported in order to make the argument/decision
based on it.
> Since stretch is likely to be the last
> version to support these devices, it might be worth it. OTOH, since
> it's easy to fix by users, it might not be worth pushing more code
> in.
I think /etc/qcontrol.conf is a conffile for a good reason and folks
can and should edit it to support their specific system if need be
without feeling like they are doing something "wrong".
That said, if there are modifications which can be made to the existing
config file installed on this variant which would minimise the
modifications i.e. by adding a simple "has_a_fan = true" which affected
people can set to false then that is something to consider doing I
think.
> Getting the right device from /etc/mtdblock5 is easy, but I've no
> idea how to change the config based on that.
I think you mean /dev/mtdblock5? While mounting that to extract the
configuration might in theory be "easy" I think it is a whole new set
of code which would now need to be written, debugged etc for qcontrol,
which doesn't currently do anything as invasive as mounting or touching
devices which are not "owned" in any sense by the Debian installation.
I'm not even sure it would be within policy for a package to do that
sort of thing in a postinst and I'd certainly be very wary of it going
wrong.
I don't personally have time to work on that (nor a device to test with
in any case) but I'd be happy to look at a tested and well documented
patch.
> Ian, it seems the git repo is out of date (has 0.5.5-2 while unstable
> has 0.5.5-3). The VCS headers are out of date too now with Salsa.
The repo on salsa is up to date I believe, please let me know if not.
I was waiting to have some other reason to upload before fixing the Vcs
fields. The redirector is working for some but not all of them (I
forget which of http and git is working vs broken).
Ian.
> * Axel Sommerfeldt <axel.som...@f-m.fm> [2018-04-14 22:07]:
> > Just a reminder that this bug is still a thing. And yes, the model
> can be found in uLinux.conf:
>
> Ian, do you think it's worth asking the release team if they'd allow
> can be found in uLinux.conf:
>
> an update for this in stable?
I think it is premature to consider that question without a specific
fix in unstable to be backported in order to make the argument/decision
based on it.
> Since stretch is likely to be the last
> version to support these devices, it might be worth it. OTOH, since
> it's easy to fix by users, it might not be worth pushing more code
> in.
I think /etc/qcontrol.conf is a conffile for a good reason and folks
can and should edit it to support their specific system if need be
without feeling like they are doing something "wrong".
That said, if there are modifications which can be made to the existing
config file installed on this variant which would minimise the
modifications i.e. by adding a simple "has_a_fan = true" which affected
people can set to false then that is something to consider doing I
think.
> Getting the right device from /etc/mtdblock5 is easy, but I've no
> idea how to change the config based on that.
I think you mean /dev/mtdblock5? While mounting that to extract the
configuration might in theory be "easy" I think it is a whole new set
of code which would now need to be written, debugged etc for qcontrol,
which doesn't currently do anything as invasive as mounting or touching
devices which are not "owned" in any sense by the Debian installation.
I'm not even sure it would be within policy for a package to do that
sort of thing in a postinst and I'd certainly be very wary of it going
wrong.
I don't personally have time to work on that (nor a device to test with
in any case) but I'd be happy to look at a tested and well documented
patch.
> Ian, it seems the git repo is out of date (has 0.5.5-2 while unstable
> has 0.5.5-3). The VCS headers are out of date too now with Salsa.
The repo on salsa is up to date I believe, please let me know if not.
I was waiting to have some other reason to upload before fixing the Vcs
fields. The redirector is working for some but not all of them (I
forget which of http and git is working vs broken).
Ian.
Martin Michlmayr
Apr 15, 2018, 11:20:02 AM4/15/18
to
* Axel Sommerfeldt <axel.som...@f-m.fm> [2018-04-14 22:07]:
> Just a reminder that this bug is still a thing. And yes, the model can be found in uLinux.conf:
Ian, do you think it's worth asking the release team if they'd allow
an update for this in stable? Since stretch is likely to be the last
version to support these devices, it might be worth it. OTOH, since
it's easy to fix by users, it might not be worth pushing more code in.
it's easy to fix by users, it might not be worth pushing more code in.
Getting the right device from /etc/mtdblock5 is easy, but I've no idea
how to change the config based on that.
Maybe the right thing to do would be to put an update into stable
how to change the config based on that.
documenting this issue properly. This shouldn't be too controversial
for the stable release team.
Ian, it seems the git repo is out of date (has 0.5.5-2 while unstable
has 0.5.5-3). The VCS headers are out of date too now with Salsa.
(My web site doesn't mention this issue either.)
> BTW: Martin, thanks a lot for all the work. Having Debian on a qnap really rocks.
and I'm not doing much apart from responding to some email. :/
Ian Campbell
Apr 15, 2018, 12:40:03 PM4/15/18
to
On Sun, 2018-04-15 at 15:33 +0100, Ian Campbell wrote:
> That said, if there are modifications which can be made to the existing
> config file installed on this variant which would minimise the
> modifications i.e. by adding a simple "has_a_fan = true" which affected
> people can set to false then that is something to consider doing I
> think.
Or if it differs by too much we could install a /etc/qcontrol/ts1xx.lua
> That said, if there are modifications which can be made to the existing
> config file installed on this variant which would minimise the
> modifications i.e. by adding a simple "has_a_fan = true" which affected
> people can set to false then that is something to consider doing I
> think.
file but not attempt to automatically link to it, so people can just
flip the /etc/qcontrol.conf symlink themselves.
Ian.
Martin Michlmayr
Apr 16, 2018, 2:20:03 PM4/16/18
to
* Martin Michlmayr <t...@cyrius.com> [2018-04-16 20:12]:
> As a workaround, until this is fixed, users can create a file
> /etc/qcontrol.d/90_no_fan with:
It needs a .conf extension, so e.g. /etc/qcontrol.d/90-no-fan.conf
> As a workaround, until this is fixed, users can create a file
> /etc/qcontrol.d/90_no_fan with:
It needs a .conf extension, so e.g. /etc/qcontrol.d/90-no-fan.conf
Ian Campbell
Apr 16, 2018, 2:50:03 PM4/16/18
to
On Mon, 2018-04-16 at 20:12 +0200, Martin Michlmayr wrote:
> Do you know if /etc/default is Debian-specific or generic? I'm just
> wondering if the qcontrol configs should read from /etc/default/qcontrol
> (Google suggests Red Hat and SUSE have it too, so I guess that should
> be ok.)
They have a different name/path for it IIRC.
I don't think it's necessary to indirect via /etc/default anyway. Just
write the variable directly into the appropriate /etc/qcontrol/foo.conf
files and have necessary conditionals in there. I believe you can also
call the fan stop function from the config file, perhaps from the
system init module callback or just do it at the top level.
Ian.
> Do you know if /etc/default is Debian-specific or generic? I'm just
> wondering if the qcontrol configs should read from /etc/default/qcontrol
> (Google suggests Red Hat and SUSE have it too, so I guess that should
> be ok.)
They have a different name/path for it IIRC.
I don't think it's necessary to indirect via /etc/default anyway. Just
write the variable directly into the appropriate /etc/qcontrol/foo.conf
files and have necessary conditionals in there. I believe you can also
call the fan stop function from the config file, perhaps from the
system init module callback or just do it at the top level.
Ian.
Martin Michlmayr
Apr 16, 2018, 3:20:03 PM4/16/18
to
* Ian Campbell <i...@debian.org> [2018-04-15 15:33]:
> > Getting the right device from /etc/mtdblock5 is easy, but I've no
> > idea how to change the config based on that.
>
> I think you mean /dev/mtdblock5? While mounting that to extract the
/dev/, yes. But I agree with your concerns.
Anyway, after reading the bug log again and looking at the files,
here's what I think:
Devices affected:
* TS-109
* TS-109 II
* TS-119
* HS-210
The first two are ts-209 devices from the POV of qcontrol and the latter
two ts-219.
We have two problems:
1) fan_error() produces a beep. Previous discussion suggests that turning
the fan off will make the fan_error() calls go away on devices without a
fan (at least on the TS-109).
Axel, can you restore the original config and 1) see if you get the beeps
and 2) whether running
qcontrol fanspeed stop
makes them stop. (change setfan in the config to do nothing, otherwise
the fan will be turned on again)
2) We have temp_low()/temp_high() on ts-209 and temp() on ts-219 which
regulates the temperature by calling setfan().
So imho the easiest fix would be a) for the init script to run `qcontrol
fanspeed stop` if HAS_FAN=no and for setfan() to be modified to do nothing
if HAS_FAN=no.
It would be up to users to add HAS_FAN=no to /dev/default/qcontrol
Ian, does that sound reasonable?
Do you know if /etc/default is Debian-specific or generic? I'm just
wondering if the qcontrol configs should read from /etc/default/qcontrol
(Google suggests Red Hat and SUSE have it too, so I guess that should
be ok.)
end
function setfan( temp, speed )
end
I believe this should work but is completely untested. (Alex,
Christian, maybe you can test after restoring the original config.)
> > Ian, do you think it's worth asking the release team if they'd allow
> > an update for this in stable?
>
> I think it is premature to consider that question without a specific
> fix in unstable to be backported in order to make the argument/decision
> based on it.
Yes, absolutely. Of course we have to fix it in unstable first.
> > an update for this in stable?
>
> I think it is premature to consider that question without a specific
> fix in unstable to be backported in order to make the argument/decision
> based on it.
> > Getting the right device from /etc/mtdblock5 is easy, but I've no
> > idea how to change the config based on that.
>
> I think you mean /dev/mtdblock5? While mounting that to extract the
Anyway, after reading the bug log again and looking at the files,
here's what I think:
Devices affected:
* TS-109
* TS-109 II
* TS-119
* HS-210
The first two are ts-209 devices from the POV of qcontrol and the latter
two ts-219.
We have two problems:
1) fan_error() produces a beep. Previous discussion suggests that turning
the fan off will make the fan_error() calls go away on devices without a
fan (at least on the TS-109).
Axel, can you restore the original config and 1) see if you get the beeps
and 2) whether running
qcontrol fanspeed stop
makes them stop. (change setfan in the config to do nothing, otherwise
the fan will be turned on again)
2) We have temp_low()/temp_high() on ts-209 and temp() on ts-219 which
regulates the temperature by calling setfan().
So imho the easiest fix would be a) for the init script to run `qcontrol
fanspeed stop` if HAS_FAN=no and for setfan() to be modified to do nothing
if HAS_FAN=no.
It would be up to users to add HAS_FAN=no to /dev/default/qcontrol
Ian, does that sound reasonable?
Do you know if /etc/default is Debian-specific or generic? I'm just
wondering if the qcontrol configs should read from /etc/default/qcontrol
(Google suggests Red Hat and SUSE have it too, so I guess that should
be ok.)
As a workaround, until this is fixed, users can create a file
/etc/qcontrol.d/90_no_fan with:
function fan_error( )
/etc/qcontrol.d/90_no_fan with:
end
function setfan( temp, speed )
end
I believe this should work but is completely untested. (Alex,
Christian, maybe you can test after restoring the original config.)
Axel Sommerfeldt
Apr 16, 2018, 3:30:03 PM4/16/18
to
On Mon, Apr 16, 2018, at 20:12, Martin Michlmayr wrote:
> Axel, can you restore the original config and 1) see if you get the beeps
> and 2) whether running
>
> qcontrol fanspeed stop
>
> makes them stop. (change setfan in the config to do nothing, otherwise
> the fan will be turned on again)
1) Done
> Axel, can you restore the original config and 1) see if you get the beeps
> and 2) whether running
>
> qcontrol fanspeed stop
>
> makes them stop. (change setfan in the config to do nothing, otherwise
> the fan will be turned on again)
2) "qcontrol fanspeed stop" makes the beeping stop
> Do you know if /etc/default is Debian-specific or generic?
> As a workaround, until this is fixed, users can create a file
> /etc/qcontrol.d/90_no_fan with:
>
> function fan_error( )
> end
>
> function setfan( temp, speed )
> end
>
> I believe this should work but is completely untested. (Alex,
> Christian, maybe you can test after restoring the original config.)
Log:
Apr 16 21:08:59 qnap-backup qcontrol[330]: confdir: loading from /etc/qcontrol.d...
Apr 16 21:08:59 qnap-backup qcontrol[330]: confdir: including /etc/qcontrol.d/90-no-fan.conf
Maybe it's a good idea to overwrite the temp() function in /etc/qcontrol.d/90-no-fan.conf, too? It could create a log entry if the temperature gets hot and make a beep (and a red blinking status led) if it gets too hot!?
Martin Michlmayr
Apr 19, 2018, 7:00:03 AM4/19/18
to
* Axel Sommerfeldt <axel.som...@f-m.fm> [2018-04-16 21:25]:
> Creating /etc/qcontrol.d/90-no-fan.conf with the content above makes the beeping stop, too.
Great!
Based on Ian's comments, I added a has_fan to the configuration file.
I believe the attached patch should do the trick.
Axel, can you test this (after restoring the original config).
> Maybe it's a good idea to overwrite the temp() function in
> /etc/qcontrol.d/90-no-fan.conf, too? It could create a log entry if
logtemp() is still being called, so you will get temperate logs.
> the temperature gets hot and make a beep (and a red blinking status
> led) if it gets too hot!?
Maybe, although the fanless devices are designed to work without a fan
so this shouldn't happen. But what would you consider "too hot"?
Maybe thsi should be in a config variable.
> 1) Done
> 2) "qcontrol fanspeed stop" makes the beeping stop
Thanks for confirming this!
> 2) "qcontrol fanspeed stop" makes the beeping stop
> Creating /etc/qcontrol.d/90-no-fan.conf with the content above makes the beeping stop, too.
Based on Ian's comments, I added a has_fan to the configuration file.
I believe the attached patch should do the trick.
Axel, can you test this (after restoring the original config).
> Maybe it's a good idea to overwrite the temp() function in
> /etc/qcontrol.d/90-no-fan.conf, too? It could create a log entry if
> the temperature gets hot and make a beep (and a red blinking status
> led) if it gets too hot!?
so this shouldn't happen. But what would you consider "too hot"?
Maybe thsi should be in a config variable.
Axel Sommerfeldt
Apr 22, 2018, 6:10:03 AM4/22/18
to
On Thu, Apr 19, 2018, at 12:47, Martin Michlmayr wrote:
> * Axel Sommerfeldt <axel.som...@f-m.fm> [2018-04-16 21:25]:
> * Axel Sommerfeldt <axel.som...@f-m.fm> [2018-04-16 21:25]:
> Based on Ian's comments, I added a has_fan to the configuration file.
> I believe the attached patch should do the trick.
>
> Axel, can you test this (after restoring the original config).
Looks good to me. Right after patching:
> I believe the attached patch should do the trick.
>
> Axel, can you test this (after restoring the original config).
Apr 22 11:40:26 qnap systemd[1]: Started LSB: Start qcontrol daemon.
Apr 22 11:40:26 qnap qcontrol[338]: qcontrol 0.5.5 daemon starting.
Apr 22 11:40:26 qnap qcontrol[338]: Register evdev on /dev/input/by-path/platform-gpio_keys-event
Apr 22 11:40:26 qnap qcontrol[338]: confdir: loading from /etc/qcontrol.d...
Apr 22 11:40:26 qnap qcontrol[338]: System status: start
Apr 22 11:40:30 qnap qcontrol[338]: ts219: temperature 55
Apr 22 11:40:30 qnap qcontrol[338]: ts219: temperature 55 setting fan to "high"
Apr 22 11:40:37 qnap qcontrol[338]: ts219: fan error
Apr 22 11:41:27 qnap qcontrol[338]: ts219: fan error
Apr 22 11:42:17 qnap qcontrol[338]: ts219: fan error
And after setting "has_fan" to "false":
Apr 22 11:44:26 qnap systemd[1]: Starting LSB: Start qcontrol daemon...
Apr 22 11:44:26 qnap qcontrold[323]: Starting qcontrol daemon: qcontrol.
Apr 22 11:44:26 qnap systemd[1]: Started LSB: Start qcontrol daemon.
Apr 22 11:44:26 qnap qcontrol[333]: qcontrol 0.5.5 daemon starting.
Apr 22 11:44:26 qnap qcontrol[333]: Register evdev on /dev/input/by-path/platform-gpio_keys-event
Apr 22 11:44:26 qnap qcontrol[333]: confdir: loading from /etc/qcontrol.d...
Apr 22 11:44:26 qnap qcontrol[333]: System status: start
Apr 22 11:44:30 qnap qcontrol[333]: ts219: temperature 55
> > the temperature gets hot and make a beep (and a red blinking status
> > led) if it gets too hot!?
>
> Maybe, although the fanless devices are designed to work without a fan
> so this shouldn't happen. But what would you consider "too hot"?
Martin Michlmayr
Apr 23, 2018, 6:10:03 AM4/23/18
to
* Axel Sommerfeldt <axel.som...@f-m.fm> [2018-04-22 12:01]:
I hope Ian can apply this upstream and release a new Debian package.
It probably makes sense to update debian/NEWS (see proposed patch in
the attachment). debian/README.Debian is also quite out of date.
> > Maybe, although the fanless devices are designed to work without a
> > fan so this shouldn't happen. But what would you consider "too
> > hot"?
>
> I have no idea what max. temperature the qnap can handle. Maybe 70?
> Maybe it should not beep but at least change the status of the
> status led? Or change the status led at 70 and beep at 75? (But this
> is only clueless guessing of mine.)
I don't really know. Maybe Ian has some ideas.
> And after setting "has_fan" to "false":
Ok, thanks for testing!
I hope Ian can apply this upstream and release a new Debian package.
It probably makes sense to update debian/NEWS (see proposed patch in
the attachment). debian/README.Debian is also quite out of date.
> > Maybe, although the fanless devices are designed to work without a
> > fan so this shouldn't happen. But what would you consider "too
> > hot"?
>
> I have no idea what max. temperature the qnap can handle. Maybe 70?
> Maybe it should not beep but at least change the status of the
> status led? Or change the status led at 70 and beep at 75? (But this
> is only clueless guessing of mine.)
Martin Michlmayr
Apr 23, 2018, 6:10:03 AM4/23/18
to
Some QNAP devices don't have a fan. qcontrol will unsuccessfully try
to regulate the temperature and produce beeps when fan errors are
received.
These problems can be avoided with two steps:
1) Turn off the fan (even though there isn't one) so fan_error()
doesn't get called.
2) Make setfan() do nothing so the fan doesn't get turned on again.
Thanks to Axel Sommerfeldt for testing these changes.
This addresses Debian bug #712841
---
examples/ts209.lua | 12 ++++++++++++
examples/ts219.lua | 13 +++++++++++++
2 files changed, 25 insertions(+)
diff --git a/examples/ts209.lua b/examples/ts209.lua
index da301a5..51991c8 100644
--- a/examples/ts209.lua
+++ b/examples/ts209.lua
@@ -37,6 +37,13 @@ register("system-status")
-- Set to "false" to suppress the sounding of the buzzer
buzzer = true
+-- Set to "false" if your device doesn't have a fan (TS-109 and TS-109 II)
+has_fan = true
+
+-- Turn off fan if there is no fan to avoid fan_error() being called
+if not has_fan then
+ piccmd("fanspeed", "stop")
+end
function system_status( status )
logprint("System status: "..status)
@@ -88,6 +95,11 @@ end
last_fan_setting = nil
function setfan( speed )
+ -- Do nothing if there's no fan
+ if not has_fan then
+ return
+ end
+
if ( ( not last_fan_setting ) or
( last_fan_setting ~= speed ) ) then
logprint(string.format("ts209: setting fan to \"%s\"", speed))
diff --git a/examples/ts219.lua b/examples/ts219.lua
index ab28d93..97d9b8f 100644
--- a/examples/ts219.lua
+++ b/examples/ts219.lua
@@ -38,6 +38,14 @@ register("system-status")
-- Set to "false" to suppress the sounding of the buzzer
buzzer = true
+-- Set to "false" if your device doesn't have a fan (TS-119 and HS-210)
+has_fan = true
+
+-- Turn off fan if there is no fan to avoid fan_error() being called
+if not has_fan then
+ piccmd("fanspeed", "stop")
+end
+
function system_status( status )
logprint("System status: "..status)
if status == "start" then
@@ -128,6 +136,11 @@ end
last_fan_setting = nil
function setfan( temp, speed )
+ -- Do nothing if there's no fan
+ if not has_fan then
+ return
+ end
+
if ( ( not last_fan_setting ) or
( last_fan_setting ~= speed ) ) then
logprint(string.format("ts219: temperature %d setting fan to \"%s\"", temp, speed))
--
2.11.0
to regulate the temperature and produce beeps when fan errors are
received.
These problems can be avoided with two steps:
1) Turn off the fan (even though there isn't one) so fan_error()
doesn't get called.
2) Make setfan() do nothing so the fan doesn't get turned on again.
Thanks to Axel Sommerfeldt for testing these changes.
This addresses Debian bug #712841
---
examples/ts209.lua | 12 ++++++++++++
examples/ts219.lua | 13 +++++++++++++
2 files changed, 25 insertions(+)
diff --git a/examples/ts209.lua b/examples/ts209.lua
index da301a5..51991c8 100644
--- a/examples/ts209.lua
+++ b/examples/ts209.lua
@@ -37,6 +37,13 @@ register("system-status")
-- Set to "false" to suppress the sounding of the buzzer
buzzer = true
+-- Set to "false" if your device doesn't have a fan (TS-109 and TS-109 II)
+has_fan = true
+
+-- Turn off fan if there is no fan to avoid fan_error() being called
+if not has_fan then
+ piccmd("fanspeed", "stop")
+end
function system_status( status )
logprint("System status: "..status)
@@ -88,6 +95,11 @@ end
last_fan_setting = nil
function setfan( speed )
+ -- Do nothing if there's no fan
+ if not has_fan then
+ return
+ end
+
if ( ( not last_fan_setting ) or
( last_fan_setting ~= speed ) ) then
logprint(string.format("ts209: setting fan to \"%s\"", speed))
diff --git a/examples/ts219.lua b/examples/ts219.lua
index ab28d93..97d9b8f 100644
--- a/examples/ts219.lua
+++ b/examples/ts219.lua
@@ -38,6 +38,14 @@ register("system-status")
-- Set to "false" to suppress the sounding of the buzzer
buzzer = true
+-- Set to "false" if your device doesn't have a fan (TS-119 and HS-210)
+has_fan = true
+
+-- Turn off fan if there is no fan to avoid fan_error() being called
+if not has_fan then
+ piccmd("fanspeed", "stop")
+end
+
function system_status( status )
logprint("System status: "..status)
if status == "start" then
@@ -128,6 +136,11 @@ end
last_fan_setting = nil
function setfan( temp, speed )
+ if not has_fan then
+ return
+ end
+
if ( ( not last_fan_setting ) or
( last_fan_setting ~= speed ) ) then
logprint(string.format("ts219: temperature %d setting fan to \"%s\"", temp, speed))
--
2.11.0
0 new messages