Arnaud Quette
2017-Jun-14 12:32 UTC
[Nut-upsuser] Unable to use nut-2.7.4 with Eaton 5E1500I USB
2017-06-13 17:49 GMT+02:00 Manuel Wolfshant <wolfy at nobugconsulting.ro>:> On 06/13/2017 05:48 PM, Arnaud Quette wrote: > > Hi Manuel > > > Hi Arno > >Hi Manuel> > > 2017-06-07 14:40 GMT+02:00 Charles Lepple <clepple at gmail.com>: > >> On Jun 7, 2017, at 5:47 AM, Manuel Wolfshant <wolfy at nobugconsulting.ro> >> wrote: >> > >> > If that matters, the OS is a fully updated CentOS 6.9 and this >> (latest stable ) version of nut was packaged by me. The problem appears on >> any of the USB ports ( well, I tried the 2 in front and one in the back of >> the server ). >> > >> > lsusb -v reports: >> ... >> > wDescriptorLength 549 >> > Warning: incomplete report descriptor >> > Report Descriptor: (length is 9) >> > Item(Main ): (null), data=none >> >> Because both NUT and lsusb are having trouble retrieving the HID Report >> Descriptor, I think the problem is at a lower level: probably between the >> UPS, the kernel, and the USB HCI. The archives have a number of unresolved >> emails about the 5E and "broken pipe" errors. >> >> Probably worth checking with Eaton, too. >> > > Charles is right in both the fact that the issue is (or at least seems to > be) upstream to NUT, and also that it's worth checking with "Eaton" > > > I've approached "them" ( apparently my request for supported landed at > after-sales support/Romania ) as soon as Charles replied. Unfortunately the > "dialogue" rather stalls, they seem to have a policy to not send more than > one email every 3 days. Leaving aside that after telling them that I am > using an *USB *unit (and providing USB-related logs ) they wanted to know > if I was using *SNMP*. >no comments ;)> > Could you please tell me your kernel > > [root at belgrade ~]# uname -r > 2.6.32-696.3.1.el6.x86_64 >that may be part of the issue... long time I've not tried the 2.x series, not sure how it goes nowadays. btw, any interesting "usb" messages from your syslog? also, would you be able to test with a 3.x or 4.x, at least to see if that improves / solves the issue?> > and libusb (0.1) version? > > [root at belgrade ~]# rpm -qa libusb > libusb-0.1.12-23.el6.x86_64 > > > > Would you also be able to test some github code? > We have the libusb-1.0 branch that provides both libusb 1.0 support > (interesting to test to see if the problem still happens) along with few > other improvements (though these should not help for your issue): > https://github.com/networkupstools/nut/tree/libusb-1.0 > > I can and I will test ( tomorrow, probably ). > > > Don't hesitate if you need more guidance for trying this branch. > > Do you happen to know how can I find the version of firmware run by the > UPS, in _my_ conditions ( remote + the previously mentioned errors) ? >don't bother too much, in the end, such request only get an answer once it has reached me ;)> The guys who contacted me from Eaton did not reply yet to my email sent > yesterday. >that requires the driver to be running, then it's published as ups.firmware. as per my upsc output above (in my case): ups.firmware: 02.06.0019> > FYI, I've just made a test with the same unit, on a Debian jessie (kernel > 3.16.43-2, libusb 0.1.12-25) both with 2.7.4 and the latest git master, and > it works fine: > > battery.charge: 62 > battery.runtime: 2725 > battery.type: PbAc > device.mfr: EATON > device.model: 5E 1500i > device.type: ups > driver.name: usbhid-ups > [...] > > I was expecting it to work fine, given https://risc-a-day.blogspot. > ro/2014/09/getting-my-ups-to-work-with-linux.html ( before the purchase I > assumed the units to be similar, modulo the maximum power ) >you shouldn't be that far...> > cheers, > Arno > > thanks a lot. I will come back with more data once I test the github code > ( yes, I know, everybody hates this kind of threats :) ) >looking forward to get news so ;) cheers, Arno -- Eaton Data Center Automation Solutions - Opensource Leader - http://42ity.org NUT (Network UPS Tools) 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/20170614/c1cd206f/attachment.html>
Manuel Wolfshant
2017-Jun-14 13:16 UTC
[Nut-upsuser] Unable to use nut-2.7.4 with Eaton 5E1500I USB
Hello On 06/14/2017 03:32 PM, Arnaud Quette wrote:> > > On Jun 7, 2017, at 5:47 AM, Manuel Wolfshant <wolfy at nobugconsulting.ro > <mailto:wolfy at nobugconsulting.ro>> wrote: > >> > >> > If that matters, the OS is a fully updated CentOS 6.9 >> and this (latest stable ) version of nut was packaged by me. >> The problem appears on any of the USB ports ( well, I tried >> the 2 in front and one in the back of the server ). >> > >> > lsusb -v reports: >> ... >> > wDescriptorLength 549 >> > Warning: incomplete report descriptor >> > Report Descriptor: (length is 9) >> > Item(Main ): (null), data=none >> >> Because both NUT and lsusb are having trouble retrieving the >> HID Report Descriptor, I think the problem is at a lower >> level: probably between the UPS, the kernel, and the USB HCI. >> The archives have a number of unresolved emails about the 5E >> and "broken pipe" errors. >> >> Probably worth checking with Eaton, too. >> >> >> Charles is right in both the fact that the issue is (or at least >> seems to be) upstream to NUT, and also that it's worth checking >> with "Eaton" > > I've approached "them" ( apparently my request for supported > landed at after-sales support/Romania ) as soon as Charles > replied. Unfortunately the "dialogue" rather stalls, they seem to > have a policy to not send more than one email every 3 days. > Leaving aside that after telling them that I am using an *USB > *unit (and providing USB-related logs ) they wanted to know if I > was using *SNMP*. > > > no comments ;).... still no reply from them ...>> >> Could you please tell me your kernel > [root at belgrade ~]# uname -r > 2.6.32-696.3.1.el6.x86_64 > > > that may be part of the issue... long time I've not tried the 2.x > series, not sure how it goes nowadays. > btw, any interesting "usb" messages from your syslog? > also, would you be able to test with a 3.x or 4.x, at least to see if > that improves / solves the issue? >It's a bit tricky. I tried to use the kernel-lt package from the elrepo repository ( incidentally I am also part of the elrepo team but I am in charge with other packages, not the kernels ) and failed miserably. For reasons unknown to me ( and not logged ) the system failed to boot and a colleague from that office had to manually make it use the stock CentOS kernel ( typing what I was dictating to him over the phone .. ) Due to a complete lack of logs, I have absolutely no idea what happened and since the machine is critical for the activity there, I am a bit reluctant to try again>> Would you also be able to test some github code? >> We have the libusb-1.0 branch that provides both libusb 1.0 >> support (interesting to test to see if the problem still happens) >> along with few other improvements (though these should not help >> for your issue): >> https://github.com/networkupstools/nut/tree/libusb-1.0 >> <https://github.com/networkupstools/nut/tree/libusb-1.0> >> > I can and I will test ( tomorrow, probably ). >I just packaged and tested it ( see below some comments, not important for my issue here ) Unfortunately there is no change in the output: [root at belgrade ~]#u root -x explore -x vendorid="0463" -a eaton Network UPS Tools - Generic HID driver 0.42 (2.7.4.1) USB communication driver (libusb 0.1) 0.33 0.000000 [D1] debug level is '4' 0.012088 [D1] upsdrv_initups... 8.248213 [D2] Checking device (0463/FFFF) (002/004) 9.249069 [D2] - VendorID: 0463 9.249094 [D2] - ProductID: ffff 9.249129 [D2] - Manufacturer: unknown 9.249135 [D2] - Product: unknown 9.249140 [D2] - Serial Number: unknown 9.249145 [D2] - Bus: 002 9.249151 [D2] - Device release number: 0001 9.249156 [D2] Trying to match device 9.249199 [D2] Device matches 9.249209 [D2] failed to claim USB device: could not claim interface 0: Device or resource busy 9.249373 [D2] detached kernel driver from USB device... 9.249394 [D3] nut_usb_set_altinterface: skipped usb_set_altinterface(udev, 0) 9.249991 [D2] Unable to get HID descriptor (error sending control message: Broken pipe) 9.250002 [D3] HID descriptor length (method 1) -1 9.250009 [D4] i=0, extra[i]=09, extra[i+1]=21 9.250017 [D3] HID descriptor, method 2: (9 bytes) => 09 21 10 01 21 01 22 25 02 9.250023 [D3] HID descriptor length (method 2) 549 9.250028 [D2] HID descriptor length 549 9.250515 [D2] Unable to get Report descriptor: Broken pipe Comments on the new tree: a) there seem to be some missing files in the tree: - some bits for augeas, devs and udev: configure.ac:1526: required file `scripts/augeas/nutupsconf.aug.in' not found configure.ac:1526: required file `scripts/devd/nut-usb.conf.in' not found configure.ac:1526: required file `scripts/udev/nut-usbups.rules.in' not found - all man pages b) on top of that, I did not manage to include the manpages in the final rpms because the new configure script insists on using tools not available on CentOS 6 ( a newer asciidoc, for a start ) and I was too lazy to just include the pages as they are. Why did you change that towards 2.7.4, oooh why ? It was working sooooooooooooo fine.... FWIW, I modified the spec to create a separate subpackage for the augeas lenses/modules -- those did not seem to exists in 2.7.4. If anyone wishes to toy with the spec or rpm packages I will be happy to share them. Regards, manuel -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20170614/32a1447e/attachment.html>
Arnaud Quette
2017-Jun-15 13:32 UTC
[Nut-upsuser] Unable to use nut-2.7.4 with Eaton 5E1500I USB
Hi Manuel, 2017-06-14 15:16 GMT+02:00 Manuel Wolfshant <wolfy at nobugconsulting.ro>:> Hello > > > > On 06/14/2017 03:32 PM, Arnaud Quette wrote: > > > > On Jun 7, 2017, at 5:47 AM, Manuel Wolfshant <wolfy at nobugconsulting.ro> > wrote: > >> > >>> > If that matters, the OS is a fully updated CentOS 6.9 and this >>> (latest stable ) version of nut was packaged by me. The problem appears on >>> any of the USB ports ( well, I tried the 2 in front and one in the back of >>> the server ). >>> > >>> > lsusb -v reports: >>> ... >>> > wDescriptorLength 549 >>> > Warning: incomplete report descriptor >>> > Report Descriptor: (length is 9) >>> > Item(Main ): (null), data=none >>> >>> Because both NUT and lsusb are having trouble retrieving the HID Report >>> Descriptor, I think the problem is at a lower level: probably between the >>> UPS, the kernel, and the USB HCI. The archives have a number of unresolved >>> emails about the 5E and "broken pipe" errors. >>> >>> Probably worth checking with Eaton, too. >>> >> >> Charles is right in both the fact that the issue is (or at least seems to >> be) upstream to NUT, and also that it's worth checking with "Eaton" >> >> >> I've approached "them" ( apparently my request for supported landed >> at after-sales support/Romania ) as soon as Charles replied. Unfortunately >> the "dialogue" rather stalls, they seem to have a policy to not send more >> than one email every 3 days. Leaving aside that after telling them that I >> am using an *USB *unit (and providing USB-related logs ) they wanted to >> know if I was using *SNMP*. >> > > no comments ;) > > .... still no reply from them ... >is the guy you contacted Paul Henri?> > >> Could you please tell me your kernel >> >> [root at belgrade ~]# uname -r >> 2.6.32-696.3.1.el6.x86_64 >> > > that may be part of the issue... long time I've not tried the 2.x series, > not sure how it goes nowadays. > btw, any interesting "usb" messages from your syslog? > also, would you be able to test with a 3.x or 4.x, at least to see if that > improves / solves the issue? > > It's a bit tricky. I tried to use the kernel-lt package from the elrepo > repository ( incidentally I am also part of the elrepo team but I am in > charge with other packages, not the kernels ) and failed miserably. For > reasons unknown to me ( and not logged ) the system failed to boot and a > colleague from that office had to manually make it use the stock CentOS > kernel ( typing what I was dictating to him over the phone .. ) > Due to a complete lack of logs, I have absolutely no idea what happened > and since the machine is critical for the activity there, I am a bit > reluctant to try again > > > > Would you also be able to test some github code? >> We have the libusb-1.0 branch that provides both libusb 1.0 support >> (interesting to test to see if the problem still happens) along with few >> other improvements (though these should not help for your issue): >> https://github.com/networkupstools/nut/tree/libusb-1.0 >> >> I can and I will test ( tomorrow, probably ). >> > > I just packaged and tested it ( see below some comments, not important for > my issue here ) > Unfortunately there is no change in the output: > > [root at belgrade ~]#u root -x explore -x vendorid="0463" -a eaton > Network UPS Tools - Generic HID driver 0.42 (2.7.4.1) > USB communication driver (libusb 0.1) 0.33 > 0.000000 [D1] debug level is '4' > 0.012088 [D1] upsdrv_initups... > 8.248213 [D2] Checking device (0463/FFFF) (002/004) > 9.249069 [D2] - VendorID: 0463 > 9.249094 [D2] - ProductID: ffff > 9.249129 [D2] - Manufacturer: unknown > 9.249135 [D2] - Product: unknown > 9.249140 [D2] - Serial Number: unknown > 9.249145 [D2] - Bus: 002 > 9.249151 [D2] - Device release number: 0001 > 9.249156 [D2] Trying to match device > 9.249199 [D2] Device matches > 9.249209 [D2] failed to claim USB device: could not claim interface > 0: Device or resource busy > 9.249373 [D2] detached kernel driver from USB > device... > 9.249394 [D3] nut_usb_set_altinterface: skipped > usb_set_altinterface(udev, 0) > 9.249991 [D2] Unable to get HID descriptor (error sending control > message: Broken pipe) > 9.250002 [D3] HID descriptor length (method 1) > -1 > 9.250009 [D4] i=0, extra[i]=09, extra[i+1]=21 > > 9.250017 [D3] HID descriptor, method 2: (9 bytes) => 09 21 10 01 21 > 01 22 25 02 > 9.250023 [D3] HID descriptor length (method 2) > 549 > 9.250028 [D2] HID descriptor length 549 > > 9.250515 [D2] Unable to get Report descriptor: Broken pipe > >argh, no improvement, but still with libusb 0.1. do you have libusb 1.0 -devel package installed? With that libusb1.0 nut branch, if both 1.0 and 0.1 are available, 1.0 will take precedence.> > Comments on the new tree: > a) there seem to be some missing files in the tree: > - some bits for augeas, devs and udev: > configure.ac:1526: required file `scripts/augeas/nutupsconf.aug.in' not > found > configure.ac:1526: required file `scripts/devd/nut-usb.conf.in' not found > configure.ac:1526: required file `scripts/udev/nut-usbups.rules.in' not > found >when using git, you must call autogen.sh prior to calling configure...> - all man pages > b) on top of that, I did not manage to include the manpages in the final > rpms because the new configure script insists on using tools not available > on CentOS 6 ( a newer asciidoc, for a start ) and I was too lazy to just > include the pages as they are. Why did you change that towards 2.7.4, oooh > why ? It was working sooooooooooooo fine.... >my mems fails to recall that specific point, but it was on purpose, not to bother users... FWIW, I modified the spec to create a separate subpackage for the> augeas lenses/modules -- those did not seem to exists in 2.7.4. If anyone > wishes to toy with the spec or rpm packages I will be happy to share them. >cheers Arno -- Eaton Data Center Automation Solutions - Opensource Leader - http://42ity.org NUT (Network UPS Tools) 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/20170615/6c3ac529/attachment-0001.html>