Nut upsdev - Jun 2015 - neon (was libusb_get_string: invalid argument (other usbhid-ups users, please test))

thanks - this has been fun.

There is one other thing I have been having trouble with - and i've tried it
on
two archlinuxarm installs and gotten the same thing. i am not even sure if its 
important for me. but if i try to configure and make with neon support - it cant
find the neon libraries. despite neon having been installed several 
different ways (i tried pacman, as well as compiling and installign neon from 
source)

i only came across this because when i originally tried installing nut, i tried 
doing it from the archlinux AUR. There, neon is enabled by default. and i 
couldnt get it to build. so i ended up going to the source.

Greg


On Fri, 12 Jun 2015, Charles Lepple wrote:
> Greg,
>
> I think I fixed it. Thanks for your patience.
>
> https://github.com/networkupstools/nut/pull/213
>
> Diffs:
https://github.com/networkupstools/nut/compare/usbhid_ups_input_vs_feature
>
> If anyone else can test usbhid-ups against their hardware before I merge
this to master, I would appreciate it. I tried my MGE UPS on a Linux box as
well, and it does not get interrupt events there, either.
>
> - Charles Lepple
>
> On Jun 11, 2015, at 9:13 AM, Charles Lepple <clepple at gmail.com>
wrote:
>
>> Greg,
>>
>> I'm still not 100% on what is going on, but after comparing the
call stack with a debug session here, I think I have at least identified why I
wasn't seeing similar behavior.
>>
>> There are two ways that the driver can get information from the UPS:
asking the UPS for a specific report (which returns one or more values), and
checking the interrupt pipe (which the UPS can fill with whatever has changed).
With the interrupt pipe results, the driver has to do an additional HID table
lookup to determine exactly what is being returned.
>>
>> It looks like the driver is processing the latter case when it throws
that error. I wasn't seeing that here, apparently because my MGE UPS on
FreeBSD is never getting anything via the interrupt pipe. (The driver falls back
to the polling method.)
>>
>> I might have some time later to reconnect that UPS to a Linux system
and see if the error crops up there. However, I have a suspicion that the bug is
triggered because the first entry in the Tripp Lite table has a conversion
function, and when the table lookup fails (your UPS does not have the HID item
corresponding to a manufacturer's part number), the lookup function
incorrectly returns that first table entry by default.
>>
>> - Charles
>>
>> On Jun 10, 2015, at 12:18 PM, Greg Hersch <hersch.greg at
gmail.com> wrote:
>>
>>>
>>> And here are the logs and GDB output from the
reconfigured/recompiled CFLAGS=-G program. You will notice i made a change to
the version definition of tripplite-hid.c just to make sure i am working with
the updated version.
>>>
>>> On Tue, 9 Jun 2015, Charles Lepple wrote:
>>>
>>>> On Jun 9, 2015, at 4:55 PM, Greg Hersch wrote:
>>>>
>>>>> (gdb) bt
>>>>> #0  libusb_get_string (udev=0x43110, StringIdx=0,
buf=0x40204 <buf>
>>>>> "", buflen=20) at libusb.c:496
>>>>> #1  0x00015330 in HIDGetIndexString (udev=<optimized
out>,
>>>>> Index=<optimized out>, buf=0x40204 <buf>
"", buflen=<optimized out>)
>>>>> at libhid.c:407
>>>>> #2  0x00012e18 in ups_infoval_set (item=0x3ee48
<tripplite_hid2nut>,
>>>>> value=<optimized out>) at usbhid-ups.c:1552
>>>>> #3  0x00013da8 in upsdrv_updateinfo () at usbhid-ups.c:835
>>>>> #4  0x00012410 in main (argc=<optimized out>,
argv=<optimized out>) at
>>>>> main.c:708
>>>>
>>>> You did everything right on the backtrace, but that is
puzzling.
>>>>
>>>> At #2, ups_infoval_set() apparently calls HIDGetIndexString(),
but I don't see where it does that in the code. There must be some pointers,
or something.
>>>>
>>>> The easiest thing might be to crank the debug output up a bit
more (5x -D, even) but since that will be a bit more output, please redirect it
to a file, and gzip the log before attaching it. Doesn't need to be long,
just enough to see one or two errors.
>>>>
>>>> Another idea is to recompile without optimizations, to see if
that helps the gdb backtrace. NUT apparently sets CFLAGS=-O if it is not set
already, so adding "CFLAGS=-g" to the ./configure line should do it.
>>>>
>>>> Arnaud, am I missing something obvious here? After making
"device.part" HU_STATIC, there shouldn't be any other string
descriptors retrieved in drivers/tripplite-hid.c.
>>>>
>>>> --
>>>> Charles Lepple
>>>> clepple at gmail
>>>>
>>>>
>>>>
>>>
<typescript-GDB-withCFLAGchange.gz><typescript_LOG_withCFLAG.gz>
>>
>
>

