[Nut-upsdev] libusb_get_string: invalid argument

[Charles Lepple]

On Jun 8, 2015, at 8:23 PM, Greg Hersch <hersch.greg at gmail.com> wrote:

> Hi Charles. I patched, reconfigured, remake'd, remake install'd - but
> no change. however, some more likely helpful information below for
> you. Thank you

Odd. Are you sure that the new version of usbhid-ups got installed to the same path you are running? Also, there is no protection against running two drivers if one is in debug mode. Please check that usbhid-ups is not still running in the background from an earlier run.

You can also add some text to the version string in drivers/tripplite-hid.c - it will show up as "Using subdriver: TrippLite HID 0.81" in the stock version.

> On Mon, Jun 8, 2015 at 12:34 PM, Greg Hersch <hersch.greg at gmail.com> wrote:
>> 
>> 
>> On Sun, 7 Jun 2015, Charles Lepple wrote:
>> 
>>> [please use reply-all to include the list, as the list does not override
>>> the Reply-To header.]
>>> 
>>> On Jun 7, 2015, at 5:02 PM, Greg Hersch <hersch.greg at gmail.com> wrote:
>>> 
>>>> Here is the driver debug log. If I just let it run, it pops up with
>>>> libusb_get_string_invalid argument over and over again, mixed in the
>>>> debug output. seems to be several issues reported in the log, but they
>>>> arent easily interpreted.
>>> 
>>> 
>>> Does the libusb_get_string error occur only every 30 seconds or so?
>> 
>> 
>> Yes - thats correct. perhaps more like every 15 sec.
> 
> I was incorrect. they occur every 6 seconds. and there are two of them
> each time.
> hopefully that narrows it down!

Unfortunately, no. I was thinking either every 30 seconds or every two seconds, and I'm not sure why they would occur two at a time every six seconds.

I'm not sure if we have enough log messages in the code already. If you can use GDB, you could do something like the following:

gdb /usr/local/ups/bin/usbhid-ups
...
(gdb) break libusb_get_string
(gdb) run -DD -a tripplite
...
(gdb) c
...
(gdb) bt

Keep pressing "c" until you get past the initial detection, which probably succeeds.

That last line should print a backtrace showing which function called the offending function.

>>> 
>>> Also, I would be interested in the output of "lsusb -vvv -d 09ae:" for
>>> your UPS.
> 
> Here it is:
> 
Thanks. Doesn't look too different than what we've seen before, so I'm optimistic.

-- 
Charles Lepple
clepple at gmail