Possible Issue With 14.2 MultiLib /user/lib vs/ /usr/lib64 for USB Connected UPS

enorbet · 06-26-2019, 03:03 PM

I have a CyperPower UPS which employs an app and daemon for PowerPanel that allows for functional configuring, testing and status reports with that UPS. Mine is connected to my PC via USB. The app is installed via a simple "install.sh" script and though it has specific script components for Arch, Debian, RedHat and Suse it has a generic script, too. The reason for this thread is that communication now fails in Slackware Multilib but doesn't in a test install of Debian. Here's some specifics.

Here's the problem----

Code:

bash-4.3# pwrstat -status

The UPS information shows as following:

        Properties:
                Model Name................... LX1500GU
                Firmware Number.............. QAKEX2000274
                Rating Voltage............... 120 V
                Rating Power................. 900 Watt(1500 VA)

        Current UPS status:
                State........................ Lost Communication
                Test Result.................. Failed at 2019/06/26 14:19:22
                Last Power Event............. None

The owners manual states this...

Code:

2. Can not establish communication with UPS
a. Ensure UPS type is supported by PowerPanel for Linux..........................(check)
b. Ensure USB or Serial cable is connected between UPS and computer.
Directly connect computer and UPS without USB Hub is helpful to solve if
which have communication problem...............................................(check)
c. Try to unplug and plug the USB Cable with UPS.
d. Ensure hid device can be found at directory of /dev/hiddev,
/dev/usb/hiddev, /dev/usb/hid/hiddev such as 'hiddev0' if UPS is
connected by USB cable. Ensure hid device can be found at directory of
/dev such as ttyS0 if UPS is connected by serial cable.........................(check)
e. Ensure Linux kernel version is more than 2.4.22 or 2.6. Ensure kernel
module 'usbhid.ko' is loaded on system in kernel 2.4 and 'hid.o' in
kernel 2.6......................................................................(check)
.....................
5.The pwrstatd daemon can not detect the UPS which has H2C USB adapter.
a. Ensure linux system have libusb library. It can be found at /usr/lib
directory................................................(possible Multilib issue?)
b. Ensure the libusb soname is libusb-0.1.so.4......................................(check)
c. If libusb soname version is less than libusb-0.1.so.4, please go to
'rpmfind' or 'sourceforge' web site download the libusb rpm package
and install it. The 'rpmfind' and 'sourceforge' download web site are
shows as below:
*rpmfind web site, http://rpmfind.net
*sourceforge web site, http://sourceforge.net.....................................(check)

A further conundrum besides that it works in Debian is that it also did work on my Main (for years before it died) which is also 14.2 MultiLib though an earlier software version. No searching has discovered any reason why version should be a problem, and rather than spend too much time on the past success, and considering this new version does work on Debian, think I need to focus on current failure and solution.

Bottom line I don't know how to determine why communication via USB has any problems or specifically what those problems might be that are so obviously a software issue. That I get a status report says some communication is working but that it fails the test (and that it beeps every few seconds in alarm) in Slackware says something isn't ideal (intermittent in only one OpSys?) naturally concerns me and I need resolution.

Suggestions Please.

NOTE: I am a bit exhausted from nonstop scrambling to deploy an old single core machine until I can replace the mobo on my main so please forgive me if this is just a silly mistake.

BW-userx · 06-27-2019, 10:41 AM

I do not run a 32bit multi slack but taking into consideration you are running a script, I believe you did not write, but can still open and be looked at and modified to give you output.

I'd find where it should be checking for or where it is using that libusb and depending on what it is doing with it, add a check of your own to output what libusb is is trying to use that maybe causing this to fail then hopefully that will give you a starting point to what else to look into from there.

trite · 06-27-2019, 12:22 PM

DISCLAMER: I have no idea what I'm talking about xD

Code:

 
  Repetitive timeout and staleness
       Some models tends to be unresponsive with the default polling frequency. The result is
       that your system log will have lots of messages like:

           usb 2-1: control timeout on ep0in
           usb 2-1: usbfs: USBDEVFS_CONTROL failed cmd usbhid-ups rqt 128 rq 6 len 256
           ret -110

       In this case, simply modify the general parameter "pollinterval" to a higher value (like
       10 for 10 seconds). This should solve the issue.

Have you checked something like that?

Also BW-userx's suggestion on trying to get some output is interesting.

enorbet · 06-27-2019, 03:16 PM

Quote:

Originally Posted by trite

DISCLAMER: I have no idea what I'm talking about xD

Code:

 
  Repetitive timeout and staleness
       Some models tends to be unresponsive with the default polling frequency. The result is
       that your system log will have lots of messages like:

           usb 2-1: control timeout on ep0in
           usb 2-1: usbfs: USBDEVFS_CONTROL failed cmd usbhid-ups rqt 128 rq 6 len 256
           ret -110

       In this case, simply modify the general parameter "pollinterval" to a higher value (like
       10 for 10 seconds). This should solve the issue.

Have you checked something like that?

Also BW-userx's suggestion on trying to get some output is interesting.

