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

Discussion:

Shade Alabsa

2014-09-19 23:48:08 UTC

Hey, was wondering if I could get a quick sanity check. We have a SmartUPS
1500 RM2U which we have connected to a box via USB. It seems like every
40-45 seconds it becomes disconnected and reconnected. Though this only
happens when we have NUT enabled, otherwise it's fine. When it is
disconnecting and reconnecting running lsusb doesn't show it disconnecting.
After having it sit like that for a day NUT was unable to connect to the
driver.

So I was wondering does NUT do anything which would cause the USB to
disconnect? 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.

Here is what the logs look like -

CentOS -
ite TRIPP LITE SMART1500RM2UN ] on usb-0000:00:1d.2-1/input0
Sep 19 17:49:41 localhost kernel: usb 8-1: USB disconnect, device number 118
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
Sep 19 17:49:42 localhost kernel: generic-usb 0003:09AE:3015.0171:
hiddev96,hidraw2: USB HID v1.10 Device [Tripp Lite TRIPP LITE
SMART1500RM2UN ] on usb-0000:00:1d.2-1/input0
Sep 19 17:50:26 localhost kernel: usb 8-1: USB disconnect, device number 119
Sep 19 17:50:26 localhost kernel: usb 8-1: new low speed USB device number
120 using uhci_hcd
Sep 19 17:50:26 localhost kernel: usb 8-1: New USB device found,
idVendor=09ae, idProduct=3015
Sep 19 17:50:26 localhost kernel: usb 8-1: New USB device strings: Mfr=2,
Product=3, SerialNumber=4
Sep 19 17:50:26 localhost kernel: usb 8-1: Product: TRIPP LITE
SMART1500RM2UN
Sep 19 17:50:26 localhost kernel: usb 8-1: Manufacturer: Tripp Lite
Sep 19 17:50:26 localhost kernel: usb 8-1: SerialNumber: 2424AY0SM882300229
Sep 19 17:50:26 localhost kernel: usb 8-1: configuration #1 chosen from 1
choice
Sep 19 17:50:27 localhost kernel: generic-usb 0003:09AE:3015.0172:
hiddev96,hidraw2: USB HID v1.10 Device [Tripp Lite TRIPP LITE
SMART1500RM2UN ] on usb-0000:00:1d.2-1/input0

Fedora -
Sep 19 19:46:19 nemo kernel: usb 8-1: USB disconnect, device number 6
Sep 19 19:46:19 nemo usbhid-ups[1595]: libusb_get_interrupt: No such device
or address
Sep 19 19:46:19 nemo usbhid-ups[1595]: libusb_get_report: No such device or
address
Sep 19 19:46:19 nemo kernel: usb 8-1: new low-speed USB device number 7
using uhci_hcd
Sep 19 19:46:20 nemo kernel: usb 8-1: New USB device found, idVendor=09ae,
idProduct=3015
Sep 19 19:46:20 nemo kernel: usb 8-1: New USB device strings: Mfr=2,
Product=3, SerialNumber=4
Sep 19 19:46:20 nemo kernel: usb 8-1: Product: TRIPP LITE SMART1500RM2UN
Sep 19 19:46:20 nemo kernel: usb 8-1: Manufacturer: Tripp Lite
Sep 19 19:46:20 nemo kernel: usb 8-1: SerialNumber: 2424AY0SM882300229
Sep 19 19:46:20 nemo kernel: hid-generic 0003:09AE:3015.0007:
hiddev0,hidraw2: USB HID v1.10 Device [Tripp Lite TRIPP LITE
SMART1500RM2UN ] on usb-0000:00:1d.2-1/input0
Sep 19 19:46:20 nemo mtp-probe[1689]: checking bus 8, device 7:
"/sys/devices/pci0000:00/0000:00:1d.2/usb8/8-1"
Sep 19 19:46:20 nemo mtp-probe[1689]: bus: 8, device: 7 was not an MTP
device
Sep 19 19:46:49 nemo kernel: usb 8-1: USB disconnect, device number 7
Sep 19 19:46:49 nemo kernel: usb 8-1: new low-speed USB device number 8
using uhci_hcd
Sep 19 19:46:49 nemo usbhid-ups[1595]: libusb_get_interrupt: No such device
or address
Sep 19 19:46:49 nemo usbhid-ups[1595]: libusb_get_report: No such device or
address
Sep 19 19:46:49 nemo kernel: usb 8-1: New USB device found, idVendor=09ae,
idProduct=3015
Sep 19 19:46:49 nemo kernel: usb 8-1: New USB device strings: Mfr=2,
Product=3, SerialNumber=4
Sep 19 19:46:49 nemo kernel: usb 8-1: Product: TRIPP LITE SMART1500RM2UN
Sep 19 19:46:49 nemo kernel: usb 8-1: Manufacturer: Tripp Lite
Sep 19 19:46:49 nemo kernel: usb 8-1: SerialNumber: 2424AY0SM882300229
Sep 19 19:46:50 nemo kernel: hid-generic 0003:09AE:3015.0008:
hiddev0,hidraw2: USB HID v1.10 Device [Tripp Lite TRIPP LITE
SMART1500RM2UN ] on usb-0000:00:1d.2-1/input0
Sep 19 19:46:50 nemo mtp-probe[1699]: checking bus 8, device 8:
"/sys/devices/pci0000:00/0000:00:1d.2/usb8/8-1"
Sep 19 19:46:50 nemo mtp-probe[1699]: bus: 8, device: 8 was not an MTP
device

