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 <[email protected]> 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 <[email protected]> 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@gmail
> > >
> > >
> > >
> > <typescript-GDB-withCFLAGchange.gz><typescript_LOG_withCFLAG.gz>
>
_______________________________________________
Nut-upsdev mailing list
[email protected]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
