[Nut-upsuser] Unable to use nut-2.7.4 with Eaton 5E1500I USB
arnaud.quette at gmail.com
Thu Jun 15 13:32:24 UTC 2017
2017-06-14 15:16 GMT+02:00 Manuel Wolfshant <wolfy at nobugconsulting.ro>:
> On 06/14/2017 03:32 PM, Arnaud Quette wrote:
> On Jun 7, 2017, at 5:47 AM, Manuel Wolfshant <wolfy at nobugconsulting.ro>
>>> > 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
> 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):
>> 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 (126.96.36.199)
> 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
> 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)
> 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)
> 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
> 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
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
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.
Eaton Data Center Automation Solutions - Opensource Leader -
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...
More information about the Nut-upsuser