[Nut-upsuser] New intermediate Windows binaries release - 2.6.5-2

[Arnaud Quette]

2012/9/18 Denis Serov <dns-srv at yandex.ru>

> Hello Frederic!
>
> >> 2. I've found a strange warning in Event Log:
> >> "usbhid-ups - libusb_get_interrupt: libusb0-dll:err [submit_async]
> submitting request failed, win error: The device does not recognize the
> command."
> >> Here is more details from UBSHID-USB output:
> >>    0.468000     libusb_get_report: libusb0-dll:err [control_msg]
> sending control message failed, win error: A device attached to the system
> is not functioning.
> >>    0.468000     Can't retrieve Report 48: Input/output error [A device
> attached to the system is not functioning. ]
>
> >> I think it is related to issue with APC Back ES UPS (there was no such
> error in private binary you sent to me).
>
> > This is very strange.
> > I see two report ID raising a libusb error in your logs: 48 and 62. They
> contains non standard, APC specific, HID data and strange value (as I see
> them on the old binary logs you have sent me).
> > I am not sure what are the differences between the released binary and
> the one that I sent to you. That's because the one I send to you was just
> an experimental thing to see if I was searching in the right direction, and
> I have lost its sources now. But from what I remember I don't see what
> could have changed its behavior the way it is now.
> > Anyway, from what you are reporting this is only "cosmetic" issue. Just
> one thing that still bothering me is that you have mentioned that it
> "repeats iteratively". Do you mean that the libusb error repeats regularly
> when the usbhid-ups driver is running ? If it is the case, can you send us
> usbhid-ups logs on a longer run (the attached one is stopped just after the
> init), please ?
>
> I didn't spot different error codes and I thought that this is reiteration
> of the same error. I've just tested private build of UPSHID-UPS and 2.6.5-2
> one. The behavior is equal: "report 48" is logged firstly, "report 62" -
> after that and no errors afterwards. So, there is no problem.
>
> Sorry for misleading...
>

thanks for the confirmation.
These errors should only occurs at communication init, thus only at initial
startup, and potentially upon device disconnection / reconnection.

cheers,
Arnaud
-- 
Linux / Unix / Opensource Engineering Expert - Eaton -
http://opensource.eaton.com
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.fr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20120920/9cf07c9a/attachment.html>