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.
On Wed, 2014-01-15 at 23:13 +0000, Dermot O'Dwyer wrote:
> The following appears to work OK in ts209.c:
> case 0x73:
> /* call_function("fan_error", ""); */
> {
> unsigned char code = 0x30;
> serial_write(&code, 1);
> }
> break;
>
> No errors in logs.
>
> The rest of qcontrol continues working OK (manual led/buzzer commands).
>
> Dermot
>
>
> On 9 January 2014 20:04, Ian Campbell <i...@hellion.org.uk> wrote:
> > 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
> > 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.
> >
>
signature.asc
Description: This is a digitally signed message part
