On Sep 9, 2015, at 9:40 AM, Rob Groner <rgroner at RTD.com> wrote:> > I'm not sure which USB lib it compiled against.What does this return? ldd /path/to/driver -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20150909/ba08f4c0/attachment.html>
linux-5048:/home/rtd # ldd /usr/local/ups/bin/usbhid-ups linux-vdso.so.1 (0x00007fff403fc000) libusb-0.1.so.4 => /usr/lib64/libusb-0.1.so.4 (0x00007f7c34b56000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f7c34939000) libc.so.6 => /lib64/libc.so.6 (0x00007f7c34590000) libusb-1.0.so.0 => /usr/lib64/libusb-1.0.so.0 (0x00007f7c34378000) /lib64/ld-linux-x86-64.so.2 (0x00007f7c34d7a000) libudev.so.1 => /usr/lib64/libudev.so.1 (0x00007f7c34362000) librt.so.1 => /lib64/librt.so.1 (0x00007f7c34159000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f7c33f55000) Rob Groner Software Engineer Level II RTD Embedded Technologies, Inc. ISO 9001 and AS9100 Certified Ph: +1 814-234-8087 www.rtd.com<http://www.rtd.com/> From: Charles Lepple [mailto:clepple at gmail.com] Sent: Wednesday, September 09, 2015 10:05 AM To: Rob Groner <rgroner at RTD.com> Cc: Roger Price <roger at rogerprice.org>; nut-upsuser Mailing List <nut-upsuser at lists.alioth.debian.org> Subject: Re: [Nut-upsuser] UPS/NUT with openSUSE 13.1 On Sep 9, 2015, at 9:40 AM, Rob Groner <rgroner at RTD.com<mailto:rgroner at RTD.com>> wrote: I'm not sure which USB lib it compiled against. What does this return? ldd /path/to/driver -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20150909/2aa66bb1/attachment.html>
I?ve now installed the package on a brand new Porteus 3.1.0 install, and it works just fine. The shutdown command is in /etc/rc.d/rc.local_shutdown and works so far (though only a few test runs have been executed). I?d still like to pursue what is wrong with openSUSE, as it is a more mainstream distro than Porteus. But I do feel that openSUSE itself is the problem. Rob Groner Software Engineer Level II RTD Embedded Technologies, Inc. ISO 9001 and AS9100 Certified Ph: +1 814-234-8087 www.rtd.com<http://www.rtd.com/> From: Charles Lepple [mailto:clepple at gmail.com] Sent: Wednesday, September 09, 2015 10:05 AM To: Rob Groner <rgroner at RTD.com> Cc: Roger Price <roger at rogerprice.org>; nut-upsuser Mailing List <nut-upsuser at lists.alioth.debian.org> Subject: Re: [Nut-upsuser] UPS/NUT with openSUSE 13.1 On Sep 9, 2015, at 9:40 AM, Rob Groner <rgroner at RTD.com<mailto:rgroner at RTD.com>> wrote: I'm not sure which USB lib it compiled against. What does this return? ldd /path/to/driver -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20150909/74887fa8/attachment.html>
> On Sep 9, 2015, at 10:12 AM, Rob Groner <rgroner at RTD.com> wrote: > > linux-5048:/home/rtd # ldd /usr/local/ups/bin/usbhid-ups > linux-vdso.so.1 (0x00007fff403fc000) > libusb-0.1.so.4 => /usr/lib64/libusb-0.1.so.4 (0x00007f7c34b56000)The last line seems to indicate that it is the real libusb-0.1, not -compat. What kernel version on openSUSE? -- Charles Lepple clepple at gmail -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20150909/5f1d65cd/attachment-0001.html>
On Sep 15, 2015, at 5:12 PM, Rob Groner <rgroner at RTD.com> wrote:> > Charles, > > Trying to track down the source of the problem, I checked Yast to make sure I had at least 0.1.8 version for libusb. I saw this (attached photo). Is it then actually using ?compat instead of the ?real? libusb? And is that a problem?You're right, both the -compat and real libusb packages will use the same libusb-0.1.so* name. It's not necessarily a problem, but it does mean that there is different code between your driver and the kernel. Most of the NUT testing has been done with the original libusb.> I just thought of something else that has changed since the last time I was trying this.... I am now using the "--with-pidpath=/var/run/ups" configuration parameter to change where everything keeps the pid files. I wasn't doing that before. Since that's mounted to tmpfs, is it possible that's getting unmounted before the shutdown command happens (and thus not finding the .pid file, it tries to start it instead)?You might be on to something, but if so, the race happens earlier than the "usbhid-ups -k" invocation. Because the "-k" flag is meant to be called at the end of the shutdown sequence, it doesn't assume /var is mounted, and consequently, it doesn't check for other PID files. However, if a driver happens to still be running, it could cause the "-k" option to report a busy error. https://github.com/networkupstools/nut/blob/master/drivers/main.c#L588 -- Charles Lepple clepple at gmail
I found something particularly strange while trying out different things: I started up upsdrvctl, upsd, and upsmon. I then stopped upsdrvctl, and tried starting the usbhid-ups driver a few times. Each time I executed the driver, it indicated an instance was already running, stopped it, and then started it again....which is what it should do. I then added -DDDD to the command....and then it failed, giving me the same "Can't claim USB" message. Why does adding the debug commands cause a problem? It seems like it would either be timing related (extra time taken by outputting debug messages) or the debug flags are actually affecting execution. -------------------------------------------------- linux-86h4:/usr/local/ups/bin # ./usbhid-ups -u root -a rtdups Network UPS Tools - Generic HID driver 0.39 (2.7.2.6_RTD) USB communication driver 0.32 Duplicate driver instance detected! Terminating other driver! Broadcast message from rtd at linux-86h4 (somewhere) (Wed Sep 16 11:33:10 2015): Communications with UPS rtdups at localhost lost Using subdriver: RTD UPS HID v1.0 Broadcast message from rtd at linux-86h4 (somewhere) (Wed Sep 16 11:33:20 2015): Communications with UPS rtdups at localhost established linux-86h4:/usr/local/ups/bin # ./usbhid-ups -u root -DDDD -a rtdups Network UPS Tools - Generic HID driver 0.39 (2.7.2.6_RTD) USB communication driver 0.32 0.000000 debug level is '4' 0.000457 upsdrv_initups... 0.004206 Checking device (0930/6545) (002/002) 0.008192 - VendorID: 0930 0.008226 - ProductID: 6545 0.008242 - Manufacturer: Kingston 0.008257 - Product: DT 101 G2 0.008274 - Serial Number: 00137297189CEB80F59301A9 0.008290 - Bus: 002 0.008305 Trying to match device 0.008326 Device does not match - skipping 0.008365 Checking device (1D6B/0002) (002/001) 0.008527 - VendorID: 1d6b 0.008547 - ProductID: 0002 0.008563 - Manufacturer: Linux 3.16.6-2-desktop ehci_hcd 0.008579 - Product: EHCI Host Controller 0.008594 - Serial Number: 0000:00:1d.7 0.008610 - Bus: 002 0.008625 Trying to match device 0.008642 Device does not match - skipping 0.008667 Checking device (1D6B/0001) (008/001) 0.029283 - VendorID: 1d6b 0.029391 - ProductID: 0001 0.029408 - Manufacturer: Linux 3.16.6-2-desktop uhci_hcd 0.029716 - Product: UHCI Host Controller 0.029734 - Serial Number: 0000:00:1d.2 0.029750 - Bus: 008 0.029766 Trying to match device 0.029788 Device does not match - skipping 0.029857 Checking device (1D6B/0001) (007/001) 0.050377 - VendorID: 1d6b 0.050403 - ProductID: 0001 0.050425 - Manufacturer: Linux 3.16.6-2-desktop uhci_hcd 0.050438 - Product: UHCI Host Controller 0.050452 - Serial Number: 0000:00:1d.1 0.050465 - Bus: 007 0.050478 Trying to match device 0.050496 Device does not match - skipping 0.050547 Checking device (1D6B/0001) (006/001) 0.071634 - VendorID: 1d6b 0.071652 - ProductID: 0001 0.071657 - Manufacturer: Linux 3.16.6-2-desktop uhci_hcd 0.071662 - Product: UHCI Host Controller 0.071668 - Serial Number: 0000:00:1d.0 0.071673 - Bus: 006 0.071677 Trying to match device 0.071687 Device does not match - skipping 0.071741 Checking device (2A37/5110) (001/005) 0.073249 - VendorID: 2a37 0.073262 - ProductID: 5110 0.073268 - Manufacturer: RTD Embedded Technologies, Inc. 0.073274 - Product: UPS25110 0.073279 - Serial Number: 123456789ABC 0.073285 - Bus: 001 0.073290 Trying to match device 0.073299 Device matches 0.073326 failed to claim USB device: Device or resource busy 0.073338 failed to detach kernel driver from USB device: No such file or directory 0.073347 failed to claim USB device: Device or resource busy 0.073360 failed to detach kernel driver from USB device: No such file or directory 0.073372 failed to claim USB device: Device or resource busy 0.073379 failed to detach kernel driver from USB device: No such file or directory 0.073386 failed to claim USB device: Device or resource busy 0.073393 failed to detach kernel driver from USB device: No such file or directory 0.073400 Can't claim USB device [2a37:5110]: No such file or directory ------------------------------------------ Rob Groner Software Engineer Level II RTD Embedded Technologies, Inc. ISO 9001 and AS9100 Certified Ph: +1 814-234-8087 www.rtd.com -----Original Message----- From: Charles Lepple [mailto:clepple at gmail.com] Sent: Tuesday, September 15, 2015 9:32 PM To: Rob Groner <rgroner at RTD.com> Cc: Roger Price <roger at rogerprice.org>; nut-upsuser Mailing List <nut-upsuser at lists.alioth.debian.org> Subject: Re: [Nut-upsuser] UPS/NUT with openSUSE 13.1 On Sep 15, 2015, at 5:12 PM, Rob Groner <rgroner at RTD.com> wrote:> > Charles, > > Trying to track down the source of the problem, I checked Yast to make sure I had at least 0.1.8 version for libusb. I saw this (attached photo). Is it then actually using ?compat instead of the ?real? libusb? And is that a problem?You're right, both the -compat and real libusb packages will use the same libusb-0.1.so* name. It's not necessarily a problem, but it does mean that there is different code between your driver and the kernel. Most of the NUT testing has been done with the original libusb.> I just thought of something else that has changed since the last time I was trying this.... I am now using the "--with-pidpath=/var/run/ups" configuration parameter to change where everything keeps the pid files. I wasn't doing that before. Since that's mounted to tmpfs, is it possible that's getting unmounted before the shutdown command happens (and thus not finding the .pid file, it tries to start it instead)?You might be on to something, but if so, the race happens earlier than the "usbhid-ups -k" invocation. Because the "-k" flag is meant to be called at the end of the shutdown sequence, it doesn't assume /var is mounted, and consequently, it doesn't check for other PID files. However, if a driver happens to still be running, it could cause the "-k" option to report a busy error. https://github.com/networkupstools/nut/blob/master/drivers/main.c#L588 -- Charles Lepple clepple at gmail
On Sep 15, 2015, at 9:31 PM, Charles Lepple <clepple at gmail.com> wrote:> >> Trying to track down the source of the problem, I checked Yast to make sure I had at least 0.1.8 version for libusb. I saw this (attached photo). Is it then actually using ?compat instead of the ?real? libusb? And is that a problem? > > You're right, both the -compat and real libusb packages will use the same libusb-0.1.so* name.I misspoke. The "real libusb" (0.1) and libusb-compat will both get linked with "-lusb". The package management system is free to implement that with symlinks to the actual files. The confusing part is that openSUSE seems to be adopting the 0.1.1x numbering scheme for libusb-compat so that the package looks newer (0.1.13) than the real libusb-0.1.12: https://build.opensuse.org/package/view_file/openSUSE:13.2/libusb-compat/libusb-compat.spec?expand=1 Note the changes mentioned in the return codes for usb_detach_kernel_driver_np(): https://build.opensuse.org/package/view_file/openSUSE:13.2/libusb-compat/libusb-compat.changes?expand=1 Those are the sort of edge cases that haven't been fully tested with NUT. It seems like the path from NUT driver through libusb to the kernel is relatively unchanged with libusb-compat, but that mapping the errors back to root cause will depend on the exact version of libusb-compat in use (and potentially, the kernel version as well). I would recommend retesting with an explicit "killall usbhid-ups" (and anything else necessary to stop NUT background services, otherwise it will pop back up) before switching debug flags on. If that fails to turn up anything conclusive, you might try to install libusb-0.1.12 from source in a separate directory, and explicitly point ./configure to that tree: <remove libusb-compat-devel> install from http://sourceforge.net/projects/libusb/files/libusb-0.1%20%28LEGACY%29/0.1.12/ .../libusb-0.1.12 $ ./configure --prefix=$HOME/local/libusb-0.1 && make && sudo make install .../nut $ ./configure --with-usb-include=$HOME/local/libusb-0.1/include --with-usb-libs=-L$HOME/local/libusb-0.1/lib ... (might need slight adjustments) After that, you can verify that the libusb line in "ldd /path/to/usbhid-ups" points to "$HOME/local/..." -- Charles Lepple clepple at gmail