<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 31, 2015 at 4:43 PM, Charles Lepple <span dir="ltr"><<a href="mailto:clepple@gmail.com" target="_blank">clepple@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thanks for the libusb version numbers. By the way, which version of NUT are you using?<br>
<span class=""><br></span></blockquote><div><br></div><div>nut-2.7.3<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
On Dec 31, 2015, at 6:23 PM, Nicholas Leippe <<a href="mailto:leippe@gmail.com">leippe@gmail.com</a>> wrote:<br>
><br>
> 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.<br>
> Could it be a USB power management issue? Or simply opening it too many times somehow breaks it?<br>
<br>
</span>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.<br>
<br>
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.<br>
<br>
[*] <a href="https://github.com/networkupstools/nut/blob/master/drivers/libusb.c#L271" rel="noreferrer" target="_blank">https://github.com/networkupstools/nut/blob/master/drivers/libusb.c#L271</a><br>
<br>
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):<br>
<br>
[    2.893909] usb 1-1.2: new low-speed USB device number 4 using dwc_otg<br>
[    3.041108] usb 1-1.2: New USB device found, idVendor=09ae, idProduct=3016<br>
[    3.050101] usb 1-1.2: New USB device strings: Mfr=3, Product=1, SerialNumber=5<br>
[    3.059367] usb 1-1.2: Product: TRIPP LITE UPS<br>
[    3.065704] usb 1-1.2: Manufacturer: Tripp Lite<br>
[    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<br>
<br>
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.<br>
<br>
Other than the reconnection attempts, usbhid-ups only fully opens the UPS USB device once.<br></blockquote><div><br></div><div>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.<br><br></div><div><br></div></div></div></div>