search for: constantlly

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

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

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 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

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

Hey, was wondering if I could get a quick sanity check. We have a SmartUPS 1500 RM2U which we have connected to a box via USB. It seems like every 40-45 seconds it becomes disconnected and reconnected. Though this only happens when we have NUT enabled, otherwise it's fine. When it is disconnecting and reconnecting running lsusb doesn't show it disconnecting. After having it sit like that

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

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

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

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