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@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@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@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@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@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@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@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@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@127.0.0.1] failed -
Data stale
Sep 22 10:36:45 nemo upsmon[12015]: Poll UPS [upsunit@127.0.0.1] failed -
Data stale
Sep 22 10:36:50 nemo upsmon[12015]: Poll UPS [upsunit@127.0.0.1] failed -
Data stale
Sep 22 10:36:55 nemo upsmon[12015]: Poll UPS [upsunit@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@127.0.0.1] failed -
Data stale
Sep 22 10:37:05 nemo upsmon[12015]: Poll UPS [upsunit@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@127.0.0.1 established
Sep 22 10:37:10 nemo wall[12035]: wall: user nut broadcasted 1 lines (55
chars)
[root@nemo tmp]#
Broadcast message from nut@nemo (Mon Sep 22 10:40:00 2014):
Communications with UPS upsunit@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 <shade34...@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 <clep...@gmail.com> wrote:
On Sep 19, 2014, at 7:48 PM, Shade Alabsa <shade34...@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@gmail
Odchozi zprava neobsahuje viry, protoze nebyla odeslana z Windows.
Otestovano zdarma a legalne na OS Linux.
(Proc pouzivat Linux - http://proc.linux.cz/).
_______________________________________________
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
