I think I have another lead: For the Powervar, lsusb gives: Bus 003 Device 002: ID 4234:0002 AMETEK-POWERVAR Corporation UPM UPS (v01.51, Nov 3 2018)
When running usbhid-ups from the command line, I get: 0.035977 [D2] - Bus: 003 0.035989 [D2] - Device: unknown So is it passing "unknown" as the device number to libusb instead of 002? On Wed, Feb 7, 2024, at 3:54 PM, Jason Doolittle wrote: > Hello, > > Thanks for your reply. > > Both of the services you mentioned ([email protected] and > [email protected]) were running. They were spamming syslog with > messages like the following: > 2024-02-07T14:29:27.704506-05:00 hostname nut-driver@PowervarUPS01[72162]: > Network UPS Tools - Generic HID driver 0.47 (2.8.0) > > 2024-02-07T14:29:27.704537-05:00 hostname nut-driver@PowervarUPS01[72162]: > USB communication driver (libusb 1.0) 0.43 > > 2024-02-07T14:29:27.704873-05:00 hostname nut-driver@PowervarUPS01[72161]: > Driver failed to start (exit status=1) > > 2024-02-07T14:29:32.718262-05:00 hostname nut-driver@PowervarUPS01[72167]: > Can't claim USB device [4234:0002]@1/0: Invalid parameter > > 2024-02-07T14:29:32.718386-05:00 hostname nut-driver@PowervarUPS01[72167]: > Network UPS Tools - Generic HID driver 0.47 (2.8.0) > > 2024-02-07T14:29:32.718422-05:00 hostname nut-driver@PowervarUPS01[72167]: > USB communication driver (libusb 1.0) 0.43 > > 2024-02-07T14:29:32.718684-05:00 hostname nut-driver@PowervarUPS01[72161]: > Driver failed to start (exit status=1) > > 2024-02-07T14:29:32.718829-05:00 hostname nut-driver@APCUPS01[72166]: Can't > claim USB device [051d:0002]@1/0: Invalid parameter > > > After stopping those services I ran the driver again from the CLI with the > same result. That "Invalid parameter" is conspicuous. I haven't seen it in > anyone else's questions or answers. The only place i've seen it in relation > to this problem is in libusb1.c (on github), but not in a way that makes it > obvious how to track down the cause. I suspect some sort of version or > parameter mismatch somewhere in libusb, but I have no idea how to test for > that. > > > On Wed, Feb 7, 2024, at 12:57 PM, Jim Klimov wrote: >> Hello and welcome! >> >> My guess would be that a nut-driver service unit (or instances thereof >> since NUT v2.8.0, monolithic before) have started and captured the devices, >> so your attempts with another copy of the driver started from CLI fail at >> that. Normally drivers detect an older sibling running (by poking a PID >> file), but service units may forgo creation of one. (Since 2.8.1 they can >> also try to use driver-server protocol locally.) >> >> Since NUT v2.8.0 there is a nut-driver-enumerator (script and service) >> which manages creation, deletion and reloading/restarting of unit instances >> based on ups.conf contents (start-up) or changes (run-time). Check if you >> have `[email protected]` (and `...@APCUPS01`) there to fit >> this bill? If yes, then to experiment with CLI copies of drivers, `systemctl >> stop` such unit(s). >> >> Hope this helps, >> Jim Klimov >> >> >> On Wed, Feb 7, 2024, 14:48 Jason Doolittle <[email protected]> >> wrote: >>> I am working in Ubuntu Linux on a Raspberry Pi 5. Nut is unable to connect >>> to USB UPSs. >>> >>> uname -srvmpio >>> Linux 6.5.0-1009-raspi #12-Ubuntu SMP PREEMPT_DYNAMIC Wed Jan 17 11:45:08 >>> UTC 2024 aarch64 aarch64 aarch64 GNU/Linux >>> >>> Current Installed version of nut is 2.8.0-7 installed with apt >>> >>> apt-cache policy nut >>> nut: >>> Installed: 2.8.0-7 >>> Candidate: 2.8.0-7 >>> Version table: >>> *** 2.8.0-7 500 >>> 500 http://ports.ubuntu.com/ubuntu-ports mantic/main arm64 Packages >>> 100 /var/lib/dpkg/status >>> >>> I currently have 2 UPSs connected to the system >>> A Powervar UPM UPS >>> Bus 003 Device 002: ID 4234:0002 AMETEK-POWERVAR Corporation UPM UPS >>> (v01.51, Nov 3 2018) >>> >>> An APC Back-UPS Pro 1500 >>> Bus 001 Device 002: ID 051d:0002 American Power Conversion Uninterruptible >>> Power Supply >>> >>> It appears that the all of the permissions were set up correctly during >>> installation. The nut user and group were created and the usb devices have >>> the correct ownership and permissions set per the udev rules >>> >>> For the Powervar: >>> crw-rw-r-- 1 root nut 189, 257 Feb 7 06:42 /dev/bus/usb/003/002 >>> >>> For the APC: >>> crw-rw-r-- 1 root nut 189, 1 Feb 7 06:42 /dev/bus/usb/001/002 >>> >>> In ups.conf, I have this: >>> >>> [PowervarUPS01] >>> driver = "usbhid-ups" >>> port = "auto" >>> vendorid = "4234" >>> productid = "0002" >>> >>> [APCUPS01] >>> driver = "usbhid-ups" >>> port = "auto" >>> vendorid = "051D" >>> productid = "0002" >>> >>> The UPSs are matched, but drivers continuously fail to start. Here is the >>> output from running the usbhid-ups driver manually for the Powervar: >>> >>> sudo /usr/lib/nut/usbhid-ups -u root -a PowervarUPS01 -DD >>> >>> Network UPS Tools - Generic HID driver 0.47 (2.8.0) >>> USB communication driver (libusb 1.0) 0.43 >>> 0.000000 [D1] debug level is '2' >>> 0.001191 [D2] Initializing an USB-connected UPS with library >>> libusb-1.0.26 (API: 0x1000109) (NUT subdriver name='USB communication >>> driver (libusb 1.0)' ver='0.43') >>> 0.001209 [D1] upsdrv_initups (non-SHUT)... >>> 0.006358 [D2] Checking device 1 of 6 (1D6B/0003) >>> 0.006385 [D1] Failed to open device (1D6B/0003), skipping: Access denied >>> (insufficient permissions) >>> 0.006393 [D2] Checking device 2 of 6 (4234/0002) >>> 0.007354 [D2] - VendorID: 4234 >>> 0.007364 [D2] - ProductID: 0002 >>> 0.007371 [D2] - Manufacturer: AMETEK-POWERVAR Corporation >>> 0.007378 [D2] - Product: UPM UPS (v01.51, Nov 3 2018) >>> 0.007385 [D2] - Serial Number: 5008094R-1940438 >>> 0.007395 [D2] - Bus: 003 >>> 0.007402 [D2] - Device: unknown >>> 0.007409 [D2] - Device release number: 0002 >>> 0.007418 [D2] Trying to match device >>> 0.007425 [D2] match_function_subdriver (non-SHUT mode): matching a >>> device... >>> 0.007485 [D2] Device matches >>> 0.007497 [D2] Reading first configuration descriptor >>> 0.007505 [D2] result: -5 (Entity not found) >>> 0.007517 [D2] failed to claim USB device: Entity not found >>> 0.007529 [D1] failed to detach kernel driver from USB device: Invalid >>> parameter >>> 0.007539 [D2] failed to claim USB device: Entity not found >>> 0.007549 [D1] failed to detach kernel driver from USB device: Invalid >>> parameter >>> 0.007560 [D2] failed to claim USB device: Entity not found >>> 0.007574 [D1] failed to detach kernel driver from USB device: Invalid >>> parameter >>> 0.007582 [D2] failed to claim USB device: Entity not found >>> 0.007594 [D1] failed to detach kernel driver from USB device: Invalid >>> parameter >>> 0.007604 Can't claim USB device [4234:0002]@1/0: Invalid parameter >>> >>> I get basically the same from the APC. >>> >>> I think the "failed to detach kernel driver from USB device: Invalid >>> parameter" is the key here, especially the "Invalid parameter" part, but >>> after a few hours of poking at things, I haven't made any progress. >>> >>> I would be eternally grateful if someone could point me in the right >>> direction. >>> >>> _______________________________________________ >>> Nut-upsuser mailing list >>> [email protected] >>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser > > _______________________________________________ > Nut-upsuser mailing list > [email protected] > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser > -- Jason Doolittle Facility Engineer [email protected] | 813 918-6157
_______________________________________________ Nut-upsuser mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
