[Nut-upsuser] TrippLite HID 0.82: libusb_get_interrupt: Function not implemented [3016]

[Mike]

On 5/13/2017 1:12 PM, Mike wrote:
> On 5/13/2017 10:20 AM, Charles Lepple wrote:
>> On May 12, 2017, at 10:06 AM, Mike <the.lists at mgm51.com> wrote:
[snip]
>>
>> 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.



OK, I had the chance to try this out on my new motherboard.

Again, here's my environment:
- OpenBSD 6.1/amd64 (running on a new SuperMicro motherboard)
- nut-2.7.4p0 (from OpenBSD package)
- UPS: Tripp-Lite OMNI1500LCDT


I see the Tripp-Lite UPS in the dmesg. If I unplug and plug the
Tripp-Lite USB cable back in to the PC, OpenBSD always sees the
disconnect, but most of the time does not see the subsequent connect.  I
need to reboot in order for OpenBSD to see the Tripp-Lite again.
However, at no time does NUT see the Tripp-Lite UPS.

This behavior with the Super Micro motherboard is different than what I
was seeing in my prior messages (last week?), when I was using a
10-year-old Dell home PC.  With that one, sometimes NUT would see the
Tripp-Lite, sometimes it wouldn't.  Sometimes OpenBSD would see the
reconnect, sometimes it wouldn't.

If I had to describe the behavior of the Tripp-Lite communications in
one word, I'd called it "non-deterministic."


So, now back to the SuperMicro motherboard...

I left the Tripp-Lite behind and moved on to a CyberPower UPS I have on
the shelf, a Cyber Power Systems EC750G.

I didn't need to change the NUT configuration as both use USB for comms.

So... using the Cyber Power Systems UPS...

No matter how many times I unplugged and plugged the Cyber Power USB
cable into the SuperMicro motherboard, OpenBSD always saw and
accommodated the changes that occurred.

And NUT always saw the Cyber Power Systems UPS.

If I had to use one word to describe the behavior of the Cyber Power
Systems communications with the Super Micro motherboard, I'd call it
"reliable."


The Super Micro motherboard is now in production, so I'm not really able
to do any further testing with it...