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@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
_______________________________________________
Nut-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
