[Nut-upsdev] Fixing Drops With SMART1500LCDXL & USB-HID Driver

Manuel Wolfshant wolfy at nobugconsulting.ro
Tue Jun 18 04:17:43 BST 2019


On 6/18/19 5:27 AM, Charles Lepple wrote:
> On Jun 17, 2019, at 3:00 PM, David Zomaya <David_Zomaya at tripplite.com> wrote:
>> Hi Network UPS Tools Support,
>>   
>> I’m not sure if this is a question for the “user group” or the developer group”.
> The config files will be useful for -users, but I'd say the development list is probably better for discussing potential changes.
>   
>> My name is David Zomaya and I work at Tripp Lite in our technical support department. Copied on this email are Eric Cobb from our Product Management group & Jonathan Manzanilla tech support subject matter expert for our single phase UPS product lines.
> I recognize Eric's name from a few years ago - he emailed some detailed test results with NUT connecting to various Tripp-Lite models. Hi, Eric!
>
>> Recently, we received a complaint about our SMART1500LCDXL dropping and reconnecting in different Linux Operating Systems.A fter some in-house testing, the behavior seems to be reproducible on a number of different *nix operating systems (Windows seems fine). Here’s an example of the drops in /var/log/messages (I’ll use CentOS 7.6 as my reference point throughout this email):
>> May 29 19:25:27 localhost kernel: usb 2-2.1: new low-speed USB device number 6 using uhci_hcd
>> May 29 19:25:27 localhost kernel: usb 2-2.1: New USB device found, idVendor=09ae, idProduct=2012
>> May 29 19:25:27 localhost kernel: usb 2-2.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
> This is a little off-topic, but I would like to point out that not including a machine-readable serial number in the USB device descriptor makes it difficult for people to reliably use two or more UPSes on a single *nix system. Due to some complications with the way that USB devices are opened in libusb, there is no easy way to "open the next unused USB device", so we recommend that people match against the serial number.
>
>> May 29 19:25:27 localhost kernel: usb 2-2.1: Product: Tripp Lite UPS
>> May 29 19:25:27 localhost kernel: usb 2-2.1: Manufacturer: Tripp Lite
>> May 29 19:25:27 localhost kernel: hid-generic 0003:09AE:2012.0004: hiddev0,hidraw1: USB HID v1.10 Device [Tripp Lite  Tripp Lite UPS ] on usb-0000:02:02.0-2.1/input0
>> May 29 19:25:29 localhost upsd[6287]: UPS [TrippLiteUPS] data is no longer stale
>> May 29 19:25:29 localhost upsd: UPS [TrippLiteUPS] data is no longer stale
>> May 29 19:25:45 localhost kernel: usb 2-2.1: USB disconnect, device number 6
> It would be interesting to see the debug log from usbhid-ups as well. It would give a little more context to the kernel errors. I haven't used a physical CentOS or RedHat system in a while, so I am not sure of the specifics needed to just stop the usbhid-ups driver, but then you can restart it with a few "-D" flags (3 should be sufficient for this kind of problem) and "-a TrippLiteUPS" to match this configuration. Please compress any log files (gzip preferred; zip works).
>
>> As a result, this impacted the user’s ability use NUT software on their Linux hosts. After some trial and error (and a lot of search engine use), I was able to find that the following configuration changes/settings stop the drops and stabilize performance:
>> 1)      This in the ups.conf file
>> pollinterval = 1
> pollinterval defaults to 2, and to be honest, for most other UPSes, we suggest that people raise the value (since many UPSes do not update their filtered values more frequently than that anyway). Do you know how frequently the Windows software polls the UPS? Should this be applied to other models as well, or just protocol 2012?
>
>> [TrippLiteUPS]
>>      driver = usbhid-ups
>>      port = auto
>>      desc = "SMART1500LCD"
>> 2)      The attached 62-nut-usbups.rules file at /etc/udev/rules.d/
>> 3)      The attached 42-usb-hid-pm.rules /usr/lib/udev/rules.d/
> The 62-nut-usbups.rules file looks pretty standard. Do you know if the changes to 42-usb-hd-pm.rules are needed? It seems like none of the USB devices would have the right permissions if 62-nut-usbups.rules isn't sufficient (though this happened in Debian once).
>
>>   
>> Below is some other information that may be relevant regarding my testing.
>>   
>> ·         I installed using the command “yum install nut.x86_64”
>>   
>> ·         Operating system version:
>> CentOS Linux release 7.6.1810 (Core)
>>   
>> ·         Network UPS Tools version
>> Network UPS Tools upsd 2.7.2
> Note that NUT 2.7.4 has been out for some time now.

While version 2.7.4 was packaged and is available for Fedora, the 
packages shipped by EPEL ( which is what David used for his testing) for 
CentOS 7 were not updated past 2.7.2

If useful for testing I can try to rebuild for CentOS 7 the Fedora 
packages (*) (**) but a better long term approach would be if someone 
opened a ticket at bugzilla.redhat.com ( => EPEL => nut )  and asked for 
that update. I could do that but I think that a request coming from an 
UPS manufacturer would probably have more weight than one incoming from 
a random user.


(*) and I can also include the 2 udev files, if needed and instructed to 
do that

(**) the resulting packages would end at 
https://wolfy.fedorapeople.org/nut/?C=M;O=D ( and anyone using them 
should, obviously, trust my packaging :) ) For those who do not trust, 
just google me.


wolfy






More information about the Nut-upsdev mailing list