Charles Lepple
2014-Sep-23 01:29 UTC
[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
Shade Alabsa
2014-Sep-23 02:24 UTC
[Nut-upsuser] Tripp-Lite USB constantlly disconnecting.
Charles,
> 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) *
> 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.
I will try this tomorrow and send the results back.
> 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
On Mon, Sep 22, 2014 at 9:29 PM, Charles Lepple <clepple at gmail.com>
wrote:
> 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
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20140922/e50c6a7d/attachment.html>
Shade Alabsa
2014-Sep-29 16:46 UTC
[Nut-upsuser] Tripp-Lite USB constantlly disconnecting.
Charles,
> 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)
> 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.
I will try this tomorrow and send the results back.
> 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!
On Mon, Sep 22, 2014 at 10:24 PM, Shade Alabsa <shade34321 at gmail.com>
wrote:> Charles,
> > 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)
>
> > 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.
>
> I will try this tomorrow and send the results back.
>
> > 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
>
> On Mon, Sep 22, 2014 at 9:29 PM, Charles Lepple <clepple at
gmail.com> wrote:
>>
>> 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
>>
>>
>>
>
Shade Alabsa
2014-Sep-29 16:50 UTC
[Nut-upsuser] Tripp-Lite USB constantlly disconnecting.
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!
On Tue, Sep 23, 2014 at 5:14 PM, Shade Alabsa <shade34321 at gmail.com>
wrote:> 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!
> Shade
>
> On Mon, Sep 22, 2014 at 10:24 PM, Shade Alabsa <shade34321 at
gmail.com> wrote:
>>
>> Charles,
>> > 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)
>>
>> > 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.
>>
>> I will try this tomorrow and send the results back.
>>
>> > 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
>>
>> On Mon, Sep 22, 2014 at 9:29 PM, Charles Lepple <clepple at
gmail.com> wrote:
>>>
>>> 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
>>>
>>>
>>>
>>
>
-------------- 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-Sep-30 02:26 UTC
[Nut-upsuser] Tripp-Lite USB constantlly disconnecting.
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