I've made some progress getting this Tripplite to work: http://gathman.org/2016/07/30/Standard_Schmandard/ Basically, plug it into a USB hub that actually implements USB2.0, then power cycle the port when it hangs. It does seem to be a hardware problem with the USB controller. On 05/24/2016 09:06 AM, Charles Lepple wrote:> On May 22, 2016, at 10:18 AM, Stuart Gathman wrote: >> I have a ticket open with TrippLite, but at this point it seems to be a >> software, rather than hardware problem, since with the newer kernel and >> usbhid-ups, the ups stays on the bus, and I could kludge around the >> problem by making systemd keep restarting nut-driver. They seem to be >> interested in actually resolving the issue. If necessary, I am willing >> to donate the TrippLite and just buy a Cyberware (the last cyberware I >> bought works - hopefully they haven't broken their USB code). What >> should I do next to diagnose this problem? I don't know enough about >> USB protocol to determine which side is broken (I can only point to all >> the other brands of USB UPC that work). > I have that same model UPS, and the same general set of symptoms. Although I can't argue with the software dependency, I think it might be related to the USB controller hardware as well. > > http://lists.alioth.debian.org/pipermail/nut-upsuser/2015-October/009967.html > > With a Raspberry Pi, the UPS seemed to run much longer between disconnects. I would have to dig up the old logs to see which kernels were in use. > > I was hoping to have more time to test this UPS, but a lot of other projects got in the way, and I ended up just switching to an older Tripp-Lite OMNIVS1000. > > Another option is to build the code from this pull request, which reorganizes the way the device is polled: https://github.com/networkupstools/nut/pull/122 > > I don't have a lot of experience with that branch, but it sounds promising. (I would prefer to identify the underlying problem rather than work around it by closing and reopening the USB device more frequently, though, especially given the testing needed for other UPSes.) >
On 08/03/2016 05:25 AM, Stuart Gathman wrote:> I've made some progress getting this Tripplite to work: > http://gathman.org/2016/07/30/Standard_Schmandard/ > > Basically, plug it into a USB hub that actually implements USB2.0, then > power cycle the port when it hangs. It does seem to be a hardware > problem with the USB controller.Finally an idea;-) I had the same problem for a couple of years but since I use a [1st gen] appleTV as the server, I thought it might be it's USB port. I bought a `plugable USB2-HUB-AG7' and experimented a bit. So far, I did not get it to turn the power to devices completely off:-( But the unbind/bind seems affect the devices somehow. I tried it with a little Sparkfun RedBoard (Arduino clone) and when I [re]bind, the RX/TX LEDs flash shortly, so it seems to reinitialize it's USB-Serial chip. Maybe that's enough? The same TX/RX LED flashing happens with the hub-ctrl power off->on;-) OK, the USB hub is now installed between the aTV & USP ;-) Let's see what happens next. -- Marco> > On 05/24/2016 09:06 AM, Charles Lepple wrote: >> On May 22, 2016, at 10:18 AM, Stuart Gathman wrote: >>> I have a ticket open with TrippLite, but at this point it seems to be a >>> software, rather than hardware problem, since with the newer kernel and >>> usbhid-ups, the ups stays on the bus, and I could kludge around the >>> problem by making systemd keep restarting nut-driver. They seem to be >>> interested in actually resolving the issue. If necessary, I am willing >>> to donate the TrippLite and just buy a Cyberware (the last cyberware I >>> bought works - hopefully they haven't broken their USB code). What >>> should I do next to diagnose this problem? I don't know enough about >>> USB protocol to determine which side is broken (I can only point to all >>> the other brands of USB UPC that work). >> I have that same model UPS, and the same general set of symptoms. Although I can't argue with the software dependency, I think it might be related to the USB controller hardware as well. >> >> http://lists.alioth.debian.org/pipermail/nut-upsuser/2015-October/009967.html >> >> With a Raspberry Pi, the UPS seemed to run much longer between disconnects. I would have to dig up the old logs to see which kernels were in use. >> >> I was hoping to have more time to test this UPS, but a lot of other projects got in the way, and I ended up just switching to an older Tripp-Lite OMNIVS1000. >> >> Another option is to build the code from this pull request, which reorganizes the way the device is polled: https://github.com/networkupstools/nut/pull/122 >> >> I don't have a lot of experience with that branch, but it sounds promising. (I would prefer to identify the underlying problem rather than work around it by closing and reopening the USB device more frequently, though, especially given the testing needed for other UPSes.) >> > > _______________________________________________ > Nut-upsdev mailing list > Nut-upsdev at lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
On Fri, 5 Aug 2016, Marco Walther wrote:> On 08/03/2016 05:25 AM, Stuart Gathman wrote: >> I've made some progress getting this Tripplite to work: >> http://gathman.org/2016/07/30/Standard_Schmandard/ >> >> Basically, plug it into a USB hub that actually implements USB2.0, then >> power cycle the port when it hangs. It does seem to be a hardware >> problem with the USB controller. > Finally an idea;-) I had the same problem for a couple of years but since I > use a [1st gen] appleTV as the server, I thought it might be it's USB port. > > I bought a `plugable USB2-HUB-AG7' and experimented a bit. So far, I did not > get it to turn the power to devices completely off:-( But the unbind/bind > seems affect the devices somehow. I tried it with a little Sparkfun RedBoard > (Arduino clone) and when I [re]bind, the RX/TX LEDs flash shortly, so it > seems to reinitialize it's USB-Serial chip. Maybe that's enough? > > The same TX/RX LED flashing happens with the hub-ctrl power off->on;-) > > OK, the USB hub is now installed between the aTV & USP ;-) Let's see what > happens next.I also bought a USB2-HUB-AG7, but the new black version (of the *same* model# - arrrrgggghhhh) no longer implements PPPS. Only the old silver version does. What is the point of a model# if you can't count on the functionality? -- Stuart D. Gathman <stuart at gathman.org> "Confutatis maledictis, flamis acribus addictis" - background song for a Microsoft sponsored "Where do you want to go from here?" commercial.