Re: [Nut-upsuser] trouble building nut for HID-USB [Tripp Lite 4016]
On Oct 28, 2016, at 8:43 AM, Dorsey, Scott B. (LARC-D316)[LITES II] wrote: > > So, no suggestions for diagnosing intermittent driver loading issues? > >> You might also benefit from adjusting these variables: >> http://lists.alioth.debian.org/pipermail/nut-upsuser/2016-October/010352.html > > I tried changing the polling interval, it doesn't seem to make any > difference. Either it loads when upsdrvctl runs, or it doesn't. Once it > loads, > it can poll at any rate without being a problem. > --scott Ah, I think I was confusing several threads. I thought you were restarting after the driver had indicated that the UPS had disconnected. Since you have 2.7.4 now, there is a pair of upsdrvctl options introduced in 2.7.2 to control retries: "maxretry" and "retrydelay". http://networkupstools.org/docs/man/ups.conf.html The strange part is that I would expect the "No matching HID UPS found" message to correlate with the UPS not showing up on lsusb. There are some corner cases, though. We'll need the startup messages from the driver. I thought we had fixed this to pass the debug flags through, but something like "upsdrvctl -D -D start" should print the path to the driver, and then you can copy-and-paste that command line (something like "/lib/nut/usbhid-ups...") with one or more "-D" flags added to *that*. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] trouble building nut for HID-USB
So, no suggestions for diagnosing intermittent driver loading issues? > You might also benefit from adjusting these variables: > http://lists.alioth.debian.org/pipermail/nut-upsuser/2016-October/010352.html I tried changing the polling interval, it doesn't seem to make any difference. Either it loads when upsdrvctl runs, or it doesn't. Once it loads, it can poll at any rate without being a problem. --scott ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] trouble building nut for HID-USB
"lsusb" always shows the UPS. It's always there with an ls -al. I can start the thing, and it doesn't load wait a minute and try again and it doesn't load wait another minute and it loads then try to restart a minute later and it doesn't load. > You might also benefit from adjusting these variables: > http://lists.alioth.debian.org/pipermail/nut-upsuser/2016-October/010352.html > though I would consider it a stop-gap measure. At some point, unless you have > many of the same model. the cost of the time to fiddle with it may exceed the > value of the UPS. Oh, that was exceeded _weeks_ ago. The customer for some reason wants this one. --scott ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] trouble building nut for HID-USB
> On Oct 12, 2016, at 2:00 PM, Dorsey, Scott B. (LARC-D316)[LITES II] > wrote: > > It does in fact show exactly what you describe. Udev is working properly > with the device file being assigned to group > dialout, which the nut user is in. You were correct about my having had to > install the libusb-devel kit to make 2.7.4 > build, but it does build properly and everything seems to be working well, > except that the driver only sometimes loads. > > About 25% of the time I get this: >> NUT Starting UPS model drivers: Network UPS Tools - UPS driver controller >> 2.7.4 >> Network UPS Tools - Generic HID driver 0.41 (2.7.4) >> USB communication driver 0.33 >> Using subdriver: TrippLite HID 0.82 > > and the rest of the time I get this: >> NUT Starting UPS model drivers: Network UPS Tools - UPS driver controller >> 2.7.4 >> Network UPS Tools - Generic HID driver 0.41 (2.7.4) >> USB communication driver 0.33 >> No matching HID UPS found >> Driver failed to start (exit status=1) In the latter case, does "lsusb" show the UPS, or is it gone from that list as well? > > Which, sadly, is the same problem I was having with 2.6.5, although I think > it is starting more often > with 2.7.4. It is very disturbing, though, to see something that only > sometimes works and I am not sure > how to diagnose it from this point. Of all of the bugs we've had in NUT over the years, the ones at this level are the most frustrating, because we can't add log statements to the code inside the UPS to see why it is dropping off the bus. It definitely seems correlated with NUT driver activity, but the same core driver works fine with other models and vendors. You might also benefit from adjusting these variables: http://lists.alioth.debian.org/pipermail/nut-upsuser/2016-October/010352.html though I would consider it a stop-gap measure. At some point, unless you have many of the same model. the cost of the time to fiddle with it may exceed the value of the UPS. > Also I had to write a new startup script to make 2.7.4 work with Centos > 6.8. It should work with all > Centos 6. Do you want a copy of it? I am not sure I can donate it but I > will see. I'm sure that other CentOS users would appreciate it, or at least some tips on how to reproduce the script. However, a while back, we (mostly) decided to stop shipping distro-specific files in the NUT source tree itself, and instead tried to work more closely with the maintainers of those distributions. The best way might be to file a feature request with CentOS for updating to NUT 2.7.4, and include whatever portion of the script that you can in that request. Wouldn't hurt to post a link back to this list to help others who want to upgrade. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] trouble building nut for HID-USB
It does in fact show exactly what you describe. Udev is working properly with the device file being assigned to group dialout, which the nut user is in. You were correct about my having had to install the libusb-devel kit to make 2.7.4 build, but it does build properly and everything seems to be working well, except that the driver only sometimes loads. About 25% of the time I get this: > NUT Starting UPS model drivers: Network UPS Tools - UPS driver controller > 2.7.4 > Network UPS Tools - Generic HID driver 0.41 (2.7.4) > USB communication driver 0.33 > Using subdriver: TrippLite HID 0.82 and the rest of the time I get this: > NUT Starting UPS model drivers: Network UPS Tools - UPS driver controller > 2.7.4 > Network UPS Tools - Generic HID driver 0.41 (2.7.4) > USB communication driver 0.33 > No matching HID UPS found > Driver failed to start (exit status=1) Which, sadly, is the same problem I was having with 2.6.5, although I think it is starting more often with 2.7.4. It is very disturbing, though, to see something that only sometimes works and I am not sure how to diagnose it from this point. Also I had to write a new startup script to make 2.7.4 work with Centos 6.8. It should work with all Centos 6. Do you want a copy of it? I am not sure I can donate it but I will see. --scott ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] trouble building nut for HID-USB
[please use Reply-All - this list does not modify the reply-to header.] > On Oct 10, 2016, at 8:53 AM, scott.b.dor...@nasa.gov wrote: > > I have a user running centos 6.8 with a brand new Tripplite HID (protocol > 4016) > UPS. So I installed nut 6.5 from EPEL and it sometimes worked, and it > sometimes didn't, and it seemed to be very inconsistent about loading the > device driver. Protocol 4016 is a new one for us. If you run "lsusb -d 09ae:", does it show something like this? (this is from a protocol 3016 unit) $ lsusb -d 09ae: Bus 006 Device 008: ID 09ae:3016 Tripp Lite Assuming nothing drastic has changed in this protocol, there are two places where the new protocol number needs to be added. The driver has a table of known protocol numbers (USB VendorID:ProductID pairs, really, but aside from PID 0001, Tripp Lite tends to keep the protocol numbers and ProductIDs in sync), but you can try adding the "-x productid=4016" command line option (or add "productid=4016" to ups.conf). The second place is in the udev configuration files. When the UPS is first plugged into the USB port, the system looks up the VID:PID (and possibly some more attributes) in the udev configuration directories (/lib/udev/rules.d and /etc/udev/rules.d, if it's similar to Debian's layout), and NUT adds a configuration file to change ownership of the device node to allow the unprivileged NUT driver to control the UPS. Probably the easiest test would be to reinstall the package, check for the udev file (named /lib/udev/rules.d/52-nut-usbups.rules[*] in Ubuntu 14.04) and add a line for your protocol number (copying the 3015 entry). Then you can run "udevadm trigger --subsystem-match=usb --action=change" as root to reload the new udev file. [*] yours might have 62 instead, which could also be part of the problem - the number needs to be lower in order to override some later-numbered rules. We're erring on the side of caution with the USB product IDs - in many cases, vendors have other random USB devices besides UPSes, so we don't just do a wildcard entry for everything with Tripp Lite's VendorID. Also, many Tripp Lite devices have what I would consider to be bugs in the HID descriptor, and so many values end up being reported in the wrong units (Hz*100 for frequency, microvolts for voltage measurements, etc.). When we add a product ID to the table, we also try to correct for the obvious typos. If this doesn't work, please save the logs and let us know what failed. > So, looking around and after spending some time looking at things that had > nothing to do with the real problem, I instead wiped the full install, > downloaded http://www.networkupstools.org/source/2.7/nut-2.7.4.tar.gz > and built it from source. > > The problem is, even if I do a ./configure --with-usb=yes I don't get any > usb drivers installed on the system. usbhid-ups is no where to be found. Centos probably comes with the runtime libraries for libusb installed by default, but you will also need libusb*-devel packages to build from source. We are finishing up testing a libusb-1.0 branch of NUT, and if you encounter problems with the 2.6.5 package (plus the configuration changes mentioned above), it might be worthwhile to test with the new branch. We haven't narrowed down the exact problem, but some combination of the following has been problematic: - TL Protocol 3016 - Server-class motherboards - Older Linux kernels (< 4.0?) - libusb-0.1 For some reason, our snapshots on Buildbot aren't being properly indexed by branch, but this build is what I am currently testing: http://buildbot.networkupstools.org/public/nut/builders/Debian-x64-gcc/builds/664 -- 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
