Manuel Wolfshant
2017-Jun-19 23:56 UTC
[Nut-upsuser] Unable to use nut-2.7.4 with Eaton 5E1500I USB
On 06/20/2017 02:27 AM, Charles Lepple wrote:> On Jun 19, 2017, at 10:45 AM, Manuel Wolfshant wrote: >> #lsusb -vvv -d 0463:ffff >> >> Bus 002 Device 012: ID 0463:ffff MGE UPS Systems UPS > ... >> HID Device Descriptor: >> bLength 9 >> bDescriptorType 33 >> bcdHID 1.10 >> bCountryCode 33 US >> bNumDescriptors 1 >> bDescriptorType 34 Report >> wDescriptorLength 549 >> Warning: incomplete report descriptor >> Report Descriptor: (length is 9) >> Item(Main ): (null), data=none >> Item(Main ): (null), data=none >> Item(Main ): (null), data=none >> > If I recall, this is equivalent to the usbhid-ups "method 2" approach to retrieving the descriptor.That's greek to me, I am completely unfamiliar to any of nut ( and its drivers ) internals :) But if I can configure usbhid-ups in a different manner which I did not spot from the docs, please point me to the correct docs.>>> or try to roll back the userspace tools to match what was current when the kernel was current. >>> >> I am afraid I did not understand this part... > If there are newer kernels out there, it is possible that some of the userspace tools (usbutils, libusb, etc.) are expecting a newer kernel. Is it possible to downgrade any of them, to test with package versions that were released at the same time as the 2.6.32 kernel?If you mean the applications/libraries running on that server, I can guarantee that every one (minus libusb 1.0.19 -- see below) of them is compatible with the running kernel. Everything but nut is stock CentOS 6 and fully updated. I am 100% positive that libsub0.1 which was used until yesterday ( and 1.0.9 which proved to be incompatible with nut ) are 100% compatible with the kernel. I cannot guarantee for libusbx 1.0.19 (which I used instead of 1.0.9) because I built it myself. However I am using the very same package on my personal workstation (which is also running CentOS 6 but has a whole lot of packages installed either from 3rd party repos or built by me ) since Fri 09 Jan 2015 (I needed it for heimdall <http://glassechidna.com.au/heimdall/> ) and I had zero issues so far. As of newer kernels: RH does not introduce incompatibilities between kernel and userspace. For the whole 10 years of life of a major version of a distribution, the major release of the kernel (and of most packages -- which is why both libsub and libusb1 aka 1.0.9 are oldish ) is frozen to the version used at launch date. It was 2.6.32 4.5 years ago when 6.0 was launched and it will claim to be 2.6.32 when it will be EOLed 4 years from now. They do backport stuff into the kernel ( actually the current kernel has huge backports from 3.10 ), but breaking the ABI is extremely rare and normally never affects the packages from the distro itself because they are tested for months prior to any minor release of the distro. The newer kernels that exist and are let's say reputable are provided by a 3rd party repository ( ElRepo.org ). Over there there is one person who maintains two sets of kernels, the most recent one that is available from kernel.org ( "kernel mainline" ) and one long term version ( kernel-lt ). The kernel-lt is the one that failed for me. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20170620/11aa99c6/attachment.html>
Charles Lepple
2017-Jun-20 01:08 UTC
[Nut-upsuser] Unable to use nut-2.7.4 with Eaton 5E1500I USB
On Jun 19, 2017, at 7:56 PM, Manuel Wolfshant wrote:> > On 06/20/2017 02:27 AM, Charles Lepple wrote: >> On Jun 19, 2017, at 10:45 AM, Manuel Wolfshant wrote: >> >>> #lsusb -vvv -d 0463:ffff >>> >>> Bus 002 Device 012: ID 0463:ffff MGE UPS Systems UPS >>> >> ... >> >>> HID Device Descriptor: >>> bLength 9 >>> bDescriptorType 33 >>> bcdHID 1.10 >>> bCountryCode 33 US >>> bNumDescriptors 1 >>> bDescriptorType 34 Report >>> wDescriptorLength 549 >>> Warning: incomplete report descriptor >>> Report Descriptor: (length is 9) >>> Item(Main ): (null), data=none >>> Item(Main ): (null), data=none >>> Item(Main ): (null), data=none >>> >>> >> If I recall, this is equivalent to the usbhid-ups "method 2" approach to retrieving the descriptor. > > That's greek to me, I am completely unfamiliar to any of nut ( and its drivers ) internals :) But if I can configure usbhid-ups in a different manner which I did not spot from the docs, please point me to the correct docs.No configuration needed - the driver tries both methods: 1.013273 HID descriptor length (method 1) -1 1.013277 i=0, extra[i]=09, extra[i+1]=21 1.013283 HID descriptor, method 2: (9 bytes) => 09 21 10 01 21 01 22 25 02 1.013287 HID descriptor length (method 2) 549 1.013290 HID descriptor length 549 1.013920 Unable to get Report descriptor: Broken pipe It does not get a length for method 1, so it moves on to method 2, which gets a length, but fails to get the rest of the descriptor. This is what is happening to lsusb, too (tries to fetch 549 bytes, gets only 9).> However I am using the very same package on my personal workstation (which is also running CentOS 6 but has a whole lot of packages installed either from 3rd party repos or built by me ) since Fri 09 Jan 2015 (I needed it for heimdall ) and I had zero issues so far.Can you be more specific about this? What hardware are you testing libusbx 1.0.19 with?
Manuel Wolfshant
2017-Jun-20 10:00 UTC
[Nut-upsuser] Unable to use nut-2.7.4 with Eaton 5E1500I USB
On 06/20/2017 04:08 AM, Charles Lepple wrote:> [...] > It does not get a length for method 1, so it moves on to method 2, which gets a length, but fails to get the rest of the descriptor. This is what is happening to lsusb, too (tries to fetch 549 bytes, gets only 9).and is there anything I can do to fix, short of hoping to receive an updated unbroken firmware for the UPS from a support team which ignores me ?> >> However I am using the very same package on my personal workstation (which is also running CentOS 6 but has a whole lot of packages installed either from 3rd party repos or built by me ) since Fri 09 Jan 2015 (I needed it for heimdall ) and I had zero issues so far. > Can you be more specific about this? What hardware are you testing libusbx 1.0.19 with?Gigabyte F2A88X-D3H with AMD A8-6600K works fine with heimdall which I used to connect to a Samsung S2+ and now to a Samsung A3 (2016) . Some similar board ( I do not recall exactly what model was it, could have been either identical or DH3 which is basically the same motherboard with some minor modifications) was used by my colleague from the IT support dept 2-3 years ago with my phone as well. The packages that I have installed are : [wolfy at wolfy ~]$ rpm -qa \*usb\* kernel --qf "%{name}-%{version}-%{release} %{arch} %{vendor} %{installtime:date} \n"|sort kernel-2.6.32-642.13.1.el6 x86_64 CentOS Wed 18 Jan 2017 03:13:27 AM EET kernel-2.6.32-642.15.1.el6 x86_64 CentOS Mon 27 Feb 2017 10:19:39 AM EET kernel-2.6.32-696.1.1.el6 x86_64 CentOS Fri 14 Apr 2017 01:39:36 AM EEST kernel-2.6.32-696.3.1.el6 x86_64 CentOS Thu 01 Jun 2017 12:52:38 AM EEST kernel-2.6.32-696.el6 x86_64 CentOS Thu 30 Mar 2017 05:16:05 PM EEST libusb-0.1.12-23.el6 i686 CentOS Wed 17 Sep 2014 01:07:21 AM EEST libusb-0.1.12-23.el6 x86_64 CentOS Tue 16 Sep 2014 04:59:09 PM EEST libusbx-1.0.19-2.el6 x86_64 (none) Fri 09 Jan 2015 03:56:43 PM EET pyusb-1.0.0-1.el6 noarch Fedora Project Tue 10 Jan 2017 12:18:30 PM EET usbredir-0.5.1-3.el6 x86_64 CentOS Fri 13 May 2016 12:02:18 PM EEST usbutils-003-6.el6 x86_64 CentOS Fri 13 May 2016 12:10:19 PM EEST [wolfy at wolfy ~]$ uname -r 2.6.32-696.3.1.el6.x86_64 The culprit is occurring on a Dell R310 which has: # rpm -qa \*usb\* kernel --qf "%{name}-%{version}-%{release} %{arch} %{vendor} %{installtime:date} \n"|sort kernel-2.6.32-696.1.1.el6 x86_64 CentOS Thu 13 Apr 2017 07:10:32 PM CEST kernel-2.6.32-696.3.1.el6 x86_64 CentOS Wed 31 May 2017 11:44:08 PM CEST kernel-2.6.32-696.el6 x86_64 CentOS Sun 02 Apr 2017 12:16:24 AM CEST libusb-0.1.12-23.el6 x86_64 CentOS Thu 17 Jan 2013 02:22:38 PM CET libusbx-1.0.19-2.el6 x86_64 (none) Mon 19 Jun 2017 10:21:55 AM CEST usbutils-003-6.el6 x86_64 CentOS Fri 13 May 2016 04:29:50 PM CEST # uname -r 2.6.32-696.3.1.el6.x86_64