On 5/13/2017 10:20 AM, Charles Lepple wrote: > On May 12, 2017, at 10:06 AM, Mike <[email protected]> wrote: >> >> >> OpenBSD 6.1/amd64 >> nut-2.7.4p0 (from OpenBSD package) >> UPS: Tripp-Lite OMNI1500LCDT >> >> I cannot get the driver for the UPS to load without error. >> >> Here are the commands, with the output, and the config files: >> >> ======================================================= >> # upsdrvctl start >> Network UPS Tools - UPS driver controller 2.7.4 >> Network UPS Tools - Generic HID driver 0.41 (2.7.4) >> USB communication driver 0.33 >> No matching HID UPS found - check permissions on /dev/ugen* and /dev/usb* >> Driver failed to start (exit status=1) >> > This seems to be different behavior than below. Did anything else change? > >> >> # ls -al /dev/usb* >> crw-rw---- 1 root wheel 61, 0 May 11 15:45 /dev/usb0 >> crw-rw---- 1 root wheel 61, 1 May 11 15:45 /dev/usb1 >> crw-rw---- 1 root wheel 61, 2 May 11 15:45 /dev/usb2 >> crw-rw---- 1 root wheel 61, 3 May 11 15:45 /dev/usb3 >> crw-rw---- 1 root wheel 61, 4 May 11 15:45 /dev/usb4 >> crw-rw---- 1 root wheel 61, 5 May 11 15:45 /dev/usb5 >> crw-rw---- 1 root wheel 61, 6 May 11 15:45 /dev/usb6 >> crw-rw---- 1 root wheel 61, 7 May 11 15:45 /dev/usb7 >> >> >> [/dev/ugen* has the same permissions as above] >> >> # grep _ups /etc/group >> wheel:*:0:root,_ups >> >> >> >> # upsdrvctl -D start >> Network UPS Tools - UPS driver controller 2.7.4 >> 0.000000 Starting UPS: usb >> Network UPS Tools - Generic HID driver 0.41 (2.7.4) >> USB communication driver 0.33 >> Using subdriver: TrippLite HID 0.82 >> libusb_get_interrupt: Function not implemented > > The last line is just a warning - usbhid-ups can use both interrupt requests > and EP0 control requests. The driver was probably running in the background, > per the "Duplicate driver instance" message below. >> >> >> # upsdrvctl -DD start >> Network UPS Tools - UPS driver controller 2.7.4 >> 0.000000 >> If you're not a NUT core developer, chances are that you're told to >> enable debugging >> to see why a driver isn't working for you. We're sorry for the >> confusion, but this is >> the 'upsdrvctl' wrapper, not the driver you're interested in. >> >> Below you'll find one or more lines starting with 'exec:' followed by an >> absolute >> path to the driver binary and some command line option. This is what the >> driver >> starts and you need to copy and paste that line and append the debug >> flags to that >> line (less the 'exec:' prefix). >> >> 0.000323 Starting UPS: usb >> 0.000360 1 remaining attempts >> 0.000378 exec: /usr/local/bin/usbhid-ups -a usb >> Network UPS Tools - Generic HID driver 0.41 (2.7.4) >> USB communication driver 0.33 >> Duplicate driver instance detected! Terminating other driver! >> [about a 20 second delay] >> Using subdriver: TrippLite HID 0.82 >> libusb_get_interrupt: Function not implemented >> >> >> >> # /usr/local/bin/usbhid-ups -a usb >> Network UPS Tools - Generic HID driver 0.41 (2.7.4) >> USB communication driver 0.33 >> Using subdriver: TrippLite HID 0.82 >> libusb_get_interrupt: Function not implemented > > The usbhid-ups command line is where you could add '-D' to increase debug > output. > >> If I run upsdrvctl with -D flags, it appears to loop. I can make >> available that extensive output, if needed. > > Per the message from upsdrvctl, the debug flags need to be passed directly to > the driver, not to upsdrvctl. > > What happens when you start "upsd" and run "upsc ups"? > > That said, we have had no end of trouble with Tripp-Lite 3016 protocol > devices. For instance: > > https://github.com/networkupstools/nut/pull/122 (SMART1500LCDT in this case, > but seems similar in many regards) > > I don't have a physical OpenBSD box to test with, but extrapolating from the > Linux devices I have tested against, you might see USB disconnect messages in > dmesg. While it could be argued that the NUT driver is doing something to > trigger these disconnections, I have seen them on Linux systems when NUT is > not loaded. > > We have been in contact with Tripp-Lite about this over the past few years, > and this issue is complicated by the fact that it seems to be > motherboard-dependent: older USB host controllers do not trigger the > disconnections. ARM boards such as the Raspberry Pi sometimes fare better, > but their USB controllers seem to be more flaky in the long term than > x86-based systems. > > Fortunately, the USB interface on these UPS models seems to be somewhat > isolated from the power control circuitry. The SMART1500LCDT powering my > primary desktop seems to handle brief power outages just fine, but I got > tired of dealing with the disconnect/reconnect messages, and stopped trying > to debug the NUT driver. > > My personal recommendation (and I do not speak for my employer, or > Tripp-Lite) is that if you need shutdown notifications to the OS, choose a > different UPS. (This UPS should be okay for filtering power to non-core > network infrastructure.) >
Thanks for the reply. I need to investigate this further. I found that the USB port on the PC I was using seemed to be a bit flaky. When I plugged the Tripp-Lite into another USB port on the same box, it worked a lot better. I'll have another PC to use sometime next week, and I'll get into it again. Until I get to the bottom of all this, I've put into use a CyberPower UPS. I should get around to posting the various data on it this weekend. Thanks again for the reply. _______________________________________________ Nut-upsuser mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
