This issue has been occurring for years on my setup. OS: Gentoo most recent kernel: 4.1.12 UPS: Eaton Powerware 9130 rackmount 2000kVA, connected via USB The upsdrv service dies and must be restarted several times a day. Zero output to dmesg or any other log other than failed reattempts reporting no such file or directory errors. "/lib64/nut/usbhid-ups -DDD -q -a powerware" exited 1 and this is the tail end of its output: 1383.519082 Quick update... 1383.519694 Report[get]: (5 bytes) => 16 ff ff ff ff 1383.519701 Path: UPS.PowerSummary.DelayBeforeStartup, Type: Feature, ReportID: 0x16, Offset: 0, Size: 32, Value: 0 1383.520268 Report[get]: (5 bytes) => 15 ff ff ff ff 1383.520274 Path: UPS.PowerSummary.DelayBeforeShutdown, Type: Feature, ReportID: 0x15, Offset: 0, Size: 32, Value: 0 1383.520887 Report[get]: (6 bytes) => 32 00 61 00 00 00 1383.520895 Path: UPS.PowerSummary.PresentStatus.ACPresent, Type: Feature, ReportID: 0x32, Offset: 8, Size: 1, Value: 1 1383.520898 Report[buf]: (6 bytes) => 32 00 61 00 00 00 1383.520900 Path: UPS.PowerSummary.PresentStatus.Discharging, Type: Feature, ReportID: 0x32, Offset: 12, Size: 1, Value: 0 1383.520903 Report[buf]: (6 bytes) => 32 00 61 00 00 00 1383.520905 Path: UPS.PowerSummary.PresentStatus.Charging, Type: Feature, ReportID: 0x32, Offset: 10, Size: 1, Value: 0 1383.520907 Report[buf]: (6 bytes) => 32 00 61 00 00 00 1383.520909 Path: UPS.PowerSummary.PresentStatus.BelowRemainingCapacityLimit, Type: Feature, ReportID: 0x32, Offset: 9, Size: 1, Value: 0 1385.270723 upsdrv_updateinfo... 1385.520798 libusb_get_interrupt: Connection timed out 1385.520815 Got 0 HID objects... 1385.520819 Quick update... 1385.521445 Report[get]: (5 bytes) => 16 ff ff ff ff 1385.521455 Path: UPS.PowerSummary.DelayBeforeStartup, Type: Feature, ReportID: 0x16, Offset: 0, Size: 32, Value: 0 1385.522194 Report[get]: (5 bytes) => 15 ff ff ff ff 1385.522202 Path: UPS.PowerSummary.DelayBeforeShutdown, Type: Feature, ReportID: 0x15, Offset: 0, Size: 32, Value: 0 1385.522820 Report[get]: (6 bytes) => 32 00 61 00 00 00 1385.522829 Path: UPS.PowerSummary.PresentStatus.ACPresent, Type: Feature, ReportID: 0x32, Offset: 8, Size: 1, Value: 1 1385.522834 Report[buf]: (6 bytes) => 32 00 61 00 00 00 1385.522837 Path: UPS.PowerSummary.PresentStatus.Discharging, Type: Feature, ReportID: 0x32, Offset: 12, Size: 1, Value: 0 1385.522841 Report[buf]: (6 bytes) => 32 00 61 00 00 00 1385.522844 Path: UPS.PowerSummary.PresentStatus.Charging, Type: Feature, ReportID: 0x32, Offset: 10, Size: 1, Value: 0 1385.522848 Report[buf]: (6 bytes) => 32 00 61 00 00 00 1385.522851 Path: UPS.PowerSummary.PresentStatus.BelowRemainingCapacityLimit, Type: Feature, ReportID: 0x32, Offset: 9, Size: 1, Value: 0 1387.270796 upsdrv_updateinfo... 1387.520864 libusb_get_interrupt: Connection timed out 1387.520875 Got 0 HID objects... 1387.520878 Quick update... 1387.521591 Report[get]: (5 bytes) => 16 ff ff ff ff 1387.521600 Path: UPS.PowerSummary.DelayBeforeStartup, Type: Feature, ReportID: 0x16, Offset: 0, Size: 32, Value: 0 1387.522173 Report[get]: (5 bytes) => 15 ff ff ff ff 1387.522178 Path: UPS.PowerSummary.DelayBeforeShutdown, Type: Feature, ReportID: 0x15, Offset: 0, Size: 32, Value: 0 1387.522540 libusb_get_report: Input/output error 1387.522548 Can't retrieve Report 32: Input/output error 1389.272561 upsdrv_updateinfo... 1389.272573 Got to reconnect! 1389.272600 Checking device (8087/8000) (004/002) 1389.272613 Failed to open device, skipping. (Permission denied) 1389.272616 Checking device (1D6B/0002) (004/001) 1389.272619 Failed to open device, skipping. (Permission denied) 1389.272621 Checking device (8087/8008) (003/002) 1389.272624 Failed to open device, skipping. (Permission denied) 1389.272625 Checking device (1D6B/0002) (003/001) 1389.272628 Failed to open device, skipping. (Permission denied) 1389.272630 Checking device (0BDA/0307) (002/051) 1389.272633 Failed to open device, skipping. (Permission denied) 1389.272635 Checking device (0451/8041) (002/004) 1389.272638 Failed to open device, skipping. (Permission denied) 1389.272640 Checking device (0451/8041) (002/003) 1389.272643 Failed to open device, skipping. (Permission denied) 1389.272644 Checking device (174C/3074) (002/002) 1389.272647 Failed to open device, skipping. (Permission denied) 1389.272649 Checking device (1D6B/0003) (002/001) 1389.272651 Failed to open device, skipping. (Permission denied) 1389.272653 Checking device (046D/C00E) (001/002) 1389.272656 Failed to open device, skipping. (Permission denied) 1389.272658 Checking device (0451/8043) (001/008) 1389.272661 Failed to open device, skipping. (Permission denied) 1389.272663 Checking device (0451/8043) (001/007) 1389.272665 Failed to open device, skipping. (Permission denied) 1389.272667 Checking device (174C/2074) (001/006) 1389.272670 Failed to open device, skipping. (Permission denied) 1389.272671 Checking device (0463/FFFF) (001/004) 1389.279138 - VendorID: 0463 1389.279147 - ProductID: ffff 1389.279149 - Manufacturer: EATON Powerware 1389.279152 - Product: 9130 1389.279154 - Serial Number: GD261A0267 1389.279156 - Bus: 001 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 1389.279178 failed to claim USB device: Device or resource busy 1389.279181 failed to detach kernel driver from USB device: No such file or directory 1389.279184 failed to claim USB device: Device or resource busy 1389.279187 failed to detach kernel driver from USB device: No such file or directory 1389.279190 failed to claim USB device: Device or resource busy 1389.279192 failed to detach kernel driver from USB device: No such file or directory 1389.279195 Can't claim USB device [0463:ffff]: No such file or directory 1389.279200 upsdrv_cleanup... 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20151120/e7d7d2bd/attachment.html>
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 directoryCan 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
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 > > > >
# 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>