[Nut-upsuser] nutdrv_qx hangs after send: QS
Richard Flint
richard.flint at gmail.com
Sun Apr 5 00:08:58 UTC 2015
Thank you for the rapid response. I will try and investigate getting
answers to some of your points but I'm a little new to Solaris so I'll need
some time. Glancing at the configure output, it looks like it built against
v0.1.7 of libusb (yes i think that is derived from the one you mention),
checking for libusb version via pkg-config... 0.1.7 found
checking for libusb cflags...
checking for libusb ldflags... -lusb
checking for usb.h... yes
checking for usb_init... yes
checking for usb_detach_kernel_driver_np... no
I will first investigate how to set the debug level.
Regards,
Richard
On Sun, Apr 5, 2015 at 12:44 AM Charles Lepple <clepple at gmail.com> wrote:
> On Apr 4, 2015, at 7:19 PM, Richard Flint <richard.flint at gmail.com> wrote:
>
> More extensive debugging by running the driver sudo ./nutdrv_qx -u root -a
> MY_UPS -DDDDDD indicates the driver works normally then will randomly stop
> working at stop "send: QS". The debug logs show values successfully
> retrieved repeatedly until something like:
> ....
> Quick update...
> send: QS
> read: (247.9 239.1 248.0 005 50.0 27.5 --.- 00001001
> update_status: OL
> update_status: !LB
> update_status: !CAL
> update_status: !FSD
> upsdrv_updateinfo...
> Quick update...
> send: QS
> (driver hangs here)
>
> I'm using Generic Q* USB/Serial driver 0.06 (2.7.2) with USB communication
> driver 0.32. Playing with pollinterval didn't help - Is there anything
> further I can do to help troubleshoot this problem?
>
>
> Thanks, this narrows it down a good deal.
>
> @zykh made some changes to nutdrv_qx since the 2.7.2 release, but at first
> glance, I don't think those will alter the symptoms you are seeing.
>
> Can you provide some detail on the libusb port that you built against? If
> it is derived from the original sourceforge.net libusb-0.1, does it have
> a USB_DEBUG environment variable that can be set to log extra information?
>
> Also, is it possible to do a system call trace to figure out what libusb
> and the OS are doing at the time of the hang? It's been a while since I
> last used Solaris, but if memory serves, you could use something like truss
> to approximate what strace does on Linux.
>
> --
> Charles Lepple
> clepple at gmail
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20150405/c89a2aab/attachment-0001.html>
More information about the Nut-upsuser
mailing list