[Nut-upsdev] libusb_get_string: invalid argument (other usbhid-ups users, please test)

[Greg Hersch]

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>
>> > 
>> 
>> 
>