[Nut-upsuser] UPS Losing Connection

[Stuart D Gathman]

On Thu, 24 Sep 2020, Kirk Bocek wrote:

> On 9/23/2020 1:09 PM, Stuart D. Gathman wrote:
>>  I solved this problem a few years back.
>>
>>  https://github.com/sdgathman/trippfix
>>
>>  The short answer is USB is broken on the model (but the power management
>>  is excellent, handling switchover to generator power without a hitch).
>>
>>  The workaround is to do a usb port power off when the Tripplite USB
>>  hangs.  But hubs that actually implement this mandatory feature (must at
>>  least support powering all ports off) are getting hard to find. The USB
>>  chips implement it just fine. The hubs don't bother connecting the pins
>>  and just wire to +5V.
>>
>>  The good news is that with CentOS-8, the kernel automatically does the
>>  port power off, so you don't need my kludgey software fix when you go to
>>  8.  You still need an actual standard conforming USB hub however.
>>  If the port on your server isn't, you can buy an external hub
>>  like I did.
>> 
>> 
> Stuart, I haven't tried your program yet.
>
> However the UPS appears to have dropped off completely. lsusb no longer shows 
> the unit at all. So I physically unplugged and replugged it:
>
> #dmesg
> ...
> [252389.354190] hid-generic 0003:0557:2419.0002: usb_submit_urb(ctrl) failed: 
> -19
> [252389.403568] xhci_hcd 0000:00:14.0: USB bus 3 deregistered
> [252389.405712] xhci_hcd 0000:00:14.0: xHCI Host Controller
> [252389.407225] xhci_hcd 0000:00:14.0: new USB bus registered, assigned bus 
> number 3
> [252405.901391] xhci_hcd 0000:00:14.0: can't setup: -110
> [252405.902631] xhci_hcd 0000:00:14.0: USB bus 3 deregistered
> [252405.903033] xhci_hcd 0000:00:14.0: init 0000:00:14.0 fail, -110
> [252405.903038] xhci_hcd: probe of 0000:00:14.0 failed with error -110
>
> And it's still not there:
>
> $lsusb
> Bus 002 Device 002: ID 8087:8002 Intel Corp.
> Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> Bus 001 Device 002: ID 8087:800a Intel Corp.
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
>
>
> So is this a faulty Tripplite that needs to be returned?

No.  That is the symptom I got.  It is faulty - but they are all faulty.
You have to do that several times.  My scripting does that by powering 
off the port and back on until the unit appears.  A real kludge.
Newer kernels do that automatically.

Here is CentOS-8 handling a Triplite disconnect:

[2452246.624432] usb 2-1.4-port4: disabled by hub (EMI?), re-enabling...
[2452246.624672] usb 2-1.4.4: USB disconnect, device number 26
[2452247.585157] usb 2-1.4-port4: Cannot enable. Maybe the USB cable is
bad?
[2452248.441266] usb 2-1.4-port4: Cannot enable. Maybe the USB cable is
bad?
[2452248.441460] usb 2-1.4-port4: attempt power cycle
[2452249.460988] usb 2-1.4.4: new low-speed USB device number 29 using
ehci-pci
[2452249.508514] usb 2-1.4.4: New USB device found, idVendor=09ae,
idProduct=3016, bcdDevice= 0.02
[2452249.508519] usb 2-1.4.4: New USB device strings: Mfr=3, Product=1,
SerialNumber=5
[2452249.508522] usb 2-1.4.4: Product: TRIPP LITE UPS
[2452249.508525] usb 2-1.4.4: Manufacturer: Tripp Lite
...

Notice the "attempt power cycle".  That only works on standard
conforming hubs, which are sadly hard to find.