[Nut-upsuser] Question on EATON UPS
Jim Klimov
jimklimov+nut at gmail.com
Sat Mar 25 09:13:42 GMT 2023
Also, just in case - are you in a virtualized environment? Is there
(intentional or not) USB pass-through to the UPSes? My hint is, we had
cases where a host or guest grabbed the device but it was not apparent from
the part of system running NUT.
Jim
On Fri, Mar 24, 2023, 23:23 Jim Klimov <jimklimov+nut at gmail.com> wrote:
> Sounds like some other program is holding the port. Have you stopped other
> NUT drivers for the device (e.g. via auto-resuscitating services) before
> starting this one? Does udev, ugen or similar facility have the
> configuration to hand off this device to NUT run-time user? (BTW, if you
> are now testing a custom build - was it configured to use same accounts as
> pre-packaged variant)?
>
> On Fri, Mar 24, 2023, 18:46 Laurent Taieb <laurenttaieb at free.fr> wrote:
>
>> Hi Jim,
>>
>> I have 2 drivers which have launched well connecting 2 APC UPS (both with
>> usbhid-ups)
>>
>> They have both bus & serial set.
>>
>> The Eaton is the third one. I have removed serial and bus from the
>> configuration.
>>
>>
>>
>> driver : usbhid-ups
>>
>> port = auto
>>
>> vendorid = 0463
>>
>> productid = ffff
>>
>> pollonly
>>
>>
>>
>> I have highlighted the errors while launching the driver:
>>
>>
>>
>> 0.039057 [D2] Checking device 4 of 10 (214B/7250)
>>
>> 0.039099 [D1] Failed to open device (214B/7250), skipping:
>> Access denied (insufficient permissions)
>>
>> 0.039109 [D2] Checking device 5 of 10 (0463/FFFF)
>>
>> 0.956144 [D1] nut_libusb_open get iManufacturer failed,
>> retrying...
>>
>> 0.956518 [D1] nut_libusb_open get iManufacturer failed,
>> retrying...
>>
>> 0.956836 [D1] nut_libusb_open get iManufacturer failed,
>> retrying...
>>
>> 0.957291 [D1] nut_libusb_open get iProduct failed, retrying...
>>
>> 0.957708 [D1] nut_libusb_open get iProduct failed, retrying...
>>
>> 0.958098 [D1] nut_libusb_open get iProduct failed, retrying...
>>
>> 0.958135 [D2] - VendorID: 0463
>>
>> 0.958184 [D2] - ProductID: ffff
>>
>> 0.958207 [D2] - Manufacturer: unknown
>>
>> 0.958254 [D2] - Product: unknown
>>
>> 0.958274 [D2] - Serial Number: unknown
>>
>> 0.958297 [D2] - Bus: 002
>>
>> 0.958372 [D2] - Device: unknown
>>
>> 0.958391 [D2] - Device release number: 0001
>>
>> 0.958432 [D2] Trying to match device
>>
>> 0.958475 [D2] match_function_subdriver (non-SHUT mode):
>> matching a device...
>>
>> 0.958505 [D3] match_function_regex: matching a device...
>>
>> 0.958605 [D2] Device matches
>>
>> 0.958636 [D2] Reading first configuration descriptor
>>
>> 0.958682 [D3] libusb_kernel_driver_active() returned 1 (driver
>> active)
>>
>> 0.958715 [D2] successfully set kernel driver auto-detach flag
>>
>> 0.961730 [D2] Claimed interface 0 successfully
>>
>> 0.961788 [D3] nut_usb_set_altinterface: skipped
>> libusb_set_interface_alt_setting(udev, 0, 0)
>>
>> 0.962067 [D2] Unable to get HID descriptor (Pipe error)
>>
>> 0.962127 [D3] HID descriptor length (method 1) -1
>>
>> 0.962169 [D3] HID descriptor, method 2: (9 bytes) => 09 21 10
>> 01 21 01 22 e1 01
>>
>> 0.962201 [D3] HID descriptor length (method 2) 481
>>
>> 0.962309 [D2] HID descriptor length 481
>>
>> 0.962697 [D2] Unable to get Report descriptor: Resource
>> temporarily unavailable
>>
>> …
>>
>> 0.963687 [D2] libusb1: No appropriate HID device found
>>
>> 0.963784 libusb1: Could not open any HID devices: insufficient
>> permissions on everything
>>
>> 0.963810 No matching HID UPS found
>>
>>
>>
>>
>>
>> Thanks for your help.
>>
>> Laurent
>>
>>
>>
>>
>>
>> *De : *Jim Klimov <jimklimov+nut at gmail.com>
>> *Date : *jeudi 23 mars 2023 à 22:44
>> *À : *"laurenttaieb at free.fr" <laurenttaieb at free.fr>
>> *Cc : *nut-upsuser Mailing List <nut-upsuser at lists.alioth.debian.org>
>> *Objet : *Re: [Nut-upsuser] Question on EATON UPS
>>
>>
>>
>> The "unknown" fields mean the driver did not get that piece of
>> information from libusb. In case of Manufacturer/Product which are unknown
>> in the later post, but known in the first, I suppose you had another driver
>> running, or the kernel still owned it (udev misbehavior, not handing it off
>> after reconnections, etc.) and so exclusive access was not given to the new
>> (currently reporting) process.
>>
>>
>>
>> The "Device" matching specifically had a problem fixed in the master
>> branch a few months ago. You can try to comment it away from your ups.conf
>> for a quick workaround, and match by remaining fields (assuming their
>> values are correct).
>>
>>
>>
>> Hope this helps,
>>
>> Jim Klimov
>>
>>
>>
>> On Thu, Mar 9, 2023 at 7:51 PM Laurent Taieb via Nut-upsuser <
>> nut-upsuser at alioth-lists.debian.net> wrote:
>>
>> Thanks Larry,
>>
>> I tried.
>>
>> Got the following traces and the driver doesn’t start.
>>
>>
>>
>> 1.036797 [D2] - VendorID: 0463
>>
>> 1.036812 [D2] - ProductID: ffff
>>
>> 1.036826 [D2] - Manufacturer: unknown
>>
>> 1.036840 [D2] - Product: unknown
>>
>> 1.036872 [D2] - Serial Number: unknown
>>
>> 1.036912 [D2] - Bus: 002
>>
>> 1.036942 [D2] - Device: unknown
>>
>> 1.036965 [D2] - Device release number: 0001
>>
>> 1.036980 [D2] Trying to match device
>>
>> 1.037008 [D2] match_function_subdriver (non-SHUT mode): matching
>> a device...
>>
>> 1.037044 [D3] match_function_regex: matching a device...
>>
>> 1.037102 [D2] Device matches
>>
>> 1.037131 [D2] Reading first configuration descriptor
>>
>> 1.037187 [D3] libusb_kernel_driver_active() returned 1 (driver
>> active)
>>
>> 1.037220 [D2] successfully set kernel driver auto-detach flag
>>
>> 1.040994 [D2] Claimed interface 0 successfully
>>
>> 1.041063 [D3] nut_usb_set_altinterface: skipped
>> libusb_set_interface_alt_setting(udev, 0, 0)
>>
>> 1.041438 [D2] Unable to get HID descriptor (Pipe error)
>>
>> 1.041480 [D3] HID descriptor length (method 1) -1
>>
>> 1.041530 [D3] HID descriptor, method 2: (9 bytes) => 09 21 10 01
>> 21 01 22 e1 01
>>
>> 1.041566 [D3] HID descriptor length (method 2) 481
>>
>> 1.041605 [D2] HID descriptor length 481
>>
>> 1.041926 [D2] Unable to get Report descriptor: Resource
>> temporarily unavailable
>>
>>
>>
>> Any idea ?
>>
>>
>>
>> Thanks
>>
>> Laurent
>>
>>
>>
>> *De : *Nut-upsuser <nut-upsuser-bounces+laurenttaieb=
>> free.fr at alioth-lists.debian.net> au nom de Larry Fahnoe via Nut-upsuser <
>> nut-upsuser at alioth-lists.debian.net>
>> *Répondre à : *Larry Fahnoe <fahnoe at fahnoetech.com>
>> *Date : *jeudi 9 mars 2023 à 18:59
>> *À : *nut-upsuser Mailing List <nut-upsuser at lists.alioth.debian.org>
>> *Objet : *Re: [Nut-upsuser] Question on EATON UPS
>>
>>
>>
>> On Thursday, March 9th, 2023 at 8:34 AM, Dan Langille via Nut-upsuser <
>> nut-upsuser at alioth-lists.debian.net> wrote:
>>
>>
>>
>> The UPS has been defined in ups.conf as:
>>
>> [myups3]
>>
>> driver : usbhid-ups
>>
>> port = auto
>>
>> vendorid = 0463
>>
>> productid = ffff
>>
>> desc = "5S"
>>
>> bus = 002
>>
>> device = 014
>>
>> pollonly
>>
>> I have only:
>>
>> [ups02]
>> driver=usbhid-ups
>> port=auto
>>
>> serial = [redacted]
>>
>>
>>
>> I have an Eaton 5P750 connected via USB and agree, a less specific entry
>> in ups.conf works fine for me:
>>
>>
>>
>> [ups]
>>
>> driver = usbhid-ups
>>
>> port = auto
>>
>> vendorid = 0463
>>
>>
>>
>> --Larry
>>
>>
>>
>> _______________________________________________ Nut-upsuser mailing list
>> Nut-upsuser at alioth-lists.debian.net
>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>>
>> _______________________________________________
>> Nut-upsuser mailing list
>> Nut-upsuser at alioth-lists.debian.net
>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20230325/b11376df/attachment-0001.htm>
More information about the Nut-upsuser
mailing list