[Nut-upsuser] OMNIVS1500XL and FreeBSD
Charles Sprickman
spork at bway.net
Mon Mar 5 03:39:36 CET 2007
On Sun, 4 Mar 2007, Charles Lepple wrote:
> On 3/3/07, Charles Sprickman <spork at bway.net> wrote:
>> I'm running FreeBSD 6.2 with Nut 2.0.5 installed from ports...
>>
>> I have a TrippLite OmniVS1500XL plugged in, but I'm having little luck with
>> the
>> tripplite_usb module. I have already built and booted a new kernel with
>> UHID
>> disabled so that libusb can grab /dev/ugen0.
>
> Sounds good so far.
Yeah, at this point I figured it's two years or so since I last tried
this, so maybe it'll work. :)
>> At first I was able to get the following out of the driver:
>>
>> # USB_DEBUG=5 /usr/local/libexec/nut/tripplite_usb -u root -DDDDD auto
>>
>> Network UPS Tools - Tripp Lite OMNIVS and SMARTPRO driver 0.7 (2.0.5)
> [...]
>> send_cmd(msg_len=3, type='W')
>> send_cmd: sending 3a 57 00 a8 0d 00 00 00 '.W......'
>> usb_control_msg: 33 9 768 0 0xbfbfe960 8 4000
>> send_cmd: received 57 00 0d 00 00 00 00 00 'W.......' (OK)
>
> looks like the watchdog command works.
>
>> send_cmd(msg_len=2, type='
>> send_cmd: sending 3a 00 ff 0d 00 00 00 00 '........'
>> usb_control_msg: 33 9 768 0 0xbfbfe960 8 4000
>> usb_control_msg: 33 9 768 0 0xbfbfe960 8 4000
>> usb_control_msg: 33 9 768 0 0xbfbfe960 8 4000
>> send_cmd: received 00 20 01 58 58 58 58 0d '...XXXX.' (OK)
>> send_cmd: send_try = 3, recv_try = 1
>
> I'm a little concerned that it took three tries to send the command.
Is this the point where we think about it being a FreeBSD issue instead of
the UPS?
>> Using OMNIVS 2001 protocol (2001)
>> send_cmd(msg_len=2, type='S')
>> send_cmd: sending 3a 53 ac 0d 00 00 00 00 '.S......'
>> usb_control_msg: 33 9 768 0 0xbfbfe960 8 4000
>> usb_control_msg: 33 9 768 0 0xbfbfe960 8 4000
>> usb_control_msg: 33 9 768 0 0xbfbfe960 8 4000
>> send_cmd: received 00 20 01 58 58 58 58 0d '...XXXX.' (bad)
>> send_cmd: send_try = 3, recv_try = 3
>>
>> Could not retrieve status ... is this an OMNIVS model?
>> [root at miko /home/spork]#
>>
>> Any ideas?
>
> There are some #defines that you can tweak at the beginning of
> drivers/tripplite_usb.c.
I'm not very handy with programming, but what I did was to turn up any
timeouts and increase retries.
> I would definitely not give up hope yet, though - I think it's just
> some weirdness in the FreeBSD USB stack, interacting with the
> empirical nature of this driver (the timeouts are just guesses based
> on observed response times).
Here's some snippets of output with my little changes. It's abbreviated
as it really goes on for some time:
# USB_DEBUG=5 ./tripplite_usb -u root -DDDDD -a colo1
usb_set_debug: Setting debugging level to 5 (on)
1
usb_os_find_busses: Found /dev/usb0 USB_D./tripplite_usb -u root -DDDDD -a
colo
usb_os_find_busses: Found /dev/usb1
usb_os_find_busses: Found /dev/usb2
usb_os_find_busses: Found /dev/usb3
usb_os_find_devices: Found /dev/ugen0 on /dev/usb1
usb_control_msg: 128 6 512 0 0xbfbfd8e8 8 1000
usb_control_msg: 128 6 512 0 0x80593c0 34 1000
skipped 1 class/vendor specific interface descriptors
Checking device (09AE/0001) (/dev/usb1//dev/ugen0)
usb_control_msg: 128 6 768 0 0xbfbfd840 255 1000
usb_control_msg: 128 6 769 1033 0xbfbfd840 255 1000
usb_control_msg: 128 6 768 0 0xbfbfd840 255 1000
usb_control_msg: 128 6 770 1033 0xbfbfd840 255 1000
- VendorID: 09ae
- ProductID: 0001
- Manufacturer: TRIPP LITE
- Product: TRIPP LITE OMNIVS1500XL
- Serial Number: unknown
- Bus: /dev/usb1
Trying to match device
Device matches
-->>USB error: could not set alt intf 0/0: Invalid argument
usb_control_msg: 129 6 8448 0 0xbfbfda90 9 4000
HID descriptor, method 1: (9 bytes) => 09 21 00 01 00 01 22 34 00
i=0, extra[i]=09, extra[i+1]=21
HID descriptor, method 2: (9 bytes) => 09 21 00 01 00 01 22 34 00
HID descriptor retrieved (Reportlen = 52)
usb_control_msg: 129 6 8704 0 0xbfbfdaf0 52 4000
Report descriptor retrieved (Reportlen = 52)
Found HID device
Report Descriptor size = 52
Report Descriptor: (52 bytes) => 06 a0 ff 09 01 a1 01 09 02 a1 00 06 a1 ff
09 03 09 04 15 80 25 7f 35 00 45 ff 75 08 95 08 81 02 09 05 09 06 15 80 25
7f 35 00 45 ff 75 08 95 08 91 02 c0 c0
Detected a UPS: TRIPP LITE/TRIPP LITE OMNIVS1500XL
send_cmd(msg_len=3, type='W')
send_cmd: sending 3a 57 00 a8 0d 00 00 00 '.W......'
usb_control_msg: 33 9 768 0 0xbfbfe950 8 4000
send_cmd: received 57 00 0d 00 00 00 00 00 'W.......' (OK)
send_cmd(msg_len=2, type='
send_cmd: sending 3a 00 ff 0d 00 00 00 00 '........'
usb_control_msg: 33 9 768 0 0xbfbfe950 8 4000
usb_control_msg: 33 9 768 0 0xbfbfe950 8 4000
send_cmd: received 00 20 01 58 58 58 58 0d '...XXXX.' (OK)
Using OMNIVS 2001 protocol (2001)
send_cmd(msg_len=2, type='S')
send_cmd: sending 3a 53 ac 0d 00 00 00 00 '.S......'
usb_control_msg: 33 9 768 0 0xbfbfe950 8 4000
usb_control_msg: 33 9 768 0 0xbfbfe950 8 4000
usb_control_msg: 33 9 768 0 0xbfbfe950 8 4000
usb_control_msg: 33 9 768 0 0xbfbfe950 8 4000
usb_control_msg: 33 9 768 0 0xbfbfe950 8 4000
send_cmd: received 53 31 34 30 30 00 30 0d 'S1400.0.' (OK)
send_cmd: send_try = 5, recv_try = 1
send_cmd(msg_len=2, type='P')
send_cmd: sending 3a 50 af 0d 00 00 00 00 '.P......'
usb_control_msg: 33 9 768 0 0xbfbfe950 8 4000
usb_control_msg: 33 9 768 0 0xbfbfe950 8 4000
usb_control_msg: 33 9 768 0 0xbfbfe950 8 4000
usb_control_msg: 33 9 768 0 0xbfbfe950 8 4000
usb_control_msg: 33 9 768 0 0xbfbfe950 8 4000
send_cmd: received 53 31 34 30 30 00 30 0d 'S1400.0.' (bad)
send_cmd: send_try = 5, recv_try = 5
send_cmd(msg_len=2, type='F')
send_cmd: sending 3a 46 b9 0d 00 00 00 00 '.F......'
usb_control_msg: 33 9 768 0 0xbfbfe950 8 4000
usb_control_msg: 33 9 768 0 0xbfbfe950 8 4000
usb_control_msg: 33 9 768 0 0xbfbfe950 8 4000
usb_control_msg: 33 9 768 0 0xbfbfe950 8 4000
usb_control_msg: 33 9 768 0 0xbfbfe950 8 4000
send_cmd: received 53 31 34 30 30 00 30 0d 'S1400.0.' (bad)
send_cmd: send_try = 5, recv_try = 5
send_cmd(msg_len=2, type='V')
send_cmd: sending 3a 56 a9 0d 00 00 00 00 '.V......'
usb_control_msg: 33 9 768 0 0xbfbfe950 8 4000
usb_control_msg: 33 9 768 0 0xbfbfe950 8 4000
usb_control_msg: 33 9 768 0 0xbfbfe950 8 4000
usb_control_msg: 33 9 768 0 0xbfbfe950 8 4000
usb_control_msg: 33 9 768 0 0xbfbfe950 8 4000
send_cmd: received 50 30 31 35 30 30 58 0d 'P01500X.' (bad)
send_cmd: send_try = 5, recv_try = 5
Attached to Tripp Lite OMNIVS1500XL
send_cmd(msg_len=2, type='S')
send_cmd: sending 3a 53 ac 0d 00 00 00 00 '.S......'
usb_control_msg: 33 9 768 0 0xbfbfea80 8 4000
usb_control_msg: 33 9 768 0 0xbfbfea80 8 4000
usb_control_msg: 33 9 768 0 0xbfbfea80 8 4000
usb_control_msg: 33 9 768 0 0xbfbfea80 8 4000
usb_control_msg: 33 9 768 0 0xbfbfea80 8 4000
send_cmd: received 50 30 31 35 30 30 58 0d 'P01500X.' (bad)
send_cmd: send_try = 5, recv_try = 5
Error reading S value: Unknown error 0
dstate_init: sock /var/db/nut/colo1 open on fd 6
send_cmd(msg_len=2, type='S')
send_cmd: sending 3a 53 ac 0d 00 00 00 00 '.S......'
usb_control_msg: 33 9 768 0 0xbfbfea80 8 4000
usb_control_msg: 33 9 768 0 0xbfbfea80 8 4000
usb_control_msg: 33 9 768 0 0xbfbfea80 8 4000
usb_control_msg: 33 9 768 0 0xbfbfea80 8 4000
usb_control_msg: 33 9 768 0 0xbfbfea80 8 4000
send_cmd: received 46 32 31 35 37 20 41 0d 'F2157.A.' (bad)
send_cmd: send_try = 5, recv_try = 5
Error reading S value: Unknown error 0
send_cmd(msg_len=2, type='S')
send_cmd: sending 3a 53 ac 0d 00 00 00 00 '.S......'
usb_control_msg: 33 9 768 0 0xbfbfea80 8 4000
usb_control_msg: 33 9 768 0 0xbfbfea80 8 4000
usb_control_msg: 33 9 768 0 0xbfbfea80 8 4000
usb_control_msg: 33 9 768 0 0xbfbfea80 8 4000
usb_control_msg: 33 9 768 0 0xbfbfea80 8 4000
send_cmd: received 46 32 31 35 37 20 41 0d 'F2157.A.' (bad)
send_cmd: send_try = 5, recv_try = 5
And so on...
Notice that when I bumped retries up to 5 it now gets the info on the 5th
try rather than the third? Just a shot in the dark, but maybe something
happens after the driver sends it's last request (something gets flushed,
something lets go of some status line???) that allows a reply?
> Also, someone submitted the patch for the 2001 protocol after some
> experimentation, so I assume that they got status working at least
> partially.
I'd love to find that person. :)
If there's some FreeBSD issue here, what's the best way to attack this? I
can't just wander onto -hackers and say "some guy says your software is
broken"...
Thanks,
Charles
> --
> - Charles Lepple
>
More information about the Nut-upsuser
mailing list