Sam Varshavchik
2017-Apr-08 01:15 UTC
[Nut-upsuser] usbhid-ups: Failed to open device, skipping. (Permission denied)
Charles Lepple writes:> On Sun, Apr 2, 2017 at 2:59 AM, Sam Varshavchik <mrsam at courier-mta.com> > wrote: > > Having trouble configuring nut 2.7.4 on Fedora 25, with a new Tripp Lite > > UPS. > > > > I'm running XFCE, and XFCE's Power Manager sees the UPS just fine. lsusb > > gives: > > > > Bus 006 Device 002: ID 09ae:3016 Tripp Lite > > I'm still catching up on mail, so apologies if this was covered on a > more recent GitHub issue, but Tripp Lite PID 3016 is extra-sensitive > to certain combinations of USB cables and newer motherboards. If you > take NUT and XFCE power manager out of the equation, but the UPS still > generates a lot of disconnect/timeout/reconnect traffic in the kernel > logs, you might be up against this issue. > > Full gory details here: https://github.com/networkupstools/nut/pull/122This particular new unit came with its own USB cable, and this unit is plugged into a relatively old server. The motherboard is about ten years old. I have a lot of noise in my syslog. grepping for 'usb' or '3016' doesn't find anything useful. I've getting better results with the last patch from issue 414, which fixes the bad error handling that was causing the driver to bail out. The driver still yells about EAGAIN/EIO, once every four minutes or so: ioctl(10, USBDEVFS_REAPURBNDELAY, 0x7ffd4d210fe0) = -1 EAGAIN (Resource temporarily unavailable) sendto(3, "<31>Apr 1 12:46:10 usbhid-ups[4983]: libusb_get_report: Input/output error", 75, MSG_NOSIGNAL, NULL, 0) = 75 but with the patch it recovers and keeps running. With the last patch from 414, the driver has now been running for over 24 hours, just quietly barking about these timeouts, and reconnects, to anyone who'd listen. I am open to suggestions for grep food, but I can't find anything in my syslog that looks like a kernel complaint about actual USB connectivity. My weekend project is to build the patched libusb-1.0 branch, and see what happens there. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 801 bytes Desc: not available URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20170407/1aacc140/attachment.sig>
Stuart Gathman
2017-Apr-08 02:36 UTC
[Nut-upsuser] usbhid-ups: Failed to open device, skipping. (Permission denied)
On 04/07/2017 09:15 PM, Sam Varshavchik wrote:> Charles Lepple writes: > >> >> Full gory details here: https://github.com/networkupstools/nut/pull/122 > > This particular new unit came with its own USB cable, and this unit is > plugged into a relatively old server. The motherboard is about ten > years old. >I also had this problem with this unit. My hacky solution solution is here: https://github.com/sdgathman/trippfix I'm convinced that the USB interface on these units is braindead - despite their other excellent qualities (excellent handling of outages). Many other people have the same problem with this unit, including Windows users with the supplied proprietary monitoring software, so I think it is hardware. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20170407/5fb86b7b/attachment.sig>
Sam Varshavchik
2017-Apr-08 12:08 UTC
[Nut-upsuser] usbhid-ups: Failed to open device, skipping. (Permission denied)
Stuart Gathman writes:> On 04/07/2017 09:15 PM, Sam Varshavchik wrote: > > Charles Lepple writes: > > > >> > >> Full gory details here: https://github.com/networkupstools/nut/pull/122 > > > > This particular new unit came with its own USB cable, and this unit is > > plugged into a relatively old server. The motherboard is about ten > > years old. > > > I also had this problem with this unit. My hacky solution solution is > here: https://github.com/sdgathman/trippfix > > I'm convinced that the USB interface on these units is braindead - > despite their other excellent qualities (excellent handling of > outages). Many other people have the same problem with this unit, > including Windows users with the supplied proprietary monitoring > software, so I think it is hardware.What would be the symptoms of this that I would be seeing? I don't see anything in syslog, only usbhid-ups getting a periodic timeout, but each time it successfully reconnects via USB. It is not entirely unprecedented for manufacturers to quitely fix defects in their hardware, then simply continue to ship it as the same model. It's been about a week since this unit has been plugged in, with the only issue being these usbhid-ups timeouts, which it now apparently recovers from it. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 801 bytes Desc: not available URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20170408/3e372a74/attachment.sig>
Possibly Parallel Threads
- usbhid-ups: Failed to open device, skipping. (Permission denied)
- usbhid-ups: Failed to open device, skipping. (Permission denied)
- Keeps losing connection with UPS (local usb connection)
- usbhid-ups: Failed to open device, skipping. (Permission denied)
- How to disable hal-addon-hid-ups