[Nut-upsuser] TrippLite/Compiling on FreeBSD

[Charles Sprickman]

On Mon, 26 Sep 2005, Charles Lepple wrote:

> I don't have first-hand experience with libusb in *BSD, but from what
> I can gather, the uhid driver can block libusb access to HID-class
> devices. (I wouldn't be surprised; this happens in OS X, and to a
> lesser extent, in Linux as well.)

OK, I think I'm getting somewhere now...  I built a kernel with no UHID 
device and at least now I can get some more verbose info out of 
tripplite_usb:

root at miko[/usr/local/src/nut/drivers]# ./tripplite_usb  -u root -DDDDD 
auto
Network UPS Tools - Tripp Lite OMNIVS and SMARTPRO driver 0.5 (2.1.0)
Warning: This is an experimental driver.
Some features may not function correctly.

debug level is '5'
Opening new device (09AE/0001)
Found 0x9ae
- Unable to fetch manufacturer string
-        Unable to fetch product string
- No serial number string
HID descriptor retrieved (Reportlen =    52)
Report descriptor retrieved (Reportlen = 52)
found 1 (52)
Report Descriptor size = 52
Report Descriptor: (200 bytes) => 06 A0 FF 09 01 A1 01 09 02 A1 00 06 A1 
FF 09 03
Detected an UPS: Unknown vendor (0x09ae)/Unknown product (0x0001)
Looking up ffa00001
Looking up ffa00002
Looking up ffa10004
entering lookup_path()
parsing ffa00001
Looking up ffa00001
ffa00001 wasn't found
Path: ffa00001.ffa00002.ffa10004, Type: Input
Looking up ffa00001
Looking up ffa00002
Looking up 00000000
Looking up ffa00001
Looking up ffa00002
Looking up 00000000
Looking up ffa00001
Looking up ffa00002
Looking up 00000000
Looking up ffa00001
Looking up ffa00002
Looking up 00000000
Looking up ffa00001
Looking up ffa00002
Looking up 00000000
Looking up ffa00001
Looking up ffa00002
Looking up 00000000
Looking up ffa00001
Looking up ffa00002
Looking up ffa10005
entering lookup_path()
parsing ffa00001
Looking up ffa00001
ffa00001 wasn't found
Path: ffa00001.ffa00002.ffa10005, Type: Output
Looking up ffa00001
Looking up ffa00002
Looking up ffa10006
entering lookup_path()
parsing ffa00001
Looking up ffa00001
ffa00001 wasn't found
Path: ffa00001.ffa00002.ffa10006, Type: Output
Looking up ffa00001
Looking up ffa00002
Looking up 00000000
Looking up ffa00001
Looking up ffa00002
Looking up 00000000
Looking up ffa00001
Looking up ffa00002
Looking up 00000000
Looking up ffa00001
Looking up ffa00002
Looking up 00000000
Looking up ffa00001
Looking up ffa00002
Looking up 00000000
Looking up ffa00001
Looking up ffa00002
Looking up 00000000
send_cmd(msg_len=3, type='W')
send_cmd: sending  3a 57 00 a8 0d 00 00 00 '.W......'
libusb_get_interrupt() returned -6 instead of 8
libusb_get_interrupt() returned -6 instead of 8
libusb_get_interrupt() returned -6 instead of 8
libusb_get_interrupt() returned -6 instead of 8
libusb_get_interrupt() returned -6 instead of 8
libusb_get_interrupt() returned -6 instead of 8
libusb_get_interrupt() returned -6 instead of 8
libusb_get_interrupt() returned -6 instead of 8
libusb_get_interrupt() returned -6 instead of 8
send_cmd: send_try = 3, recv_try = 3

Could not reset watchdog. Please send model information to nut-upsdev 
mailing list
send_cmd(msg_len=2, type='
send_cmd: sending  3a 00 ff 0d 00 00 00 00 '........'
libusb_get_interrupt() returned -6 instead of 8
libusb_get_interrupt() returned -6 instead of 8
libusb_get_interrupt() returned -6 instead of 8
libusb_get_interrupt() returned -6 instead of 8
libusb_get_interrupt() returned -6 instead of 8
libusb_get_interrupt() returned -6 instead of 8
libusb_get_interrupt() returned -6 instead of 8
libusb_get_interrupt() returned -6 instead of 8
libusb_get_interrupt() returned -6 instead of 8
send_cmd: send_try = 3, recv_try = 3

Error reading protocol

Another note, without the "-u root" switch, I do not get any lengthy 
output...

Now you mentioned libusb debug levels before and when I add that, I get 
even more stuff.  I'll snip this one since it's really long:

usb_set_debug: Setting debugging level to 3 (on)
usb_os_find_busses: Found /dev/usb0
usb_os_find_devices: Found /dev/ugen0 on /dev/usb0
usb_control_msg: 128 6 512 0 0xbfbff878 8 1000
usb_control_msg: 128 6 512 0 0x805e080 34 1000
skipped 1 class/vendor specific interface descriptors
USB error: could not set alt intf 0/0: Invalid argument
usb_control_msg: 128 6 768 0 0xbfbff7c0 255 1000
USB error: error sending control message: Input/output error
usb_control_msg: 128 6 768 0 0xbfbff7c0 255 1000
USB error: error sending control message: Input/output error
usb_control_msg: 129 6 8448 0 0xbfbff9fc 9 4000
usb_control_msg: 129 6 8704 0 0x8056360 52 4000
Network UPS Tools - Tripp Lite OMNIVS and SMARTPRO driver 0.5 (2.1.0)
Warning: This is an experimental driver.
Some features may not function correctly.

Detected an UPS: Unknown vendor (0x09ae)/Unknown product (0x0001)

usb_control_msg: 33 9 768 0 0xbfbff8d8 8 4000
USB error: can't open /dev/ugen0.1 for bulk read: Device not configured
usb_interrupt_read: got negative open file descriptor for endpoint 1
libusb_get_interrupt() returned -6 instead of 8
USB error: can't open /dev/ugen0.1 for bulk read: Device not configured
usb_interrupt_read: got negative open file descriptor for endpoint 1
libusb_get_interrupt() returned -6 instead of 8

So this looks like a libusb issue.  I suppose I should head on over to the 
libusb list.  Does anyone have some tips for me on what I'm actually 
asking for?  I can give them these errors, tell them I'm using NUT... but 
I'm not really sure just what libusb *does*...

> There is a thread on the libusb list now (also referring to 0.1.10a):
>
> http://sourceforge.net/mailarchive/forum.php?thread_id=8308313&forum_id=5425
>
> but nothing conclusive has been posted.

Just looked and it seems like they're going somewhere with that.  I'm 
going to try those patches...

Thanks again,

Charles

> --
> - Charles Lepple
>