[Nut-upsuser] Tripp-Lite USB constantlly disconnecting.

Tue Nov 18 23:28:53 UTC 2014

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 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
2.6.32-431.23.3.el6.x86_64.

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?

Thanks!
Shade Alabsa

On Tue, Sep 30, 2014 at 8:33 AM, Shade Alabsa <shade34321 at gmail.com> wrote:

> 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 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?
>
>     For this testing we actually just have whatever comes installed
> via yum on CentOS 6.5 in the EPEL I believe. Throughout this process I
> can successfully run upsc to obtain the UPS system for a while,
> roughly 24 hours before it starts reporting as stale and is no longer
> accessible. Maybe I forgot to mention that, if so I'm sorry. Below is
> the output of yum as I'm installing it from yum.
>
>
> ===================================================================================================================
>     Package                      Arch                     Version
>                   Repository              Size
>
> ===================================================================================================================
>     Installing:
>      nut                          x86_64                   2.6.5-2.el6
>                    epel                   1.2 M
>      nut-client                   x86_64                   2.6.5-2.el6
>                    epel                   121 k
>
>
> Thanks for all of your help!
>
> Shade
>
> On Mon, Sep 29, 2014 at 10:26 PM, Charles Lepple <clepple at gmail.com>
> wrote:
> > 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 the
> disconnection/reconnection messages shown here:
> >
> > Sep 23 17:05:47 nemo kernel: usb 7-1: USB disconnect, device number 63
> > Sep 23 17:05:47 nemo kernel: usb 7-1: new low speed USB device number 64
> using uhci_hcd
> > Sep 23 17:05:47 nemo kernel: usb 7-1: New USB device found,
> idVendor=09ae, idProduct=3015
> >
> >> 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 though I did clear out the messages so there
> >> isn't a whole lot there. I also contacted Tripp-Lite today and they
> >> are also looking into this.
> >
> > The part that really confuses me is this:
> >
> > Sep 23 17:06:05 nemo kernel: usb 7-1: usbfs: process 2291 (usbhid-ups)
> did not claim interface 0 before use
> > Sep 23 17:06:05 nemo kernel: usb 7-1: usbfs: process 2291 (usbhid-ups)
> did not claim interface 0 before use
> >
> > 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?
> >
> > --
> > Charles Lepple
> > clepple at gmail
> >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20141118/d3d364d2/attachment.html>