Shade Alabsa
2014-Sep-19 23:48 UTC
[Nut-upsuser] Tripp-Lite USB constantlly disconnecting.
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-Sep-20 12:47 UTC
[Nut-upsuser] Tripp-Lite USB constantlly disconnecting.
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
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>