By the way, in nut-driver.service - i had to comment out StopWhenUnneeded=yes

for some reason systemd would end it each time - no matter if the server was 
loaded beforehand or not. once i did that it was fine



On Fri, 12 Jun 2015, Greg Hersch wrote:
> thanks - this has been fun.
>
> There is one other thing I have been having trouble with - and i've
tried it
> on two archlinuxarm installs and gotten the same thing. i am not even sure
if
> its important for me. but if i try to configure and make with neon support
-
> it cant find the neon libraries. despite neon having been installed several
> different ways (i tried pacman, as well as compiling and installign neon
from
> source)
>
> i only came across this because when i originally tried installing nut, i 
> tried doing it from the archlinux AUR. There, neon is enabled by default.
and
> i couldnt get it to build. so i ended up going to the source.
>
> Greg
>
>
> On Fri, 12 Jun 2015, Charles Lepple wrote:
>
>>  Greg,
>>
>>  I think I fixed it. Thanks for your patience.
>>
>>  https://github.com/networkupstools/nut/pull/213
>>
>>  Diffs:
>> 
https://github.com/networkupstools/nut/compare/usbhid_ups_input_vs_feature
>>
>>  If anyone else can test usbhid-ups against their hardware before I
merge
>>  this to master, I would appreciate it. I tried my MGE UPS on a Linux
box
>>  as well, and it does not get interrupt events there, either.
>>
>>  - Charles Lepple
>>
>>  On Jun 11, 2015, at 9:13 AM, Charles Lepple <clepple at
gmail.com> wrote:
>> 
>> >  Greg,
>> > 
>> >  I'm still not 100% on what is going on, but after comparing
the call
>> >  stack with a debug session here, I think I have at least
identified why
>> >  I wasn't seeing similar behavior.
>> > 
>> >  There are two ways that the driver can get information from the
UPS:
>> >  asking the UPS for a specific report (which returns one or more
values),
>> >  and checking the interrupt pipe (which the UPS can fill with
whatever
>> >  has changed). With the interrupt pipe results, the driver has to
do an
>> >  additional HID table lookup to determine exactly what is being
returned.
>> > 
>> >  It looks like the driver is processing the latter case when it
throws
>> >  that error. I wasn't seeing that here, apparently because my
MGE UPS on
>> >  FreeBSD is never getting anything via the interrupt pipe. (The
driver
>> >  falls back to the polling method.)
>> > 
>> >  I might have some time later to reconnect that UPS to a Linux
system and
>> >  see if the error crops up there. However, I have a suspicion that
the
>> >  bug is triggered because the first entry in the Tripp Lite table
has a
>> >  conversion function, and when the table lookup fails (your UPS
does not
>> >  have the HID item corresponding to a manufacturer's part
number), the
>> >  lookup function incorrectly returns that first table entry by
default.
>> > 
>> >  - Charles
>> > 
>> >  On Jun 10, 2015, at 12:18 PM, Greg Hersch <hersch.greg at
gmail.com> wrote:
>> > 
>> > > 
>> > >  And here are the logs and GDB output from the
reconfigured/recompiled
>> > >  CFLAGS=-G program. You will notice i made a change to the
version
>> > >  definition of tripplite-hid.c just to make sure i am working
with the
>> > >  updated version.
>> > > 
>> > >  On Tue, 9 Jun 2015, Charles Lepple wrote:
>> > > 
>> > > >  On Jun 9, 2015, at 4:55 PM, Greg Hersch wrote:
>> > > > 
>> > > > >  (gdb) bt
>> > > > >  #0  libusb_get_string (udev=0x43110, StringIdx=0,
buf=0x40204
>> > > > >  <buf>
>> > > > >  "", buflen=20) at libusb.c:496
>> > > > >  #1  0x00015330 in HIDGetIndexString
(udev=<optimized out>,
>> > > > >  Index=<optimized out>, buf=0x40204
<buf> "", buflen=<optimized
>> > > > >  out>)
>> > > > >  at libhid.c:407
>> > > > >  #2  0x00012e18 in ups_infoval_set (item=0x3ee48 
>> > > > >  <tripplite_hid2nut>,
>> > > > >  value=<optimized out>) at usbhid-ups.c:1552
>> > > > >  #3  0x00013da8 in upsdrv_updateinfo () at
usbhid-ups.c:835
>> > > > >  #4  0x00012410 in main (argc=<optimized
out>, argv=<optimized
>> > > > >  out>) at
>> > > > >  main.c:708
>> > > > 
>> > > >  You did everything right on the backtrace, but that is
puzzling.
>> > > > 
>> > > >  At #2, ups_infoval_set() apparently calls
HIDGetIndexString(), but I
>> > > >  don't see where it does that in the code. There
must be some
>> > > >  pointers, or something.
>> > > > 
>> > > >  The easiest thing might be to crank the debug output up
a bit more
>> > > >  (5x -D, even) but since that will be a bit more output,
please
>> > > >  redirect it to a file, and gzip the log before
attaching it. Doesn't
>> > > >  need to be long, just enough to see one or two errors.
>> > > > 
>> > > >  Another idea is to recompile without optimizations, to
see if that
>> > > >  helps the gdb backtrace. NUT apparently sets CFLAGS=-O
if it is not
>> > > >  set already, so adding "CFLAGS=-g" to the
./configure line should do
>> > > >  it.
>> > > > 
>> > > >  Arnaud, am I missing something obvious here? After
making
>> > > >  "device.part" HU_STATIC, there shouldn't
be any other string
>> > > >  descriptors retrieved in drivers/tripplite-hid.c.
>> > > > 
>> > > >  --
>> > > >  Charles Lepple
>> > > >  clepple at gmail
>> > > > 
>> > > > 
>> > > > 
>> > > 
<typescript-GDB-withCFLAGchange.gz><typescript_LOG_withCFLAG.gz>
>> > 
>> 
>> 
>