These messages just repeat indefinitely.

Thanks,
Shade
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20140919/3b9d791e/attachment-0001.html>

Charles Lepple

2014-09-20 12:47:43 UTC

Permalink

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

Shade Alabsa

2014-09-21 17:12:29 UTC

Permalink

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

Post by Shade Alabsa

Post by Shade Alabsa
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.

Post by Shade Alabsa
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-09-22 15:14:23 UTC

Permalink

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

Post by Shade Alabsa
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

Post by Shade Alabsa

Post by Shade Alabsa
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.

Post by Shade Alabsa
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-09-22 16:37:47 UTC

Permalink

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

Post by Shade Alabsa
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
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
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]#
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

Post by Shade Alabsa

Post by Shade Alabsa
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.

Post by Shade Alabsa
I didn't think so and I couldn't find anything yet it's quite possible

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-09-23 03:13:50 UTC

Permalink

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

Forwarding Shade's response:

"Adam,
Thanks for the suggestion. As far as I know they only have a Java client which will probably work in linux but we run headless servers. I've also suggested this or asking for a CLI version from them but the guys at work figured NUT should be able to do the job.

With that being said I also noticed if you're using their SNMPWEBCARD they have bug and report the load wrong and I forgot to mention it. Are UPS was under a 19% load and NUT was reporting 190, when I called their tech support they told me it was a limitation in the software, theirs software or the SNMP protocal I believe, where they're supposed to be sending a float but only send an int. Instead of just dropping the decimal and everything after or rounding logically they just take out the decimal completely and return all the numbers.

Shade"

Charles Lepple

2014-09-23 01:05:23 UTC

Permalink

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-09-23 01:29:20 UTC

Permalink

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

Shade Alabsa

2014-09-23 02:24:39 UTC

Permalink

Charles,

Post by Charles Lepple
What is the new behavior?

The CentOS minimal install had different print statements and a broadcast
message whenever the UPS was disconnected. The broadcast isn't really
important. Below are the differences I pasted though I'm not sure if they
are important, I just noticed they were different. Particularly the bolded
parts which I think you alluded to in your email about them not being
connected. Those messages didn't show up in the other installs.

Fedora -
Sep 19 19:46:19 nemo usbhid-ups[1595]: libusb_get_interrupt: No such device
or address
Sep 19 19:46:19 nemo usbhid-ups[1595]: libusb_get_report: No such device or
address
Sep 19 19:46:20 nemo kernel: usb 8-1: SerialNumber: 2424AY0SM882300229
Sep 19 19:46:20 nemo kernel: hid-generic 0003:09AE:3015.0007:
hiddev0,hidraw2: USB HID v1.10 Device [Tripp Lite TRIPP LITE
SMART1500RM2UN ] on usb-0000:00:1d.2-1/input0
Sep 19 19:46:20 nemo mtp-probe[1689]: checking bus 8, device 7:
"/sys/devices/pci0000:00/0000:00:1d.2/usb8/8-1"
Sep 19 19:46:20 nemo mtp-probe[1689]: bus: 8, device: 7 was not an MTP
device
Sep 19 19:46:50 nemo mtp-probe[1699]: bus: 8, device: 8 was not an MTP
device

