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?
Update from my end: I found the old thread where I posted a possible resolution for a similar issue on CentOS 7.6 with the same protocol (2012): https://alioth-lists.debian.net/pipermail/nut-upsuser/2019-June/011451.html https://alioth-lists.debian.net/pipermail/nut-upsdev/2019-June/007440.html Some of my initial steps were probably unnecessary, but through a combination of configuration tweaks and udev rules, the drops seemed to go away. Of course, if the USB port is not responding at all, that is a separate issue (is there another computer/cable to verify that with?). You should contact tech support if that ends up being the case: https://www.tripplite.com/support/help (I'm no longer on the tech support team so I couldn't help directly with an RMA if needed) Thank you, David Zomaya Tripp Lite From: Nut-upsuser <nut-upsuser-bounces+david_zomaya=tripplite.com at alioth-lists.debian.net> on behalf of Kirk Bocek <t004 at kbocek.com> Sent: Thursday, September 24, 2020 10:44 AM To: Stuart D. Gathman Cc: nut-upsuser at lists.alioth.debian.org Subject: [EXTERNAL] Re: [Nut-upsuser] UPS Losing Connection This is an EXTERNAL email. Please take a moment and think before clicking any links or opening any attachments from this email. If suspicious, please forward to ishelpdesk at tripplite.com for review. ______________________________________________________________________ On 9/23/2020 1:09 PM, Stuart D. Gathman wrote:> I solved this problem a few years back. > > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_sdgathman_trippfix&d=DwIGaQ&c=f9s1WCuF-N6cmD_YaZ7gBg&r=lhr3k4au5dVQgHY_iS-v_t9g8PHVkn8Px_wyaupZGfQ&m=ieNVDc2LsEIgAsSw5PmvtF9Ea-8ztJJmucllLxQBdYg&s=gz_sAnNNKkp5OBQ7LqrSNehqXseO3LOJjeGIKs5ccxM&e> > 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? _______________________________________________ Nut-upsuser mailing list Nut-upsuser at alioth-lists.debian.net https://urldefense.proofpoint.com/v2/url?u=https-3A__alioth-2Dlists.debian.net_cgi-2Dbin_mailman_listinfo_nut-2Dupsuser&d=DwIGaQ&c=f9s1WCuF-N6cmD_YaZ7gBg&r=lhr3k4au5dVQgHY_iS-v_t9g8PHVkn8Px_wyaupZGfQ&m=ieNVDc2LsEIgAsSw5PmvtF9Ea-8ztJJmucllLxQBdYg&s=OuS899U4p9klt5o9RCgdR25Af9i4mZZTEjF5RYx5xzk&e ________________________________ This message is for the addressee's use only. It may contain confidential information. If you receive this message in error, please delete it and notify the sender. Tripp Lite disclaims all warranties and liabilities, and assumes no responsibility for viruses which may infect an email sent to you from Tripp Lite and which damage your electronic systems or information. It is your responsibility to maintain virus detection systems to prevent damage to your electronic systems and information.
On 9/24/2020 9:05 AM, David Zomaya wrote:> Update from my end: > > I found the old thread where I posted a possible resolution for a similar issue on CentOS 7.6 with the same protocol (2012): > https://alioth-lists.debian.net/pipermail/nut-upsuser/2019-June/011451.html > https://alioth-lists.debian.net/pipermail/nut-upsdev/2019-June/007440.html > > Some of my initial steps were probably unnecessary, but through a combination of configuration tweaks and udev rules, the drops seemed to go away. > > Of course, if the USB port is not responding at all, that is a separate issue (is there another computer/cable to verify that with?). You should contact tech support if that ends up being the case: > https://www.tripplite.com/support/help > > (I'm no longer on the tech support team so I couldn't help directly with an RMA if needed) > > > Thank you, > David Zomaya > Tripp Lite >I plugged the USB into another host and nothing. Not in lsusb output. No hotplug messages in the ring buffer. So is this a busted unit? Is there anyway to reset the USB on the UPC without power cycling everything attached to it?
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.