Re: [Nut-upsuser] New intermediate Windows binaries release - 2.6.5-2
2012/9/18 Denis Serov dns-...@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 ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] bcmxcp_usb can not communicate with Eaton Powerware 5110
Massimo Gais simosagi9 at gmail.com writes: On Sun, Aug 12, 2012 at 5:11 AM, Greg Vickers daehenoc at iinet.net.au wrote: On 11/08/12 06:58, Arnaud Quette wrote: Hi Massimo and Greg, @Greg: if you yet returned your unit, you now have a solution ;) I have not yet gotten rid of it, so thank you very much! It's a case of download, extract, apply patch, and compile on my RPi, correct? thanks for the effort for the patch! welcome ;) Hello Greg, yes you can compile it directly on the RPI. See anyway that if you have the old deb package installed and you want to replace only the recompiled driver, you may have some mismatch with the pidpath/statepath directories (/var/state/ups vs /var/run/nut). I tried to do it in a clean way by making a debian package on the RPi, but it was requiring to install all the documentation tools, and I did not have enough SD disk space for that. Cheers, Massimo Greetings, Glad that I've found some info about the issue. I have same problem with the same UPS on RPi. Unfortunately link for the patch is no longer valid. Could you send it one more time or the compiled package for RPi would be more appreciable. Thank you With best regards, Eugene ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
