similar to: nutdrv_qx hangs after send: QS

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

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... >

Hi, I have used the truss command as directed. I have attached both the driver output and the last few sections of truss output leading to the hang. Both outputs end at the CTRL+C i pressed when i was forced to end the processes. Hope this is helpful. Please bear with me if i didn't run it with the right options etc - as I mentioned, I'm a little new to Solaris. Regards, Richard On

On Apr 4, 2015, at 9:48 PM, Richard Flint <richard.flint at gmail.com> wrote: > Again, apologies for my ignorance - are you suggesting that if the NUT application was built against openusb this would probably be fixed? Yes, that is my current theory. It's a little complicated in practice - openusb has a different API than libusb-0.1.x, but it supposedly includes a compatibility

On Apr 4, 2015, at 8:53 PM, Richard Flint <richard.flint at gmail.com> wrote: > I have used the truss command as directed. I have attached both the driver output and the last few sections of truss output leading to the hang. Both outputs end at the CTRL+C i pressed when i was forced to end the processes. > > Hope this is helpful. Please bear with me if i didn't run it with the

Hi, Apologies for the many replies. I have found this documentation: http://www.lehman.cuny.edu/cgi-bin/man-cgi?ugen+7 (I am using the ugen driver). Richard On Sun, Apr 5, 2015 at 3:34 AM Richard Flint <richard.flint at gmail.com> wrote: > Hi, > > I have to admit this sounds like it could screw up the system if not done > right - particularly because the solaris packaging

Hi, Unfortunately this approach isn't going to work. I've done some further research and it would appear that it is the underlying ugen device and not libusb that is failing to honor the timeout. https://mail-index.netbsd.org/tech-misc/2006/03/17/0000.html The person above worked around this by having the device opened in non blocking mode using the O_NONBLOCK flag but this required

Hi, I couldn't get openusb to make successfully but the good news is that Solaris seems to include openusb in the package repository and I have now installed it: ./usr/lib/libopenusb.so.0.0.1 Any idea how i can get NUT to build against this libopenusb which has been installed by Solaris? Regards, Richard On Sun, Apr 5, 2015 at 4:20 AM Charles Lepple <clepple at gmail.com> wrote:

On Mar 5, 2015, at 2:34 AM, Jakub <jakub.scepka at gmail.com> wrote: > Come on, it started to be interesting! Do you have one of these UPSes? If so, here was Dan's email about a branch to test: > If you still can't get it to work with nutdrv_atcl_usb, another > approach could be worth considering. > > Since this UPS seems to be supported by UPSmart2000I, it could

On Apr 4, 2015, at 10:45 PM, Richard Flint <richard.flint at gmail.com> wrote: > Hi, > > Apologies for the many replies. I have found this documentation: > http://www.lehman.cuny.edu/cgi-bin/man-cgi?ugen+7 > > (I am using the ugen driver). Right, AFAIK ugen is the kernel driver that libusb and openusb talk to (/dev/usb/*). Updated diagram: upsc --- upsd --- nutdrv_qx

It seems like it works (partially?) with NUT/driver you mentioned. I will test it more when I return home. root at Failure:/lib/nut# ./nutdrv_qx -a test -x subdriver=fuji -u root -x productid=0000 -x vendorid=0001 -DDDDDD Network UPS Tools - Generic Q* USB/Serial driver 0.13 (2.7.2.5) USB communication driver 0.32 0.000000 debug level is '6' 0.001247 upsdrv_initups...

Hi, I have to admit this sounds like it could screw up the system if not done right - particularly because the solaris packaging system is unlikely to allow me to remove the libusb package if many things are dependent on it. Are there any other options - e.g. doing something with the libusb that ships with solaris - are we sure it doesn't support timeouts? I think I found some code relating

On Apr 5, 2015, at 12:26 AM, Richard Flint <richard.flint at gmail.com> wrote: > Any idea how i can get NUT to build against this libopenusb which has been installed by Solaris? ... > It might be possible to do the following: > > ? install openusb into an alternate directory (e.g. $HOME/local) > ? set PKG_CONFIG_PATH to anything that doesn't contain the system libusb.pc

On Apr 6, 2015, at 8:46 AM, Richard Flint <richard.flint at gmail.com> wrote: > Unfortunately this approach isn't going to work. > > I've done some further research and it would appear that it is the underlying ugen device and not libusb that is failing to honor the timeout. > > https://mail-index.netbsd.org/tech-misc/2006/03/17/0000.html > > The person above

Again, apologies for my ignorance - are you suggesting that if the NUT application was built against openusb this would probably be fixed? If so I'm happy to give this a try - any idea how can I tell NUT to build against openusb instead of libusb? Regards, Richard On Sun, Apr 5, 2015 at 2:28 AM Charles Lepple <clepple at gmail.com> wrote: > On Apr 4, 2015, at 8:53 PM, Richard

Hello, I have a Salicru UPS connected by USB using nutdrv_qx driver. As I see that it was using too much CPU time (or at least, too much for what I think it should be normal), I used strace to see what is was using, and got a lot of lines like these: %<------------%<------------%<------------%<------------ ioctl(4, USBDEVFS_REAPURBNDELAY, 0x7ffdca143278) = -1 EAGAIN (Resource

Jim Klimov via Nut-upsuser <nut-upsuser at alioth-lists.debian.net> > > Cheers, > > One PR waiting to get into 2.8.1 release timeframe is https://github.com/networkupstools/nut/pull/1652 stemming from issue https://github.com/networkupstools/nut/issues/1279 > > The gist of it is that "battery.voltage" and "battery.charge" were not always reported

Jim Klimov via Nut-upsuser <nut-upsuser at alioth-lists.debian.net> > > Cheers, > > One PR waiting to get into 2.8.1 release timeframe is https://github.com/networkupstools/nut/pull/1652 stemming from issue https://github.com/networkupstools/nut/issues/1279 > > The gist of it is that "battery.voltage" and "battery.charge" were not always reported

I have a list of items on a page. Each item has a select list. If someone changes the select list I would like to update the appropriate record on the server....nothing else. I suspect I am making this too difficult. I have an action on my controller for updating this value. I just tried the ''remote_function'', ah, function. It invokes the action on the controller but the the

Hello All, I tested our new UPS yesterday. I noticed that while the blazer_ups drivers support this device, the newer nutdrv_qx does not. I suppose that this should not be the case, as nutdrv_qx will replace blazer_ups(?). Versions: I installed Nut on Ubuntu 13.10 (64 bit) from the standard package (2.6.4-2.3ubuntu2), and I also installed from the source tarball (2.7.1), into a different