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@linux-86h4 (somewhere) (Wed Sep 16 11:33:10 2015):  
                                                                               
Communications with UPS rtdups@localhost lost                                  
                                                                               
Using subdriver: RTD UPS HID v1.0
                                                                               
Broadcast message from rtd@linux-86h4 (somewhere) (Wed Sep 16 11:33:20 2015):  
                                                                               
Communications with UPS rtdups@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:clep...@gmail.com] 
Sent: Tuesday, September 15, 2015 9:32 PM
To: Rob Groner <rgro...@rtd.com>
Cc: Roger Price <ro...@rogerprice.org>; nut-upsuser Mailing List 
<nut-upsuser@lists.alioth.debian.org>
Subject: Re: [Nut-upsuser] UPS/NUT with openSUSE 13.1

On Sep 15, 2015, at 5:12 PM, Rob Groner <rgro...@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@gmail



_______________________________________________
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Reply via email to