[Nut-upsuser] UPS/NUT with openSUSE 13.1

Wed Sep 16 15:46:00 UTC 2015

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