[Nut-upsuser] I/O errors with usbhid-ups and Tripp Lite SMART1500LCDT

Charles Lepple clepple at gmail.com
Mon Oct 26 01:24:04 UTC 2015


On Oct 25, 2015, at 8:33 PM, Null <null at wuffleton.com> wrote:
> 
> On 2015-10-23 5:42, Charles Lepple wrote:
>> I'm not really sold on this approach (due to the testing needed on other hardware), but this pull request reworks the USB communication so that the interface is only claimed while it is being polled:
>> 
>>    https://github.com/networkupstools/nut/pull/122
>> 
>> Even though Github is reporting a potential merge conflict, it should be possible to check out that branch, and see if the driver is more stable in that version.
>> 
>> If nothing else, there are some value scaling fixes for this model in that pull request. The HID descriptor in this UPS is a bit of a mess. (6kHz Hz power would be... interesting.)
> 
> The driver seems to be much more stable in this branch. I'm able to get the driver up and running on the first shot, and it's been up for at least a few hours now without any issues. The scaling fixes also definitely work, since I'm seeing sane values for everything when I use upsc to query the UPS.

Did you have to reset the UPS once you switched to this branch, or did it just start working with the new driver?

I'm starting to look at the potential merge conflicts. In the master branch (also part of 2.7.3) we stopped calling usb_set_altinterface() by default. Can you check if things are still stable on the pull/122 branch when you comment out that call in drivers/libusb.c?

   https://github.com/sbutler/nut/commit/3ce3bcd6e5f63e681cbcc4a570c26af84ab0268a#diff-b6035167573569c50fc257cb06d1fed3R106

I think I understand some of that pull request a bit better now. I really don't want to change the driver semantics so drastically (such as letting the driver start up without successfully attaching to an UPS), but delaying the "claim interface" operation might be necessary for this UPS.

> 
> On 2015-10-24 19:25, Charles Lepple wrote:
>> I'm starting to think this is motherboard-dependent. I now have the SMART1500LCDT plugged into a HP Z800 (Xeon 5xxx) motherboard on Debian jessie (also 3.16, but might be slightly different than the other box), and it is disconnecting frequently. (The stable system is a Dell Core i5.)
> 
> Seeing as the Dell C2100 server I'm running it with has a very similar chipset to the Z800 (Intel 5500 vs 5520, which lspci considers to be effectively the same), I wouldn't rule this out. So we've got a couple more samples with different chipsets and this model of UPS, I'll test it against my Haswell i3 laptop, and my Raspberry Pi2 later this week to see if they behave any differently against the current master branch.

I have been running the master branch on a Raspberry Pi (Model B) for a few hours to rule out any potential cable problems on my end.

-- 
Charles Lepple
clepple at gmail






More information about the Nut-upsuser mailing list