Thank you, trite. I'm unusually foggy from extreme stress and lack of sleep from trying to put this old, semi-retired PC in shape after a mystifying and somewhat catastrophic failure of my MAIN which intermittently fails to post and finally stopped altogether giving me a beep code that I know is incorrect.

I completely blanked on looking to syslog or dmesg, thinking I needed some USB specific query to see what's going on. This has been confusing since I can verify that my UPS communicates intermittently via USB or I wouldn't even get a status report or be able to get anything from "pwrstat -test" but then getting the "lost communication" error. It would be vastly easier if it was simply On or Off.

Your response prompted me to look at dmesg and I did get some results, albeit still as bit confusing, but it may explain why there were no problems on my MAIN which has USB 3.0 which still strikes me as a bit odd considering the UPS docs only call for a "kernel greater than 2.6.x" which iirc was around for late versions of USB 1.0.

Whatever here is a sample of output for "dmesg | grep usb". It's only a sample because it is HUGE. Apparently the exact same device keeps getting assigned a new device number each time the communication halts and just goes on endlessly. I had wondered if by looking in "/usr/lib/" for libusb.so it is wrongfully getting the 32 bit version since this is a multilib system.

Code:

[72768.546897] usb 2-10: USB disconnect, device number 118
[72768.830022] usb 2-10: new full-speed USB device number 119 using ohci-pci
[72769.048358] usb 2-10: New USB device found, idVendor=0764, idProduct=0501
[72769.048361] usb 2-10: New USB device strings: Mfr=3, Product=1, SerialNumber=2
[72769.048362] usb 2-10: Product: LX1500GU
[72769.048363] usb 2-10: Manufacturer: CPS
[72769.048364] usb 2-10: SerialNumber: QAKEX2000274
[72769.062945] hid-generic 0003:0764:0501.2359: hiddev96,hidraw0: USB HID v1.10 Device [CPS LX1500GU] on usb-0000:00:02.0-10/input0
[72776.546994] usb 2-10: USB disconnect, device number 119
[72776.833024] usb 2-10: new full-speed USB device number 120 using ohci-pci
[72777.051554] usb 2-10: New USB device found, idVendor=0764, idProduct=0501
[72777.051557] usb 2-10: New USB device strings: Mfr=3, Product=1, SerialNumber=2
[72777.051558] usb 2-10: Product: LX1500GU
[72777.051559] usb 2-10: Manufacturer: CPS
[72777.051560] usb 2-10: SerialNumber: QAKEX2000274
[72777.071800] hid-generic 0003:0764:0501.235A: hiddev96,hidraw0: USB HID v1.10 Device [CPS LX1500GU] on usb-0000:00:02.0-10/input0
[72784.547042] usb 2-10: USB disconnect, device number 120
[72784.994029] usb 2-10: new full-speed USB device number 121 using ohci-pci
[72785.214354] usb 2-10: New USB device found, idVendor=0764, idProduct=0501
[72785.214357] usb 2-10: New USB device strings: Mfr=3, Product=1, SerialNumber=2
[72785.214358] usb 2-10: Product: LX1500GU
[72785.214359] usb 2-10: Manufacturer: CPS
[72785.214360] usb 2-10: SerialNumber: QAKEX2000274
[72785.228950] hid-generic 0003:0764:0501.235B: hiddev96,hidraw0: USB HID v1.10 Device [CPS LX1500GU] on usb-0000:00:02.0-10/input0
[72792.547121] usb 2-10: USB disconnect, device number 121
[72792.833024] usb 2-10: new full-speed USB device number 122 using ohci-pci
[72793.051356] usb 2-10: New USB device found, idVendor=0764, idProduct=0501
[72793.051359] usb 2-10: New USB device strings: Mfr=3, Product=1, SerialNumber=2
[72793.051360] usb 2-10: Product: LX1500GU
[72793.051361] usb 2-10: Manufacturer: CPS
[72793.051363] usb 2-10: SerialNumber: QAKEX2000274
[72793.065928] hid-generic 0003:0764:0501.235C: hiddev96,hidraw0: USB HID v1.10 Device [CPS LX1500GU] on usb-0000:00:02.0-10/input0
[72800.547245] usb 2-10: USB disconnect, device number 122
[72800.834045] usb 2-10: new full-speed USB device number 123 using ohci-pci
[72801.052419] usb 2-10: New USB device found, idVendor=0764, idProduct=0501
[72801.052422] usb 2-10: New USB device strings: Mfr=3, Product=1, SerialNumber=2
[72801.052423] usb 2-10: Product: LX1500GU
[72801.052425] usb 2-10: Manufacturer: CPS
[72801.052426] usb 2-10: SerialNumber: QAKEX2000274
[72801.067021] hid-generic 0003:0764:0501.235D: hiddev96,hidraw0: USB HID v1.10 Device [CPS LX1500GU] on usb-0000:00:02.0-10/input0

If default polling rate were to be the problem how do I change that even just for testing? I have compared the working debian kernel config to the one I'm using for Slackware since I am curious as to why a USB device has defaulted to OHCI. IIRC EHCI or better should be being used, but I'm on not well-known ground here.

I'll hunt around later as i am exhausted right now but thanks for your response at least I have some actual data to consider.

