[Nut-upsuser] New intermediate Windows binaries release - 2.6.5-2
aquette.dev at gmail.com
Thu Sep 20 08:13:48 UTC 2012
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
> >> 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.
Linux / Unix / Opensource Engineering Expert - Eaton -
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...
More information about the Nut-upsuser