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.
_______________________________________________
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
