# ldd /lib64/nut/usbhid-ups
linux-vdso.so.1 (0x00007ffdfe3e3000)
libusb-0.1.so.4 => /lib64/libusb-0.1.so.4 (0x00007f98526e6000)
<-- from libusbp-compat-0.1.5-r2
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f98524ca000)
libc.so.6 => /lib64/libc.so.6 (0x00007f985212f000)
libusb-1.0.so.0 => /lib64/libusb-1.0.so.0 (0x00007f9851f17000)
<-- from libusb-1.0.19
/lib64/ld-linux-x86-64.so.2 (0x00007f98528ec000)
libudev.so.1 => /lib64/libudev.so.1 (0x00007f9852aa6000)
librt.so.1 => /lib64/librt.so.1 (0x00007f9851d0f000)
libm.so.6 => /lib64/libm.so.6 (0x00007f9851a14000)
libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f98517fd000)
libcap.so.2 => /lib64/libcap.so.2 (0x00007f98515f7000)
libattr.so.1 => /lib64/libattr.so.1 (0x00007f98513f2000)
I haven't cracked open the nut sources yet, but am curious why it should
fail to open the usb device after already succeeding many times.
Could it be a USB power management issue? Or simply opening it too many
times somehow breaks it?
On Thu, Dec 31, 2015 at 4:06 PM, Charles Lepple <clepple at gmail.com>
wrote:
> On Dec 31, 2015, at 5:31 PM, Nicholas Leippe <leippe at gmail.com>
wrote:
> >
> > Is this something to cross post to linux-usb?
>
> I guess, although they might need to know some additional details about
> your libusb configuration (real libusb-0.1.x, or libusb-1.x with
> libusb-compat).
>
> Here is the relevant portion of the code:
>
> https://github.com/networkupstools/nut/blob/master/drivers/libusb.c#L262
>
> > On Mon, Nov 23, 2015 at 8:47 PM, Charles Lepple <clepple at
gmail.com>
> wrote:
> > On Nov 20, 2015, at 11:22 AM, Nicholas Leippe <leippe at
gmail.com> wrote:
> > >
> > > 1389.279158 Trying to match device
> > > 1389.279164 Device matches
> > > 1389.279169 failed to claim USB device: Device or resource
busy
> > > 1389.279175 failed to detach kernel driver from USB device:
No
> such file or directory
> >
> > Can you check around and see if anyone else has any wisdom on this
error
> message? I vaguely recall trying to track this down, and not finding the
> ENOENT error in the kernel code.
> >
> > > upsdrvctl is not noticing this exit, so the openrc service
scripts get
> into a stuck state also--I have to stop, then zap the upsdrv service before
> I can start it again.
> > > Each time it works fine for some non-deterministic amount of time
then
> dies.
> >
> > So the usbhid-ups driver is no longer running at that point? upsdrvctl
> just starts the driver(s) - it does not stick around, at least not in the
> default NUT configuration. I am not familiar with openrc, but in general,
> making the init system track one or more driver PIDs in a generic fashion
> is an unsolved problem.
> >
> > That said, I'm wondering if NUT is retrying too quickly. (The
default
> retry works fine for an older MGE on a slightly-less-old Soekris box
> running BSD - it reconnects about once every day or two. But I don't
have
> any Gentoo boxes or 4.x kernels to test against at the moment.)
> >
> > --
> > Charles Lepple
> > clepple at gmail
> >
> >
> >
> >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20151231/c6cd0797/attachment.html>
Thanks for the libusb version numbers. By the way, which version of NUT are you using? On Dec 31, 2015, at 6:23 PM, Nicholas Leippe <leippe at gmail.com> wrote:> > I haven't cracked open the nut sources yet, but am curious why it should fail to open the usb device after already succeeding many times. > Could it be a USB power management issue? Or simply opening it too many times somehow breaks it?One major difference between the initial startup of usbhid-ups and when it tries to reconnect: in the former case, the USB stack has had time to fully start up all of the kernel-side drivers. When usbhid-ups attempts to claim the UPS HID interface for the first time after the UPS is plugged in (or has reattached itself), the kernel USB HID driver causes an EBUSY return code ("failed to claim USB device: Device or resource busy"). Usually, the EBUSY code goes away after usbhid-ups tells the kernel to relinquish the interface (line 271 [*]), but in your case, it is possible that the USB HID driver hasn't completely started up. This might explain the "failed to detach kernel driver from USB device: No such file or directory" error. [*] https://github.com/networkupstools/nut/blob/master/drivers/libusb.c#L271 Since dmesg now shows timestamps, you might want to check to see the time delta between when the UPS is first detected, and when USB-related messages stop appearing. It's about half a second on this Raspberry Pi (which incidentally is now running a 4.1.x kernel): [ 2.893909] usb 1-1.2: new low-speed USB device number 4 using dwc_otg [ 3.041108] usb 1-1.2: New USB device found, idVendor=09ae, idProduct=3016 [ 3.050101] usb 1-1.2: New USB device strings: Mfr=3, Product=1, SerialNumber=5 [ 3.059367] usb 1-1.2: Product: TRIPP LITE UPS [ 3.065704] usb 1-1.2: Manufacturer: Tripp Lite [ 3.558046] hid-generic 0003:09AE:3016.0001: hiddev0,hidraw0: USB HID v1.11 Device [Tripp Lite TRIPP LITE UPS] on usb-20980000.usb-1.2/input0 Note that NUT does not use the kernel USB HID drivers, which is why it has to detach those drivers to allow libusb to connect. Other than the reconnection attempts, usbhid-ups only fully opens the UPS USB device once.
On Thu, Dec 31, 2015 at 4:43 PM, Charles Lepple <clepple at gmail.com> wrote:> Thanks for the libusb version numbers. By the way, which version of NUT > are you using? > >nut-2.7.3> On Dec 31, 2015, at 6:23 PM, Nicholas Leippe <leippe at gmail.com> wrote: > > > > I haven't cracked open the nut sources yet, but am curious why it should > fail to open the usb device after already succeeding many times. > > Could it be a USB power management issue? Or simply opening it too many > times somehow breaks it? > > One major difference between the initial startup of usbhid-ups and when it > tries to reconnect: in the former case, the USB stack has had time to fully > start up all of the kernel-side drivers. > > When usbhid-ups attempts to claim the UPS HID interface for the first time > after the UPS is plugged in (or has reattached itself), the kernel USB HID > driver causes an EBUSY return code ("failed to claim USB device: Device or > resource busy"). Usually, the EBUSY code goes away after usbhid-ups tells > the kernel to relinquish the interface (line 271 [*]), but in your case, it > is possible that the USB HID driver hasn't completely started up. This > might explain the "failed to detach kernel driver from USB device: No such > file or directory" error. > > [*] > https://github.com/networkupstools/nut/blob/master/drivers/libusb.c#L271 > > Since dmesg now shows timestamps, you might want to check to see the time > delta between when the UPS is first detected, and when USB-related messages > stop appearing. It's about half a second on this Raspberry Pi (which > incidentally is now running a 4.1.x kernel): > > [ 2.893909] usb 1-1.2: new low-speed USB device number 4 using dwc_otg > [ 3.041108] usb 1-1.2: New USB device found, idVendor=09ae, > idProduct=3016 > [ 3.050101] usb 1-1.2: New USB device strings: Mfr=3, Product=1, > SerialNumber=5 > [ 3.059367] usb 1-1.2: Product: TRIPP LITE UPS > [ 3.065704] usb 1-1.2: Manufacturer: Tripp Lite > [ 3.558046] hid-generic 0003:09AE:3016.0001: hiddev0,hidraw0: USB HID > v1.11 Device [Tripp Lite TRIPP LITE UPS] on usb-20980000.usb-1.2/input0 > > Note that NUT does not use the kernel USB HID drivers, which is why it has > to detach those drivers to allow libusb to connect. > > Other than the reconnection attempts, usbhid-ups only fully opens the UPS > USB device once. >This is then what confuses me, because it *works* and then dies. If it opens it only once, then why would it fail opening it again--wouldn't it just hold it open and continue to work? It's never failing to start, it's failing to continue working. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20151231/a902df71/attachment-0001.html>