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@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 <shade34...@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@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 <shade34...@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@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@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) >> >> > 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 <clep...@gmail.com> wrote: >>> >>> On Sep 22, 2014, at 11:14 AM, Shade Alabsa <shade34...@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@gmail >>> >>> >>> >> >
logs.tgz
Description: GNU Zip compressed data
_______________________________________________ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser