similar to: Tripp-Lite USB constantlly disconnecting.

Charles, So I installed a minimal CentOS 6.5 installation on the Fedora box this morning and I got the same issue. Below are the kernel versions used. CentOS 6.5 Minimal - [root at nemo tmp]# uname -a Linux nemo 2.6.32-431.el6.x86_64 #1 SMP Fri Nov 22 03:15:09 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux [root at nemo tmp]# rpm -qa | grep nut nut-2.6.5-2.el6.x86_64 nut-client-2.6.5-2.el6.x86_64

Some of my messages never went through since I hit a message size limit. I'm resending them in the hopes they are under the limit. Charles, The lsusb command did not trigger a disconnect. The output of that command is below. I ran "usbhid-ups -a upsunit -DDD &> output.log" and I have attached the /var/log/messages and output.log to this email. Before running this test

I am experiencing the same kind of disconnects, stale data on Eaton brand UPS (Nova AVR). It keeps doing it probably due to Windows to detect it as a new hardware, until Eaton software is installed. With Eaton Linux IPP http://pqsoftware.eaton.com/explore/eng/ipp/default.htm?lang=en this does not happen. Think what? It disables it somehow. But as soon as you remove this proprietary driver, its

Charles, > What is the new behavior? The CentOS minimal install had different print statements and a broadcast message whenever the UPS was disconnected. The broadcast isn't really important. Below are the differences I pasted though I'm not sure if they are important, I just noticed they were different. Particularly the bolded parts which I think you alluded to in your email about

Soon as I get back to that computer I will let you know which kernel version. Both were just recently installed, Fedora was installed specifically for this actually, though updates have been applied. I've tried it with other USB ports already across 5 different machines. I've also swapped out the USB cable for another one that I knew worked fine. I'll see what I can do about

On Sep 22, 2014, at 11:14 AM, Shade Alabsa <shade34321 at gmail.com> wrote: > These machines are exact replicas of each other and are fairly old and have a Core 2 Duo E8400 CPU in them. Is there anything else you need or anything I can do to help fix this? Thanks! Also, Barry Skrypnyk mentioned that Fedora was one of the Linux distributions that Tripp Lite claims to support. I recommend

On Sep 19, 2014, at 7:48 PM, Shade Alabsa <shade34321 at gmail.com> wrote: > So I was wondering does NUT do anything which would cause the USB to disconnect? Not intentionally, no. The reconnection code is meant to clean up after these disconnection events, but it is something that isn't expected all that frequently. > I didn't think so and I couldn't find anything yet

Charles, > If you run lsusb several times, does it still work? The exact output of lsusb isn't as important as whether anything gets logged by the kernel. Running lsusb shouldn't cause any extra kernel messages such as the disconnection/reconnection messages shown here: Running lsusb seveeral times works just fine and no disconnects are observed. > This

On Sep 29, 2014, at 12:50 PM, Shade Alabsa <shade34321 at gmail.com> wrote: > The lsusb command did not trigger a disconnect. The output of that > command is below. If you run lsusb several times, does it still work? The exact output of lsusb isn't as important as whether anything gets logged by the kernel. Running lsusb shouldn't cause any extra kernel messages such as

All, We think we found something that is causing the problem but as of right now we are unsure as to why it might be causing the issue. Recently I had to restart testing this to figure it out and for some odd reason I wasn't able to reproduce it with any system but our own custom system. I then noticed that in ups.conf I did not set the pollinterval, we normally set it to 15, so I set it to

I have just compiled and installed nut-2.4.1 and I get the following errors when I try it: There is no difference if I run it as root or normal user. Any help would be appreciated. # usbhid-ups -DDD -a SMART1000LCD Network UPS Tools - Generic HID driver 0.34 (2.4.1) USB communication driver 0.31 debug level is '3' upsdrv_initups... Checking device (1D6B/0002) (001/001) libusb

Updates on this: 1) Making progress in the related Dev list thread here: https://alioth-lists.debian.net/pipermail/nut-upsdev/2019-June/007440.html I’ll keep that thread up to date with progress as I go. But if there are specific things it would make sense to test here, just let me know. Otherwise, I figure reducing redundancy makes sense? 2) I tried disabling usbcore.autosuspend, but

To try and work through the initial drops, I repeated the previous steps that worked on the physical machine on the CentOS 7.6 virtual machine. The drops continued to occur, but it seems that the driver always reconnects. My initial inclination is to work through and see at what point I get the drops to stop, and I think I will do that next (inputs welcome). From a standpoint of “how much does

On Mon, Jun 17, 2019 at 6:10 PM David Zomaya <David_Zomaya at tripplite.com> wrote: > Hi Network UPS Tools Support, > > > > I’m not sure if this is a question for the “user group” or the developer > group”. > > > > My name is David Zomaya and I work at Tripp Lite in our technical support > department. Copied on this email are Eric Cobb from our Product

Thought I'd follow up in case someone else runs into this issue. In the end what worked for me was tweaking the udev rules. I have had no USB disconnects or stale data warnings so far. I only used one rule for my UPS: # /etc/udev/rules.d/62-nut-usbups.rules SUBSYSTEM!="usb", GOTO="nut-usbups_rules_end" # TrippLite # e.g. TrippLite SMART1500LCD - usbhid-ups

Hi Greg, I haven’t but I will give that a shot later this week and advise. Thanks for the tip. Thank you, David Zomaya Technical Support [cid:image007.png at 01D525AF.B38D63F0] 1111 W. 35th Street | Chicago, IL 60609 USA 773.869.1156 | david_zomaya at tripplite.com [cid:image008.png at 01D525AF.B38D63F0]<http://www.tripplite.com/> From: Nut-upsuser

Charles, We did notice that there were two categories. Is there a way if we could determine if it is colliding? We do have a USB analyzer so I'll see if that can be used to determine if the UPS is disconnecting due to inactivity on the bus. Thanks! Shade On Tue, Nov 18, 2014 at 8:40 PM, Charles Lepple <clepple at gmail.com> wrote: > On Nov 18, 2014, at 6:28 PM, Shade Alabsa

On Nov 18, 2014, at 6:28 PM, Shade Alabsa <shade34321 at gmail.com> wrote: > I then noticed that in ups.conf I did not set the pollinterval, we normally set it to 15, so I set it to test on a RHEL 6.6 machine which caused this issue to happen again. On our own custom system we took the poll interval out and prelim testing doesn't showing the repeated disconnects/reconnects. I started

I bought this UPS to use with NUT. I've used Belkin, APC, CyberPower, Best, Powerware upses with NUT on dozens of servers beginning with RHEL3. http://www.amazon.com/Tripp-Lite-Display-Protection-SMART1500LCDT/dp/B009TZTGWK Since this was advertised as USB HID, I didn't expect any problems. Bad idea (should have gotten the Cyberware with somewhat less runtime). Initially, it seems to

I'm trying to get a CyberPower PP1100 working with NUT on a Fedora 16 system and not having much luck. Kernel: 3.4.4-4.fc16.x86_64 #1 SMP Thu Jul 5 20:01:38 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux NUT (installed from Fedora RPM): nut-client-2.6.4-1.fc16.x86_64 nut-2.6.4-1.fc16.x86_64 libusb: libusb-devel-0.1.3-9.fc16.x86_64 libusb1-1.0.9-0.6.rc1.fc16.x86_64