[Nut-upsuser] nutdrv_qx hangs after send: QS

Charles Lepple clepple at gmail.com
Sat Apr 4 23:44:25 UTC 2015


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/20150404/e6bbb679/attachment.html>


More information about the Nut-upsuser mailing list