<div dir="ltr">All,<div> 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 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 playing more with this pollinterval and noticed that up to 14, exclusive, it seems to be fine. At 14 it happens but the messages are really spread out, I don't have an exact time delta for this. Anything over 15 displays the same symptoms just faster, 15 is roughly every 40-45 seconds and 20 is about a minute in between. We are still running the same version of everything pasted before so nut is 2.6.5-2 and the kernel is <span style="font-family:arial,sans-serif;font-size:13px">2.6.32-431.23.3.el6.x86_64. </span></div><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">I tried looking through the code but I haven't found anything that would cause these disconnects, I do see where it tries to reconnect though. Does anybody else have any other ideas about this? </span></div><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">Thanks!</span></div><div><span style="font-family:arial,sans-serif;font-size:13px">Shade Alabsa</span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 30, 2014 at 8:33 AM, Shade Alabsa <span dir="ltr"><<a href="mailto:shade34321@gmail.com" target="_blank">shade34321@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Charles,<br>
<span class=""><br>
> If you run lsusb several times, does it still work? The exact<br>
output of lsusb isn't as important as whether anything gets logged by<br>
the kernel. Running lsusb shouldn't cause any extra kernel messages<br>
such as the disconnection/reconnection messages shown here:<br>
<br>
</span> Running lsusb seveeral times works just fine and no disconnects<br>
are observed.<br>
<span class=""><br>
> This doesn't seem to match the source code, which tries to claim<br>
the interface up to three times, and if it doesn't work, it exits with<br>
a fatal error. Your logs show the same PID for usbhid-ups, so it<br>
apparently didn't exit. I am wondering if I am looking at the same<br>
code as what is built on your system. Do you have the exact version<br>
for the RPM files, or better yet, the corresponding SRPMs?<br>
<br>
</span> For this testing we actually just have whatever comes installed<br>
via yum on CentOS 6.5 in the EPEL I believe. Throughout this process I<br>
can successfully run upsc to obtain the UPS system for a while,<br>
roughly 24 hours before it starts reporting as stale and is no longer<br>
accessible. Maybe I forgot to mention that, if so I'm sorry. Below is<br>
the output of yum as I'm installing it from yum.<br>
<br>
===================================================================================================================<br>
Package Arch Version<br>
Repository Size<br>
===================================================================================================================<br>
Installing:<br>
nut x86_64 2.6.5-2.el6<br>
epel 1.2 M<br>
nut-client x86_64 2.6.5-2.el6<br>
epel 121 k<br>
<br>
<br>
Thanks for all of your help!<br>
<span class="HOEnZb"><font color="#888888"><br>
Shade<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Mon, Sep 29, 2014 at 10:26 PM, Charles Lepple <<a href="mailto:clepple@gmail.com">clepple@gmail.com</a>> wrote:<br>
> On Sep 29, 2014, at 12:50 PM, Shade Alabsa <<a href="mailto:shade34321@gmail.com">shade34321@gmail.com</a>> wrote:<br>
><br>
>> The lsusb command did not trigger a disconnect. The output of that<br>
>> command is below.<br>
><br>
> 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:<br>
><br>
> Sep 23 17:05:47 nemo kernel: usb 7-1: USB disconnect, device number 63<br>
> Sep 23 17:05:47 nemo kernel: usb 7-1: new low speed USB device number 64 using uhci_hcd<br>
> Sep 23 17:05:47 nemo kernel: usb 7-1: New USB device found, idVendor=09ae, idProduct=3015<br>
><br>
>> I ran "usbhid-ups -a upsunit -DDD &> output.log" and<br>
>> I have attached the /var/log/messages and output.log to this email.<br>
>> Before running this test though I did clear out the messages so there<br>
>> isn't a whole lot there. I also contacted Tripp-Lite today and they<br>
>> are also looking into this.<br>
><br>
> The part that really confuses me is this:<br>
><br>
> Sep 23 17:06:05 nemo kernel: usb 7-1: usbfs: process 2291 (usbhid-ups) did not claim interface 0 before use<br>
> Sep 23 17:06:05 nemo kernel: usb 7-1: usbfs: process 2291 (usbhid-ups) did not claim interface 0 before use<br>
><br>
> This doesn't seem to match the source code, which tries to claim the interface up to three times, and if it doesn't work, it exits with a fatal error. Your logs show the same PID for usbhid-ups, so it apparently didn't exit. I am wondering if I am looking at the same code as what is built on your system. Do you have the exact version for the RPM files, or better yet, the corresponding SRPMs?<br>
><br>
> --<br>
> Charles Lepple<br>
> clepple@gmail<br>
><br>
><br>
><br>
</div></div></blockquote></div><br></div>