[Nut-upsdev] Re: [nut-commits] svn commit r801 - in
branches/megatec-usb: . drivers
Alexander I. Gordeev
lasaine at lvk.cs.msu.su
Fri Feb 9 13:44:56 CET 2007
On Thu, 08 Feb 2007 19:42:26 +0300, Peter Selinger <selinger at mathstat.dal.ca> wrote:
> Hi Alexander,
>
> thanks for your good work on the megatec_usb driver. I have made a few
> more (cosmetic) changes.
>
> Is the driver now working stably for your device? In particular, do
> the instant commands (and particularly "upsdrvctl -k") work properly?
I've just implemented most instant commands.
However, some of them are not implemented because I'm not sure about
them. I think, some more investigation and testing is required.
Please, Jon, test these descriptors:
0x6 T<n> (don't know how to pass the parameter)
0x68 and 0x69 both cause shutdown after an undefined interval
A know nothing also about "C" command. Windows driver doesn't
implement it.
> In this case, we could hopefully mark the device as "supported" and
> merge the driver to the main branch.
>
Well, there are still some things that we need to do:
- fix matching code, add regex matcher (at teh moment only "auto"
works)
- make "I" request to support Jon's device as well as mine
- test the driver more to adjust the number of retries to work for
every device supported (well, I mean Jon's one :) )
About the latter: I realized yesterday that I've only tested "Q1"
request before. But "I" and "F" requests need to be tested too,
because they are necessary for the driver proper startup.
My most recent tests show, that percents of fails for these
requests aren't very promising:
F 81% (!!!)
I 15%
So the "UPS No Ack" problem is much more uncertain.
I've corrected the number of retries for these requests, they are:
F 31
I 15
These values are quite big, but since thess requests are performed
only once, at driver startup, it is not very harmful.
Well, I believe, the current code works well for me, but surely more
testing is needed. If you think that the current state is enough,
well, let's move it to trunc!
> There is still the question of whether to keep separate code for
> Ablerex and Krauler. From what I understand, each of these subdrivers
> works for each of the devices. But the Krauler driver is now more
> advanced (with the retry feature), so we could remove the Ablerex
> subdriver (provided Jon tests the Krauler one to make sure it still
> works for the Ablerex device).
>
Well, I think, there is no need to keep the code separate if Jon
confirms his UPS is supported.
> If I understand correctly, the only change needed would be to change
>
> {0xffff, 0x0000, get_data_ablerex, set_data_ablerex},
>
> to
>
> {0xffff, 0x0000, get_data_krauler, set_data_krauler},
>
> is that correct? -- Peter
>
That's right.
--
Alexander
More information about the Nut-upsdev
mailing list