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

Thanks again for all of the suggestions. I wanted to provide an update
after spending some more time testing.

At this point I'm no longer convinced this is simply a kernel regression.

I've now tested the UPS across multiple kernel generations, including:

- 6.0.x

- 6.18.40

- 7.0.2-6

- 7.0.14-8

- 7.2.x

The behavior varies somewhat between versions—7.0.2-6 gets the
farthest—but none of them provide stable long-term communication with
the UPS.

On 7.0.2-6, the driver successfully:

- Claims interface 0

- Reads the HID report descriptor

- Detects the UPS correctly as a CyberPower LE1000DG (VID:PID 0764:0501)

- Retrieves battery charge, runtime, voltage, load, and other values

- Completes several successful polling/update cycles

Eventually communication stops. At that point the running driver
repeatedly logs:

    libusb1: Could not open any HID devices: insufficient permissions
on everything

and upsd reports:

    Data for UPS [ups] is stale - check driver

One thing I find particularly interesting is that the UPS never
disappears from the USB bus. Even after communication becomes stale it
is still present in lsusb:

    Bus 001 Device 007: ID 0764:0501 Cyber Power System LE1000DG

There are also no USB disconnects, resets, xHCI errors, or other
kernel USB errors after the device has initialized.

What makes this especially confusing is that this does not appear to
be a normal permissions problem. The driver clearly has permission to
open the device initially—it successfully claims the interface, reads
the HID report descriptor, and communicates with the UPS for several
polling cycles before failing. Once it enters this state, however, it
repeatedly reports "insufficient permissions on everything" until the
driver is restarted.

Since I can reproduce essentially the same failure across 6.0, 6.18,
7.0, and 7.2 kernels, I'm beginning to think the kernel version only
affects how long the driver remains functional, rather than being the
underlying cause.

Over the next few days I plan to test the UPS using a dedicated PCIe
USB controller based on an ASMedia chipset to determine whether the
behavior is specific to the Intel xHCI controller. I'll report those
results back to the list once I've completed that testing.

Has anyone seen this pattern before, where usbhid-ups initializes
successfully, polls normally for a short period, then loses
communication and repeatedly reports:

    libusb1: Could not open any HID devices: insufficient permissions
on everything

while the USB device itself remains present and enumerated?

Thanks again for everyone's time and suggestions. I'll follow up once
I've completed the additional USB controller testing.

On Tue, Aug 4, 2026 at 8:01 PM Jamie Stephens <[email protected]> wrote:
>
> Hi Lovekesh,
>
> I have now tested 02-resume-reset.patch separately on Linux 7.1.5 with
> the CyberPower device 0764:0501.
>
> The patched kernel was active:
>
>   7.1.5-ups-reset-resume
>
> The device was detected by lsusb, but USB initialization still failed:
>
>   usb 1-3: new full-speed USB device number 4 using xhci_hcd
>   usb 1-3: New USB device found, idVendor=0764, idProduct=0501
>   usb 1-3: New USB device strings: Mfr=3, Product=1, SerialNumber=2
>   usb 1-3: can't set config #1, error -71
>
> The UPS therefore never attached to hid-generic and NUT could not use it.
>
> I then returned the same USB cable and UPS to the PiAware NUT server,
> where it immediately resumed working normally:
>
>   ups.status: OL
>   battery.charge: 100
>   input.voltage: 122.0
>   output.voltage: 122.0
>   ups.load: 23
>   driver.version.data: CyberPower HID 0.8
>
> Results so far:
>
>   01-no-lpm.patch: did not resolve the regression
>   02-resume-reset.patch: did not resolve the regression
>
> I will proceed with the requested git bisection unless you would like
> any additional targeted logs or tests first.
>
> 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