thr3ads.net - Nut upsuser - [Nut-upsuser] Tripp-Lite USB constantlly disconnecting. [Sep 2014]

If this information is useful, please help other people find it:
Share via:

Shade Alabsa

2014-Sep-21 17:12 UTC

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

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
>
>
>
>-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20140921/4f2d48d9/attachment.html>

Shade Alabsa

2014-Sep-22 15:14 UTC

head link

[Nut-upsuser] 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

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
>>
>>
>>
>>
>-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20140922/39ac7283/attachment.html>

Adam Pribyl

2014-Sep-22 16:37 UTC

head link

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

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/).

Charles Lepple

2014-Sep-23 01:05 UTC

head link

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

On Sep 22, 2014, at 11:14 AM, Shade Alabsa <shade34321 at gmail.com>
wrote:
> 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.
What is the new behavior?

Your latest excerpt from /var/log/messages does not show that the driver is
running at all, so the upsd and upsmon messages are to be expected.

Also, in your first email in this thread, you mentioned that you saw problems
only when NUT is configured. Can you elaborate on that? With upsd, upsmon and
usbhid-ups stopped, you should be able to plug in the UPS, and only see one
message like this:

Sep 19 17:49:41 localhost kernel: usb 8-1: new low speed USB device number 119
using uhci_hcd
Sep 19 17:49:41 localhost kernel: usb 8-1: New USB device found, idVendor=09ae,
idProduct=3015
Sep 19 17:49:41 localhost kernel: usb 8-1: New USB device strings: Mfr=2,
Product=3, SerialNumber=4
Sep 19 17:49:41 localhost kernel: usb 8-1: Product: TRIPP LITE SMART1500RM2UN
Sep 19 17:49:41 localhost kernel: usb 8-1: Manufacturer: Tripp Lite
Sep 19 17:49:41 localhost kernel: usb 8-1: SerialNumber: 2424AY0SM882300229
Sep 19 17:49:41 localhost kernel: usb 8-1: configuration #1 chosen from 1 choice

You should also be able to run "lsusb -v -d 09ae:" and get results
from the UPS, also without anything disconnecting.

If that doesn't trigger a disconnection, we will want to see the output of
running the usbhid-ups driver in debug mode (probably at the "-DDD"
level) as well as the corresponding /var/log/messages output.

-- 
Charles Lepple
clepple at gmail



-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20140922/8115a639/attachment-0001.html>

Charles Lepple

2014-Sep-23 01:29 UTC

head link

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

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 that you make them aware of the
issue - this UPS was on their compatibility list they posted in October 2013,
although if I recall, it was unclear whether each distribution was tested with
each model.

http://news.gmane.org/find-root.php?message_id=B8D50FAB7FEF06479924547835C34D448412AEF6%40CHI%2dVS%2dEXMBX11.tripplite.com

-- 
Charles Lepple
clepple at gmail

Possibly Parallel Threads

Search for more maybe matching threads

Nut upsuser - Sep 2014 - Tripp-Lite USB constantlly disconnecting.

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

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

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

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

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

Possibly Parallel Threads