NAOTE: I've been wondering if there is some way to point the daemon to "/usr/lib64/" even if just to test it? I don't see an applicable line in the .conf file so if there is a way I'd have to add it to override the fefault.

trite · 06-27-2019, 04:06 PM

Well I guess the easiest way to only have 64-bit is to not have multilib packages installed.

There doesn't seem to be any specific errors in your dmesg.

Does the version of libusb*so differ fron debian to Slackware?

I have these ones:

Code:

-rwxr-xr-x   1 root root   98K apr 15  2018 libusb-1.0.so.0.1.0
-rwxr-xr-x   1 root root   18K feb 20 08:26 libusb-0.1.so.4.4.4
lrwxrwxrwx   1 root root    19 apr  6 22:15 libusb-0.1.so.4 -> libusb-0.1.so.4.4.4
lrwxrwxrwx   1 root root    19 jun 24 20:18 libusb-1.0.so -> libusb-1.0.so.0.1.0
lrwxrwxrwx   1 root root    19 jun 24 20:18 libusb-1.0.so.0 -> libusb-1.0.so.0.1.0

The documentation metions "libusb-0.1.so.4" maybe you have to have that specific version?

If so maybe you can symlink it to that version, prob. would b0rk(tm) something else but yeah

enorbet · 06-27-2019, 04:06 PM

Dammit! I can't sleep with my brain churning incessantly so here's what I'm trying to do.

I had hoped "evhz" could be directed to a different device than the mouse but if it can I haven't discovered it. So I've been searching out USB polling rate info and so far all I can find in any depth is in the Arch wiki here

https://wiki.archlinux.org/index.php/Mouse_polling_rate

Despite being labelled MOUSE Polling Rate it goes into any USB device. I found this interesting

Quote:

Originally Posted by archwiki

$ lsusb

Bus 001 Device 002: ID 045e:0024 Microsoft Corp. Trackball Explorer
Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

Then run the following as root with those IDs to display the debug information for that device:

# grep -B3 -A6 045e.*0024 /sys/kernel/debug/usb/devices

T: Bus=01 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=1.5 MxCh= 0
D: Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
P: Vendor=045e ProdID=0024 Rev= 1.21
S: Manufacturer=Microsoft
S: Product=Microsoft Trackball Explorer®
C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=01 Prot=02 Driver=usbhid
E: Ad=81(I) Atr=03(Int.) MxPS= 4 Ivl=10ms

The Ivl is the polling interval; this device has requested 10ms (and actually reports every 8ms as explained in #Polling rate and polling interval). The Spd is the device speed explained in #USB device speed. For information about the other fields see the kernel documentation.

USB device speed

USB devices are designed to operate at a certain bitrate. Many pointing devices are "Low Speed" 1.5Mbit/s devices. The speed of a device can be shown as explained in #Display polling interval.

"Low Speed" devices may not be capable of polling at intervals less than 8ms.

All USB hubs should be capable of at least "Full Speed" 12Mbit/s. The speed of the hub that the device is attached to can be shown with the following command with the same Bus=xx as the device:

# grep -B1 -A10 "Bus=01 Lev=00" /sys/kernel/debug/usb/devices

T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2
B: Alloc= 11/900 us ( 1%), #Int= 1, #Iso= 0
D: Ver= 1.10 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=1d6b ProdID=0001 Rev= 4.01
S: Manufacturer=Linux 4.1.18-1-lts uhci_hcd
S: Product=UHCI Host Controller
S: SerialNumber=0000:00:10.0
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub
E: Ad=81(I) Atr=03(Int.) MxPS= 2 Ivl=255ms

I tried this substituting the UPS numbers of course but it returns a "can't find" error. Perhaps Arch and Slackware locations vary, eh?

Code:

  
bash-4.3# grep -B3 -A6 0764:0501 /sys/kernel/debug/usb/devices
grep: /sys/kernel/debug/usb/devices: No such file or directory

Sigh... once more into the breach...

enorbet · 06-27-2019, 06:49 PM

I think I need to wait before I write here again because I am forgetting the most obvious things. I forgot that ldd reports the full path to libraries linked to any executable and as there are only two of those, the app and the daemon, it was easy to see they both find "/usr/lib64A" just fine. AI'd change the thread title but I don't yet know what to change it to. Soon...I hope.

Richard Cranium · 06-27-2019, 09:55 PM

I used the nut package from slackbuilds to manage my CP1500 AVR UPS. (I had to patch /etc/rc.d/rc.0 to properly shutdown, however.)

I'm not multi-lib, so that probably wasn't of any help.

enorbet · 06-28-2019, 09:05 AM

Thanks guys. I don't understand why even that USB port worked in other systems and not Slackware but switching around to a different port seems to have satisfied Slackware. I'm just scrambling to have some semblance of a working PC until I repair my main which appears to be a few weeks off yet. It's just so hard being in the conundrum of no new boards supporting LGA 1155, making old ones hard to find and expensive on one hand, and the prospect not only of the expense of a whole new system but also essentially throwing away a lot of gear that is still really good.

Please excuse my whining.... haven't slept much in four days.