Re: [REGRESSION] CyberPower LE1000DG (0764:0501) USB HID regression on x86

Hi Lovekesh,

I tested 01-no-lpm.patch separately on Linux 7.1.5 with the
CyberPower device 0764:0501.

The patch did not resolve the problem.

On the first connection, enumeration failed with:

  string descriptor 0 read error: -75
  can't set config #1, error -71

After disconnecting and reconnecting the USB cable, the device did
enumerate and attach to hid-generic, but NUT still could not initialize
it reliably. The service reported:

  Can't initialize data from HID UPS

and later:

  libusb1: Could not open any HID devices: insufficient permissions on
everything
  No matching HID UPS found

Running usbhid-ups directly with debug output showed repeated invalid
HID report descriptor lengths, for example:

  Trying HID descriptor length 2053254698
  HID descriptor too long 2053254698 (max 6144)

It eventually reported:

  Unable to get Report descriptor: Resource temporarily unavailable

The manually run /usr/local usbhid-ups binary then terminated with a
segmentation fault.

I have returned the UPS to the PiAware NUT server, where it is again
working normally with the same UPS and NUT 2.8.1:

  ups.status: OL
  driver.version.data: CyberPower HID 0.8

I will now test 02-resume-reset.patch separately and report the result.

Regards,
Jamie Stephens

On Tue, Aug 4, 2026 at 2:56 PM Lovekesh Solanki
<[email protected]> wrote:
>
> Thanks for the report,
>
> On Thu, Jul 30, 2026 at 03:28:02PM -0400, Jamie Stephens wrote:
> > sudo lsusb -v -d 0764:0501
> >
> > reports:
> >
> > wDescriptorLength     504
> >
> > Warning: can't get report descriptor, LIBUSB_ERROR_PIPE
> >
> > cannot read device status, Resource temporarily unavailable (11)
> >
> > As a result, usbhid-ups is unable to reliably communicate with the
> > device and NUT cannot reliably monitor UPS status.
> The lsusb failure and NUT seem to be seperate, lsusb failure could
> simply be device property.
>
> Few possibilities I can think of worth testing:
> 1) It may be related to LPM, the device may be advertising this but may
> not be handling it properly.
> 2) Commit 8020c41b39f5 (usb: core: allow ACPI-managed hard-wired ports to power off)
> lets acpi managed ports be powered off even if hub does not advertise
> power switching. The UPS may be sitting on such port and its power could
> be cycled out and leave it in a stale state.
>
> I'm attaching two patches to see if they have any effect, please apply
> and test them seperatly and let us know the results.
> And, as per Thorsten's advice above, run git bisection regardless.
>
> Regards,
> Lovekesh