CentOS -
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: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
S*ep 22 10:37:00 nemo upsmon[12015]: Poll UPS [upsunit at 127.0.0.1
<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
<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 <upsunit at 127.0.0.1> established*
*Sep 22 10:37:10 nemo wall[12035]: wall: user nut broadcasted 1 lines (55
chars) *

Post by Charles Lepple
You should also be able to run "lsusb -v -d 09ae:" and get results

from the UPS, also without anything disconnecting.

Post by Charles Lepple
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.

I will try this tomorrow and send the results back.

Post by Charles Lepple
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.

I am planning on emailing them tomorrow, I just wanted to take NUT out of
the equation since when I called Tech support earlier this week they stated
they don't support NUT for tech support I presume.

Thanks for your help!

Shade

Post by Charles Lepple

Post by Shade Alabsa
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

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

Shade Alabsa

2014-09-29 16:46:57 UTC

Permalink

Charles,

Post by Charles Lepple
What is the new behavior?

The CentOS minimal install had different print statements and a
broadcast message whenever the UPS was disconnected. The broadcast
isn't really important. Below are the differences I pasted though I'm
not sure if they are important, I just noticed they were different.
Particularly the bolded parts which I think you alluded to in your
email about them not being connected. Those messages didn't show up in
the other installs.

Fedora -
Sep 19 19:46:19 nemo usbhid-ups[1595]: libusb_get_interrupt: No such
device or address
Sep 19 19:46:19 nemo usbhid-ups[1595]: libusb_get_report: No such
device or address
Sep 19 19:46:20 nemo kernel: usb 8-1: SerialNumber: 2424AY0SM882300229
Sep 19 19:46:20 nemo kernel: hid-generic 0003:09AE:3015.0007:
hiddev0,hidraw2: USB HID v1.10 Device [Tripp Lite TRIPP LITE
SMART1500RM2UN ] on usb-0000:00:1d.2-1/input0
Sep 19 19:46:20 nemo mtp-probe[1689]: checking bus 8, device 7:
"/sys/devices/pci0000:00/0000:00:1d.2/usb8/8-1"
Sep 19 19:46:20 nemo mtp-probe[1689]: bus: 8, device: 7 was not an MTP device
Sep 19 19:46:50 nemo mtp-probe[1699]: bus: 8, device: 8 was not an MTP device

CentOS -
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: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)

Post by Charles Lepple
You should also be able to run "lsusb -v -d 09ae:" and get

results from the UPS, also without anything disconnecting.

Post by Charles Lepple
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.

I will try this tomorrow and send the results back.

Post by Charles Lepple
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.

I am planning on emailing them tomorrow, I just wanted to take NUT out
of the equation since when I called Tech support earlier this week
they stated they don't support NUT for tech support I presume.

Thanks for your help!

Post by Charles Lepple
Charles,

Post by Charles Lepple
What is the new behavior?

The CentOS minimal install had different print statements and a broadcast
message whenever the UPS was disconnected. The broadcast isn't really
important. Below are the differences I pasted though I'm not sure if they
are important, I just noticed they were different. Particularly the bolded
parts which I think you alluded to in your email about them not being
connected. Those messages didn't show up in the other installs.
Fedora -
Sep 19 19:46:19 nemo usbhid-ups[1595]: libusb_get_interrupt: No such device
or address
Sep 19 19:46:19 nemo usbhid-ups[1595]: libusb_get_report: No such device or
address
Sep 19 19:46:20 nemo kernel: usb 8-1: SerialNumber: 2424AY0SM882300229
hiddev0,hidraw2: USB HID v1.10 Device [Tripp Lite TRIPP LITE SMART1500RM2UN
] on usb-0000:00:1d.2-1/input0
"/sys/devices/pci0000:00/0000:00:1d.2/usb8/8-1"
Sep 19 19:46:20 nemo mtp-probe[1689]: bus: 8, device: 7 was not an MTP
device
Sep 19 19:46:50 nemo mtp-probe[1699]: bus: 8, device: 8 was not an MTP
device
CentOS -
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
hiddev96,hidraw2: USB HID v1.10 Device [Tripp Lite TRIPP LITE
SMART1500RM2UN ] on usb-0000:00:1d.2-1/input0
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)

Post by Charles Lepple
You should also be able to run "lsusb -v -d 09ae:" and get results from

the UPS, also without anything disconnecting.

Post by Charles Lepple
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.
I will try this tomorrow and send the results back.

Post by Charles Lepple
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.
I am planning on emailing them tomorrow, I just wanted to take NUT out of
the equation since when I called Tech support earlier this week they stated
they don't support NUT for tech support I presume.
Thanks for your help!
Shade

Post by Charles Lepple

Post by Shade Alabsa
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

Shade Alabsa

2014-09-29 16:50:50 UTC

Permalink

Some of my messages never went through since I hit a message size
limit. I'm resending them in the hopes they are under the limit.

