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 right options etc - as I mentioned, I'm a little new to Solaris.Well, it did provide some information, but I'll be honest that I don't know what else we can get from truss. Stepping back a bit, here is the stack: upsc --- upsd --- nutdrv_qx --- libusb -+- Solaris kernel --- UPS truss is tracing at the "+" sign: the boundary between user space and kernel space. When the driver gets a valid response, the truss log looks like this: 5834: Q u i c k u p d a t e . . . 5834: write(2, "\n", 1) = 1 5834: write(5, 0x082DA320, 16) = 16 5834: !\t\002\0\0\b\0 Q S\r\0\0\0\0\0 5834: write(2, " 1 6 1", 4) = 4 5834: write(2, " .", 1) = 1 5834: write(2, " 3 9 5 1 0 8", 6) = 6 5834: write(2, "\t", 1) = 1 5834: write(2, " s e n d : Q S", 8) = 8 5834: write(2, "\n", 1) = 1 5834: open("/dev/usb/665.5161/0/if0in1stat", O_RDWR) = 8 5834: write(8, "01", 1) = 1 5834: open("/dev/usb/665.5161/0/if0in1", O_RDONLY) = 9 5834: read(9, " ( 2 4 5 . 4 2", 8) = 8 5834: close(9) = 0 5834: close(8) = 0 ... The failed poll at the end looks like this: 5834: Q u i c k u p d a t e . . . 5834: write(2, "\n", 1) = 1 5834: write(5, 0x082DA320, 16) (sleeping...) 5834: write(5, 0x082DA320, 16) = 16 5834: !\t\002\0\0\b\0 Q S\r\0\0\0\0\0 5834: write(2, " 1 6 9", 4) = 4 5834: write(2, " .", 1) = 1 5834: write(2, " 8 5 8 9 3 0", 6) = 6 5834: write(2, "\t", 1) = 1 5834: write(2, " s e n d : Q S", 8) = 8 5834: write(2, "\n", 1) = 1 5834: open("/dev/usb/665.5161/0/if0in1stat", O_RDWR) = 8 5834: write(8, "01", 1) = 1 5834: open("/dev/usb/665.5161/0/if0in1", O_RDONLY) = 9 5834: read(9, 0xFC9BC650, 8) (sleeping...) ^C I did run across a comment in the NUT configure.ac that says "dnl FIXME: Sun's libusb doesn't support timeout (so blocks notification)". This is unfortunate, since other libusb platforms will time out after ~5 seconds, and most of the drivers have retry logic to handle that. I couldn't find any relevant source code when searching for Solaris libusb 0.1.7 with Google. Do you have any other information about the libusb that is installed there? There is also this fork of libusb that claims to support Solaris, and the code seems to have timeouts: http://sourceforge.net/projects/openusb/ -- Charles Lepple clepple at gmail -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20150404/d7536c99/attachment.html>
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 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 > right options etc - as I mentioned, I'm a little new to Solaris. > > > Well, it did provide some information, but I'll be honest that I don't > know what else we can get from truss. > > Stepping back a bit, here is the stack: > > upsc --- upsd --- nutdrv_qx --- libusb -+- Solaris kernel --- UPS > > truss is tracing at the "+" sign: the boundary between user space and > kernel space. > > When the driver gets a valid response, the truss log looks like this: > > 5834: Q u i c k u p d a t e . . . > 5834: write(2, "\n", 1) = 1 > 5834: write(5, 0x082DA320, 16) = 16 > 5834: !\t\002\0\0\b\0 Q S\r\0\0\0\0\0 > 5834: write(2, " 1 6 1", 4) = 4 > 5834: write(2, " .", 1) = 1 > 5834: write(2, " 3 9 5 1 0 8", 6) = 6 > 5834: write(2, "\t", 1) = 1 > 5834: write(2, " s e n d : Q S", 8) = 8 > 5834: write(2, "\n", 1) = 1 > 5834: open("/dev/usb/665.5161/0/if0in1stat", O_RDWR) = 8 > 5834: write(8, "01", 1) = 1 > 5834: open("/dev/usb/665.5161/0/if0in1", O_RDONLY) = 9 > *5834: read(9, " ( 2 4 5 . 4 2", 8) = 8* > 5834: close(9) = 0 > 5834: close(8) = 0 > ... > > The failed poll at the end looks like this: > > 5834: Q u i c k u p d a t e . . . > 5834: write(2, "\n", 1) = 1 > 5834: write(5, 0x082DA320, 16) (sleeping...) > 5834: write(5, 0x082DA320, 16) = 16 > 5834: !\t\002\0\0\b\0 Q S\r\0\0\0\0\0 > 5834: write(2, " 1 6 9", 4) = 4 > 5834: write(2, " .", 1) = 1 > 5834: write(2, " 8 5 8 9 3 0", 6) = 6 > 5834: write(2, "\t", 1) = 1 > 5834: write(2, " s e n d : Q S", 8) = 8 > 5834: write(2, "\n", 1) = 1 > 5834: open("/dev/usb/665.5161/0/if0in1stat", O_RDWR) = 8 > 5834: write(8, "01", 1) = 1 > 5834: open("/dev/usb/665.5161/0/if0in1", O_RDONLY) = 9 > *5834: read(9, 0xFC9BC650, 8) (sleeping...)* > ^C > > I did run across a comment in the NUT configure.ac that says "dnl FIXME: > Sun's libusb doesn't support timeout (so blocks notification)". This is > unfortunate, since other libusb platforms will time out after ~5 seconds, > and most of the drivers have retry logic to handle that. > > I couldn't find any relevant source code when searching for Solaris libusb > 0.1.7 with Google. Do you have any other information about the libusb that > is installed there? > > There is also this fork of libusb that claims to support Solaris, and the > code seems to have timeouts: http://sourceforge.net/projects/openusb/ > > -- > Charles Lepple > clepple at gmail > > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20150405/be17d583/attachment-0001.html>
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 layer. If openusb works, I would not expect it to wait for more than 1 or 5 seconds when reading the reply.> If so I'm happy to give this a try - any idea how can I tell NUT to build against openusb instead of libusb?Not sure exactly, but to be safe, I'd make an extra backup of wherever libusb is installed - my concern is that other things might be using libusb, and openusb could interfere. Ideally, openusb is a strict superset of libusb, but I haven't used it myself. openusb does seem to use the same library name as libusb, so if libusb was installed by a package, you might want to uninstall libusb first to avoid conflicts. NUT uses either the generic pkg-config tool or a libusb-config binary to find the USB library. openusb seems to install an openusb-config file which could be symlinked to libusb-config in /usr/local/bin (once the original libusb package is out of the way). At that point, you can re-run the NUT ./configure script, and it should list the openusb version number (1.1.11?) instead of 0.1.7. -- Charles Lepple clepple at gmail -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20150404/5ed2ccf6/attachment.html>