<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 06/20/2017 02:27 AM, Charles Lepple
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:49348D43-F16B-4644-BF1E-5B8B506C245D@gmail.com">
<pre wrap="">On Jun 19, 2017, at 10:45 AM, Manuel Wolfshant wrote:
</pre>
<blockquote type="cite">
<pre wrap="">
#lsusb -vvv -d 0463:ffff
Bus 002 Device 012: ID 0463:ffff MGE UPS Systems UPS
</pre>
</blockquote>
<pre wrap="">...
</pre>
<blockquote type="cite">
<pre wrap=""> 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
</pre>
</blockquote>
<pre wrap="">If I recall, this is equivalent to the usbhid-ups "method 2" approach to retrieving the descriptor. </pre>
</blockquote>
<br>
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.<br>
<br>
<br>
<br>
<blockquote type="cite"
cite="mid:49348D43-F16B-4644-BF1E-5B8B506C245D@gmail.com">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap=""> or try to roll back the userspace tools to match what was current when the kernel was current.
</pre>
</blockquote>
<pre wrap="">I am afraid I did not understand this part...
</pre>
</blockquote>
<pre wrap="">
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?</pre>
</blockquote>
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 <a moz-do-not-send="true"
href="http://glassechidna.com.au/heimdall/">heimdall</a> ) and I
had zero issues so far.<br>
<br>
<p>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.</p>
<p><br>
</p>
</body>
</html>