Charles,
The lsusb command did not trigger a disconnect. The output of that
command is below. 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.

[root at nemo /]# lsusb -v -d 09ae:

Bus 007 Device 063: ID 09ae:3015 Tripp Lite
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x09ae Tripp Lite
idProduct 0x3015
bcdDevice 2.0a
iManufacturer 2 Tripp Lite
iProduct 3 TRIPP LITE SMART1500RM2UN
iSerial 4 2424AY0SM882300229
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 34
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xe0
Self Powered
Remote Wakeup
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 3 Human Interface Device
bInterfaceSubClass 0 No Subclass
bInterfaceProtocol 0 None
iInterface 0
HID Device Descriptor:
bLength 9
bDescriptorType 33
bcdHID 1.10
bCountryCode 0 Not supported
bNumDescriptors 1
bDescriptorType 34 Report
wDescriptorLength 1252
Report Descriptors:
** UNAVAILABLE **
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0008 1x 8 bytes
bInterval 40
Device Status: 0x0001
Self Powered

Thanks!

Post by Shade Alabsa
Charles,
The lsusb command did not trigger a disconnect. The output of that
command is below. 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.
Bus 007 Device 063: ID 09ae:3015 Tripp Lite
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x09ae Tripp Lite
idProduct 0x3015
bcdDevice 2.0a
iManufacturer 2 Tripp Lite
iProduct 3 TRIPP LITE SMART1500RM2UN
iSerial 4 2424AY0SM882300229
bNumConfigurations 1
bLength 9
bDescriptorType 2
wTotalLength 34
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xe0
Self Powered
Remote Wakeup
MaxPower 0mA
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 3 Human Interface Device
bInterfaceSubClass 0 No Subclass
bInterfaceProtocol 0 None
iInterface 0
bLength 9
bDescriptorType 33
bcdHID 1.10
bCountryCode 0 Not supported
bNumDescriptors 1
bDescriptorType 34 Report
wDescriptorLength 1252
** UNAVAILABLE **
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0008 1x 8 bytes
bInterval 40
Device Status: 0x0001
Self Powered
Thanks!
Shade

Post by Shade Alabsa
Charles,

Post by Charles Lepple
What is the new behavior?

The CentOS minimal install had different print statements and a broadcast
message whenever the UPS was disconnected. The broadcast isn't really
important. Below are the differences I pasted though I'm not sure if they
are important, I just noticed they were different. Particularly the bolded
parts which I think you alluded to in your email about them not being
connected. Those messages didn't show up in the other installs.
Fedora -
Sep 19 19:46:19 nemo usbhid-ups[1595]: libusb_get_interrupt: No such
device or address
Sep 19 19:46:19 nemo usbhid-ups[1595]: libusb_get_report: No such device
or address
Sep 19 19:46:20 nemo kernel: usb 8-1: SerialNumber: 2424AY0SM882300229
hiddev0,hidraw2: USB HID v1.10 Device [Tripp Lite TRIPP LITE SMART1500RM2UN
] on usb-0000:00:1d.2-1/input0
"/sys/devices/pci0000:00/0000:00:1d.2/usb8/8-1"
Sep 19 19:46:20 nemo mtp-probe[1689]: bus: 8, device: 7 was not an MTP
device
Sep 19 19:46:50 nemo mtp-probe[1699]: bus: 8, device: 8 was not an MTP
device
CentOS -
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
hiddev96,hidraw2: USB HID v1.10 Device [Tripp Lite TRIPP LITE
SMART1500RM2UN ] on usb-0000:00:1d.2-1/input0
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)

Post by Charles Lepple
You should also be able to run "lsusb -v -d 09ae:" and get results

from the UPS, also without anything disconnecting.

Post by Charles Lepple
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.
I will try this tomorrow and send the results back.

Post by Charles Lepple
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.
I am planning on emailing them tomorrow, I just wanted to take NUT out of
the equation since when I called Tech support earlier this week they stated
they don't support NUT for tech support I presume.
Thanks for your help!
Shade

Post by Charles Lepple

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: logs.tgz
Type: application/x-gzip
Size: 10922 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20140929/3f4fabc1/attachment-0001.bin>

Charles Lepple

2014-09-30 02:26:00 UTC

Permalink

Post by Shade Alabsa
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

Post by Shade Alabsa
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

Shade Alabsa

2014-09-30 12:33:21 UTC

Permalink

Charles,

Post by Charles Lepple
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.

Post by Charles Lepple
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

Post by Charles Lepple

Post by Shade Alabsa
The lsusb command did not trigger a disconnect. The output of that
command is below.

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

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