On Jun 12, 2015, at 10:33 AM, Greg Hersch <hersch.greg at gmail.com>
wrote:
> thanks - this has been fun.
> 
> There is one other thing I have been having trouble with - and i've
tried it on two archlinuxarm installs and gotten the same thing. i am not even
sure if its important for me. but if i try to configure and make with neon
support - it cant find the neon libraries. despite neon having been installed
several different ways (i tried pacman, as well as compiling and installign neon
from source)
> 
> i only came across this because when i originally tried installing nut, i
tried doing it from the archlinux AUR. There, neon is enabled by default. and i
couldnt get it to build. so i ended up going to the source.
Short answer: you don't need it for usbhid-ups.

libneon is used by http://www.networkupstools.org/docs/man/netxml-ups.html to
connect to some MGE/Eaton hardware, and by the corresponding nut-scanner module.

I'm not familiar with archlinux or AUR, but if you still have the logs, we
can certainly take a look. It might be that NUT is looking for an older version
of libneon, or that there is another dependency that is needed at build time.

-- 
Charles Lepple
clepple at gmail

Thanks - i won't sweat it then... i've now got upsmon running across 3
machines (a router (DDWRT optware), a raspberry pi (raspbian), and the
master archlinux system). and all seems to work well after a few
workarounds. thank you Charles

Greg

On Fri, 2015-06-12 at 20:24 -0400, Charles Lepple wrote:
> On Jun 12, 2015, at 10:33 AM, Greg Hersch <hersch.greg at gmail.com>
wrote:
> 
> > thanks - this has been fun.
> > 
> > There is one other thing I have been having trouble with - and
i've tried it on two archlinuxarm installs and gotten the same thing. i am
not even sure if its important for me. but if i try to configure and make with
neon support - it cant find the neon libraries. despite neon having been
installed several different ways (i tried pacman, as well as compiling and
installign neon from source)
> > 
> > i only came across this because when i originally tried installing
nut, i tried doing it from the archlinux AUR. There, neon is enabled by default.
and i couldnt get it to build. so i ended up going to the source.
> 
> Short answer: you don't need it for usbhid-ups.
> 
> libneon is used by http://www.networkupstools.org/docs/man/netxml-ups.html
to connect to some MGE/Eaton hardware, and by the corresponding nut-scanner
module.
> 
> I'm not familiar with archlinux or AUR, but if you still have the logs,
we can certainly take a look. It might be that NUT is looking for an older
version of libneon, or that there is another dependency that is needed at build
time.
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20150613/40cc115c/attachment.html>