Charles, > 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. > 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 On Mon, Sep 29, 2014 at 10:26 PM, Charles Lepple <clep...@gmail.com> wrote: > On Sep 29, 2014, at 12:50 PM, Shade Alabsa <shade34...@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@gmail > > > _______________________________________________ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser