Nut upsdev - Mar 2015 - (Tuncmatic returns FSD all the time)

2015-03-17 0:24 GMT+01:00 Charles Lepple <clepple at
gmail.com>:
> On Mar 16, 2015, at 12:26 PM, cinowell <cinowell at gmail.com> wrote:
>
>> I've done all the steps. However FSD indication did NOT disappear.
So it seems UPS always send the FSD flag.
One thing more.

Can you launch the driver with a debug level of 3 and then report back
the log (gzipped) of the same procedure suggested by Charles (extended
a bit as follows)?

i.e.:

1) Power down, and disconnect the UPS USB cable from the computer.
2) Power up the computer attached to a different UPS or wall outlet
3) Turn the UPS on
4) Kill the upsmon process (this will prevent automatic shutdown)
5) Plug the UPS USB cable back in
5.1) Kill the blazer_usb process (if any) and issue (as root):
blazer_usb -a ups -DDD >> /path/to/my/precious/log 2>&1
(keep it running till the test is over - this is the log we are after)
6) Turn the UPS off
6.1) Turn the UPS on

[Me too, I'm inclined to see it as a bogus value (in the old megatec
driver there was the 'ignoreoff' option that dealed with it - although
the value was mapped as an on/off status rather than the actual
'shutdown active'), but the 7th bit of the status byte should change
only while the UPS is shutting down and then be back at its original
value: if you turned off the UPS with a button (and this is likely as
the UPS has a VID:PID of 0001:0000 and so, since no overridding
'subdriver' parameter is passed to the driver, it should use the
'krauler' subdriver, which doesn't implement the shutdown commands)
and checked the upsc output only after the UPS had already turned off
the load, then you wouldn't have noticed the change.]

Hello,

I am attaching debug logs. Hopefully it helps to fix this issue.

Thank you.

2015-03-17 22:43 GMT+00:00 hyouko at gmail.com <hyouko at gmail.com>:
> 2015-03-17 0:24 GMT+01:00 Charles Lepple <clepple at gmail.com>:
> > On Mar 16, 2015, at 12:26 PM, cinowell <cinowell at gmail.com>
wrote:
> >
> >> I've done all the steps. However FSD indication did NOT
disappear. So
> it seems UPS always send the FSD flag.
>
> One thing more.
>
> Can you launch the driver with a debug level of 3 and then report back
> the log (gzipped) of the same procedure suggested by Charles (extended
> a bit as follows)?
>
> i.e.:
>
> 1) Power down, and disconnect the UPS USB cable from the computer.
> 2) Power up the computer attached to a different UPS or wall outlet
> 3) Turn the UPS on
> 4) Kill the upsmon process (this will prevent automatic shutdown)
> 5) Plug the UPS USB cable back in
> 5.1) Kill the blazer_usb process (if any) and issue (as root):
> blazer_usb -a ups -DDD >> /path/to/my/precious/log 2>&1
> (keep it running till the test is over - this is the log we are after)
> 6) Turn the UPS off
> 6.1) Turn the UPS on
>
> [Me too, I'm inclined to see it as a bogus value (in the old megatec
> driver there was the 'ignoreoff' option that dealed with it -
although
> the value was mapped as an on/off status rather than the actual
> 'shutdown active'), but the 7th bit of the status byte should
change
> only while the UPS is shutting down and then be back at its original
> value: if you turned off the UPS with a button (and this is likely as
> the UPS has a VID:PID of 0001:0000 and so, since no overridding
> 'subdriver' parameter is passed to the driver, it should use the
> 'krauler' subdriver, which doesn't implement the shutdown
commands)
> and checked the upsc output only after the UPS had already turned off
> the load, then you wouldn't have noticed the change.]
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20150320/f6e5b108/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tuncmatik_bug.tar.gz
Type: application/x-gzip
Size: 1829 bytes
Desc: not available
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20150320/f6e5b108/attachment-0001.bin>

2015-03-20 19:16 GMT+01:00 cinowell <cinowell at
gmail.com>:
> Hello,
>
> I am attaching debug logs. Hopefully it helps to fix this issue.
>
> Thank you.
Perfect, thanks!
Workaround committed and available in current git HEAD (with nutdrv_qx
driver, set 'ignoresab' flag): this should solve your problem.

If you can't update, for the time being the easiest thing is probably
what Charles suggested:

2015-03-17 0:24 GMT+01:00 Charles Lepple <clepple at
gmail.com>:
> I know this sounds kind of ridiculous, but you could use a hex editor to
change 'FSD' to 'OFF' in blazer_usb (it only seems to occur
once), which would restore the behavior of megatec_usb.

[please keep the list cc'd - thanks]

On Mar 22, 2015, at 6:20 AM, cinowell <cinowell at gmail.com> wrote:
> I may use the 'mc' in terminal. But I am not sure how to find the
exact bit of FSD? I am totally newbie in this topic.
> Could you please elaborate the hex editing of FSD bit? 
I haven't used 'mc' before, but assuming it has a hex editor, you
would just search for the string 'FSD' (46 53 44) and replace it with
'OFF' (4F 46 46), write the file, and start the driver. (You might need
to stop the driver first.)

-- 
Charles Lepple
clepple at gmail

"ups.status: ALARM OL OFF"

Great! This was so easy than I expected.
UPS back to life again.


Thank you.



2015-03-22 14:22 GMT+02:00 Charles Lepple <clepple at gmail.com>:
> [please keep the list cc'd - thanks]
>
> On Mar 22, 2015, at 6:20 AM, cinowell <cinowell at gmail.com> wrote:
>
> > I may use the 'mc' in terminal. But I am not sure how to find
the exact
> bit of FSD? I am totally newbie in this topic.
> > Could you please elaborate the hex editing of FSD bit?
>
> I haven't used 'mc' before, but assuming it has a hex editor,
you would
> just search for the string 'FSD' (46 53 44) and replace it with
'OFF' (4F
> 46 46), write the file, and start the driver. (You might need to stop the
> driver first.)
>
> --
> Charles Lepple
> clepple at gmail
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20150322/60394a91/attachment-0001.html>