[Nut-upsuser] Tripp-Lite USB constantlly disconnecting.
Adam Pribyl
pribyl at lowlevel.cz
Mon Sep 22 16:37:47 UTC 2014
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 back again.
Just wanted to let you know, you may try vendor provided driver, if there
is any...
Adam Pribyl
On Mon, 22 Sep 2014, Shade Alabsa wrote:
> 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
>
> CentOS 6.5 -
> [root at localhost ~]# uname -a
> Linux localhost.localdomain 2.6.32-431.23.3.el6.x86_64 #1 SMP Thu Jul 31
> 17:20:51 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
>
> [root at localhost ~]# rpm -qa | grep nut
> nut-client-2.6.5-2.el6.x86_64
> nut-2.6.5-2.el6.x86_64
>
> Fedora 20 -
> [root at nemo ~]# uname -a
> Linux nemo 3.11.10-301.fc20.x86_64 #1 SMP Thu Dec 5 14:01:17 UTC 2013
> x86_64 x86_64 x86_64 GNU/Linux
>
> [root at nemo ~]# rpm -qa | grep nut
> nut-2.7.2-1.fc20.x86_64
> nut-client-2.7.2-1.fc20.x86_64
>
> As mentioned earlier I have tried another USB port and cable. Below are the
> /var/log/messages - I also got a new behavior this time.
>
> Sep 22 10:35:50 nemo upsd[12011]: Data for UPS [upsunit] is stale - check
> driver
> Broadcast message from nut at nemo (Mon Sep 22 10:52:15 2014):.0.1] failed -
> Data stale
>
> Sep 22 10:36:34 nemo kernel: usb 8-1: USB disconnect, device number 112
> Sep 22 10:36:34 nemo kernel: usb 8-1: new low speed USB device number 113
> using uhci_hcd
> Sep 22 10:36:35 nemo kernel: usb 8-1: New USB device found, idVendor=09ae,
> idProduct=3015
> Sep 22 10:36:35 nemo kernel: usb 8-1: New USB device strings: Mfr=2,
> Product=3, SerialNumber=4
> Sep 22 10:36:35 nemo kernel: usb 8-1: Product: TRIPP LITE SMART1500RM2UN
> Sep 22 10:36:35 nemo kernel: usb 8-1: Manufacturer: Tripp Lite
> Sep 22 10:36:35 nemo kernel: usb 8-1: SerialNumber: 2424AY0SM882300229
> Sep 22 10:36:35 nemo kernel: usb 8-1: configuration #1 chosen from 1 choice
> Sep 22 10:36:35 nemo upsmon[12015]: Poll UPS [upsunit at 127.0.0.1] failed -
> Data stale
> Sep 22 10:36:35 nemo kernel: generic-usb 0003:09AE:3015.0071:
> hiddev96,hidraw2: USB HID v1.10 Device [Tripp Lite TRIPP LITE
> SMART1500RM2UN ] on usb-0000:00:1d.2-1/input0
> Sep 22 10:36:39 nemo kernel: usb 8-1: USB disconnect, device number 113
> Sep 22 10:36:40 nemo upsmon[12015]: Poll UPS [upsunit at 127.0.0.1] failed -
> Data stale
> Sep 22 10:36:45 nemo upsmon[12015]: Poll UPS [upsunit at 127.0.0.1] failed -
> Data stale
> Sep 22 10:36:50 nemo upsmon[12015]: Poll UPS [upsunit at 127.0.0.1] failed -
> Data stale
> Sep 22 10:36:55 nemo upsmon[12015]: Poll UPS [upsunit at 127.0.0.1] failed -
> Data stale
> Sep 22 10:36:56 nemo kernel: usb 7-1: new low speed USB device number 2
> using uhci_hcd
> Sep 22 10:36:56 nemo kernel: usb 7-1: New USB device found, idVendor=09ae,
> idProduct=3015
> Sep 22 10:36:56 nemo kernel: usb 7-1: New USB device strings: Mfr=2,
> Product=3, SerialNumber=4
> Sep 22 10:36:56 nemo kernel: usb 7-1: Product: TRIPP LITE SMART1500RM2UN
> Sep 22 10:36:56 nemo kernel: usb 7-1: Manufacturer: Tripp Lite
> Sep 22 10:36:56 nemo kernel: usb 7-1: SerialNumber: 2424AY0SM882300229
> Sep 22 10:36:56 nemo kernel: usb 7-1: configuration #1 chosen from 1 choice
> Sep 22 10:36:57 nemo kernel: generic-usb 0003:09AE:3015.0072:
> hiddev96,hidraw2: USB HID v1.10 Device [Tripp Lite TRIPP LITE
> SMART1500RM2UN ] on usb-0000:00:1d.1-1/input0
> Sep 22 10:37:00 nemo upsmon[12015]: Poll UPS [upsunit at 127.0.0.1] failed -
> Data stale
> Sep 22 10:37:05 nemo upsmon[12015]: Poll UPS [upsunit at 127.0.0.1] failed -
> Data stale
> Sep 22 10:37:05 nemo upsd[12011]: UPS [upsunit] data is no longer stale
> Sep 22 10:37:10 nemo upsmon[12015]: Communications with UPS
> upsunit at 127.0.0.1 established
> Sep 22 10:37:10 nemo wall[12035]: wall: user nut broadcasted 1 lines (55
> chars)
>
> [root at nemo tmp]#
> Broadcast message from nut at nemo (Mon Sep 22 10:40:00 2014):
>
> Communications with UPS upsunit at 127.0.0.1 lost
>
>
> 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!
>
> Shade
>
> On Sun, Sep 21, 2014 at 1:12 PM, Shade Alabsa <shade34321 at gmail.com> wrote:
>
>> 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 installing a minimal build onto these
>> machines to see if something changes.
>>
>> Thanks!
>> Shade
>>
>> On Sat, Sep 20, 2014 at 8:47 AM, Charles Lepple <clepple at gmail.com> wrote:
>>
>>> 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 it's quite possible
>>> I missed it. I've tested this with CentOS 6.5 and Fedora 20. With CentOS we
>>> were using nut-client-2.6.5-2.el16.x86_64 and nut-2.6.5-2.el6.x86_64. With
>>> Fedora we were using nut-2.7.2-1.fc20.x86_64 and
>>> nut-client-2.7.2-1.fc20.x86_64.
>>>
>>> What kernel versions?
>>>
>>> We have had a number of recent reports of issues with USB 3.0 host
>>> controllers. While it seems like your UPS is getting picked up by the
>>> uhci_hcd driver, you might want to check if another USB port works better.
>>> Also, make sure you are using a decent-quality cable (no passive USB
>>> extenders, etc.).
>>>
>>> I am also slightly suspicious of mtp-probe. We haven't done any testing
>>> with other programs trying to access the UPS at the same time, but there is
>>> some code in NUT to try and catch two NUT drivers from tripping over each
>>> other. But it only shows up in the Fedora output, and its messages seem
>>> closer to when the device is attached, rather than when it disconnects. I'm
>>> not sure if Fedora or CentOS have "server" builds, but I would recommend
>>> starting from the minimum software necessary and building up.
>>>
>>> --
>>> Charles Lepple
>>> clepple at gmail
>>>
>>>
>>>
>>>
>>
>
Odchozi zprava neobsahuje viry, protoze nebyla odeslana z Windows.
Otestovano zdarma a legalne na OS Linux.
(Proc pouzivat Linux - http://proc.linux.cz/).
More information about the Nut-upsuser
mailing list