[Nut-upsuser] nutdrv_qx hangs after send: QS

[Richard Flint]

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>