Hi, I am trying to get NUT 2.7.2 working on my Solaris 11.2 system with a PowerWalker 2000 VI PSW UPS. I have carefully configured the software such that it 'works' using custom values in the ups.conf file: driver = nutdrv_qx port = auto desc = "my UPS" protocol = voltronic-qs subdriver = cypress vendorid = 0665 productid = 5161 The problem I'm experiencing is that after a random amount of time, usually a few mins, the driver stops providing data and the and the application complains the data is "stale". 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? Regards, Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20150404/b7f19e8a/attachment.html>
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>
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>