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

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

[Jamie Stephens]

Hi,

Per the recommendation on Proxmox Bugzilla #7850, I’m reporting what
appears to be a Linux USB/HID regression affecting a CyberPower
LE1000DG UPS.

Hardware

UPS

CyberPower LE1000DG
USB VID:PID 0764:0501

Affected x86 platform

Intel Tiger Lake-H USB 3.2 Gen 2 xHCI Host Controller
PCI ID: 8086:43ed

Problem

When connected to the x86 system, the UPS enumerates successfully and
is bound by the kernel to hid-generic.

Kernel messages include:

usb 1-3: New USB device found, idVendor=0764, idProduct=0501

usb 1-3: Product: LE1000DG

hid-generic 0003:0764:0501.0001: hiddev0,hidraw0:

USB HID v1.11 Device [CPS LE1000DG]

However,

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.

Kernels Tested

The issue reproduces on:

Proxmox VE kernel 7.0.14-5-pve
Proxmox VE kernel 7.0.14-6-pve
Ubuntu mainline 7.1.5-070105-generic

Reproducing the issue on an Ubuntu mainline kernel indicates the
behavior is not specific to Proxmox and appears to exist in upstream
Linux as well.

Comparison

The identical UPS, USB cable, and NUT configuration were moved to a
Raspberry Pi 5 running:

Debian 13 (trixie)
Linux 6.18.34+rpt-rpi-2712
NUT 2.8.1

On the Raspberry Pi:

the device binds successfully to hid-generic
usbhid-ups initializes successfully
NUT communicates reliably
upsc ups@localhost consistently returns complete UPS status, including
charge, runtime, voltage, load, and other telemetry

This behavior has remained reliable through repeated testing and reboots.

For completeness, lsusb -v on the Raspberry Pi also reports the HID
report descriptor as unavailable. Despite this, usbhid-ups
communicates with the UPS reliably. The communication failure only
occurs on the affected x86 platform.

Troubleshooting Performed

Tested multiple USB ports
Tested USB 2.0 and USB 3.x ports
Replaced the USB cable
Tested NUT 2.8.1, 2.8.5, and current development master
Tested as both root and the nut service user
Verified udev permissions
Verified USB VID:PID 0764:0501
Reproduced the issue on Ubuntu mainline 7.1.5

A Proxmox developer suggested this may require a USB HID device quirk
and requested that the issue be reported upstream.

Reference:

Proxmox Bugzilla #7850: https://bugzilla.proxmox.com/show_bug.cgi?id=7850

Please let me know if additional information would be helpful. I can
provide complete dmesg, lsusb, and usbhid-upsdebug logs or perform
additional testing if needed.

Thank you,
Jamie Stephens

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

[Thorsten Leemhuis]

On 7/30/26 21:28, Jamie Stephens wrote:
> 
> Per the recommendation on Proxmox Bugzilla #7850, I’m reporting what
> appears to be a Linux USB/HID regression affecting a CyberPower
> LE1000DG UPS.

Thx for the report. No developer replied yet with an idea what's wrong.
Unless this changes I guess you need to run a git bisection to get
somebodies attention, as the root of the problem might be in one of
various kernel subsystems. The process is described in
https://docs.kernel.org/admin-guide/verify-bugs-and-bisect-regressions.html
or
https://docs.kernel.org/admin-guide/bug-bisect.html; if you follow the
latter you might want to first check if mainline (7.2-rc6) is still
affected.

Ciao, Thorsten

> Hardware
> 
> UPS
> 
> CyberPower LE1000DG
> USB VID:PID 0764:0501
> 
> Affected x86 platform
> 
> Intel Tiger Lake-H USB 3.2 Gen 2 xHCI Host Controller
> PCI ID: 8086:43ed
> 
> Problem
> 
> When connected to the x86 system, the UPS enumerates successfully and
> is bound by the kernel to hid-generic.
> 
> Kernel messages include:
> 
> usb 1-3: New USB device found, idVendor=0764, idProduct=0501
> 
> usb 1-3: Product: LE1000DG
> 
> hid-generic 0003:0764:0501.0001: hiddev0,hidraw0:
> 
> USB HID v1.11 Device [CPS LE1000DG]
> 
> However,
> 
> 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.
> 
> Kernels Tested
> 
> The issue reproduces on:
> 
> Proxmox VE kernel 7.0.14-5-pve
> Proxmox VE kernel 7.0.14-6-pve
> Ubuntu mainline 7.1.5-070105-generic
> 
> Reproducing the issue on an Ubuntu mainline kernel indicates the
> behavior is not specific to Proxmox and appears to exist in upstream
> Linux as well.
> 
> Comparison
> 
> The identical UPS, USB cable, and NUT configuration were moved to a
> Raspberry Pi 5 running:
> 
> Debian 13 (trixie)
> Linux 6.18.34+rpt-rpi-2712
> NUT 2.8.1
> 
> On the Raspberry Pi:
> 
> the device binds successfully to hid-generic
> usbhid-ups initializes successfully
> NUT communicates reliably
> upsc ups@localhost consistently returns complete UPS status, including
> charge, runtime, voltage, load, and other telemetry
> 
> This behavior has remained reliable through repeated testing and reboots.
> 
> For completeness, lsusb -v on the Raspberry Pi also reports the HID
> report descriptor as unavailable. Despite this, usbhid-ups
> communicates with the UPS reliably. The communication failure only
> occurs on the affected x86 platform.
> 
> Troubleshooting Performed
> 
> Tested multiple USB ports
> Tested USB 2.0 and USB 3.x ports
> Replaced the USB cable
> Tested NUT 2.8.1, 2.8.5, and current development master
> Tested as both root and the nut service user
> Verified udev permissions
> Verified USB VID:PID 0764:0501
> Reproduced the issue on Ubuntu mainline 7.1.5
> 
> A Proxmox developer suggested this may require a USB HID device quirk
> and requested that the issue be reported upstream.
> 
> Reference:
> 
> Proxmox Bugzilla #7850: https://bugzilla.proxmox.com/show_bug.cgi?id=7850
> 
> Please let me know if additional information would be helpful. I can
> provide complete dmesg, lsusb, and usbhid-upsdebug logs or perform
> additional testing if needed.
> 
> Thank you,
> Jamie Stephens
> 

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

[Lovekesh Solanki]

[-- Attachment #1: Type: text/plain, Size: 1146 bytes --]

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

[-- Attachment #2: 01-no-lpm.patch --]
[-- Type: text/plain, Size: 662 bytes --]

diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c
index 87ee2d938bc0..2c07e1cb7e05 100644
--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -374,6 +374,9 @@ static const struct usb_device_id usb_quirk_list[] = {
 	/* Midiman M-Audio Keystation 88es */
 	{ USB_DEVICE(0x0763, 0x0192), .driver_info = USB_QUIRK_RESET_RESUME },
 
+	/* CyberPower Systems UPS (LE1000DG / CP1500 AVR) */
+	{ USB_DEVICE(0x0764, 0x0501), .driver_info = USB_QUIRK_NO_LPM },
+
 	/* SanDisk Ultra Fit and Ultra Flair */
 	{ USB_DEVICE(0x0781, 0x5583), .driver_info = USB_QUIRK_NO_LPM },
 	{ USB_DEVICE(0x0781, 0x5591), .driver_info = USB_QUIRK_NO_LPM },


[-- Attachment #3: 02-resume-reset.patch --]
[-- Type: text/plain, Size: 667 bytes --]

diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c
index 87ee2d938bc0..8ccc5fc6060c 100644
--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -374,6 +374,9 @@ static const struct usb_device_id usb_quirk_list[] = {
 	/* Midiman M-Audio Keystation 88es */
 	{ USB_DEVICE(0x0763, 0x0192), .driver_info = USB_QUIRK_RESET_RESUME },
 
+	/* CyberPower Systems UPS (LE1000DG / CP1500 AVR) */
+	{ USB_DEVICE(0x0764, 0x0501), .driver_info = USB_QUIRK_RESET_RESUME},
+
 	/* SanDisk Ultra Fit and Ultra Flair */
 	{ USB_DEVICE(0x0781, 0x5583), .driver_info = USB_QUIRK_NO_LPM },
 	{ USB_DEVICE(0x0781, 0x5591), .driver_info = USB_QUIRK_NO_LPM },

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

[Jamie Stephens]

Thank you, will set aside some time in the next day or so  to run the
patches and git bisection

On Tue, Aug 4, 2026 at 2:56 PM Lovekesh Solanki
<lovekeshsolanki00@gmail.com> 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

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

[Jamie Stephens]

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
<lovekeshsolanki00@gmail.com> 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

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

[Jamie Stephens]

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
<lovekeshsolanki00@gmail.com> 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

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

[Jamie Stephens]

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 <jamie.stephens@gmail.com> 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
> <lovekeshsolanki00@gmail.com> 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

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

[Jamie Stephens]

I also completed the test with a separate PCIe USB controller based on
the ASMedia ASM1042.

The UPS enumerates normally on the ASMedia controller and the kernel
identifies it correctly as the CyberPower LE1000DG (0764:0501).
However, on this controller the failure mode is different.

The device and HID descriptors are readable, but the 504-byte HID
report descriptor is consistently unavailable. Ten consecutive runs
of:

    lsusb -v -d 0764:0501

all showed:

    Report Descriptors:
        ** UNAVAILABLE **

NUT behaves consistently with that result. usbhid-ups successfully
opens the device and claims interface 0, but then fails while
attempting to retrieve the HID report descriptor:

    Unable to get HID descriptor (Pipe error)
    HID descriptor length 504
    Unable to get Report descriptor: Resource temporarily unavailable
    No matching HID UPS found

There are no USB disconnects or xHCI errors in dmesg. The device
remains present and enumerated on the ASMedia controller.

So the separate USB host controller did not resolve the issue; it
changed the failure mode. On the Intel controller, the report
descriptor can sometimes be read and NUT can operate for a period
before communication becomes stale. On the ASMedia ASM1042, the report
descriptor cannot currently be retrieved at all.

The same UPS continues to work correctly when connected to the
Raspberry Pi, so for now I plan to leave the UPS attached to the Pi
for production use.

On Wed, Aug 5, 2026 at 8:08 PM Jamie Stephens <jamie.stephens@gmail.com> wrote:
>
> 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 <jamie.stephens@gmail.com> 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
> > <lovekeshsolanki00@gmail.com> 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

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

[Alan Stern]

On Sat, Aug 08, 2026 at 03:14:38PM -0400, Jamie Stephens wrote:
> I also completed the test with a separate PCIe USB controller based on
> the ASMedia ASM1042.
> 
> The UPS enumerates normally on the ASMedia controller and the kernel
> identifies it correctly as the CyberPower LE1000DG (0764:0501).
> However, on this controller the failure mode is different.
> 
> The device and HID descriptors are readable, but the 504-byte HID
> report descriptor is consistently unavailable. Ten consecutive runs
> of:
> 
>     lsusb -v -d 0764:0501
> 
> all showed:
> 
>     Report Descriptors:
>         ** UNAVAILABLE **
> 
> NUT behaves consistently with that result. usbhid-ups successfully
> opens the device and claims interface 0, but then fails while
> attempting to retrieve the HID report descriptor:
> 
>     Unable to get HID descriptor (Pipe error)
>     HID descriptor length 504
>     Unable to get Report descriptor: Resource temporarily unavailable
>     No matching HID UPS found
> 
> There are no USB disconnects or xHCI errors in dmesg. The device
> remains present and enumerated on the ASMedia controller.

What shows up in usbmon (or equivalently, Wireshark)?

Alan Stern

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

[Jamie Stephens]

Subject: Re: CyberPower LE1000DG (0764:0501) - Further testing results

Thanks again for all of the help and for the patches you provided.

Unfortunately, I did not get a usbmon/Wireshark capture from the
LE1000DG before returning it. I wanted to send an update before going
any farther with the kernel git bisect, because some additional
testing changed my thinking about where the problem may be.

As discussed previously, I tested the LE1000DG across a number of
kernels, including:

- 6.0.x
- 6.18.40
- several 7.0 kernels
- 7.1.5
- 7.2 development builds

I also built and tested the patched kernels you provided, including
the USB/LPM and reset/resume changes.

None of those changes made the LE1000DG reliable enough for normal
use, so my next planned step had been to begin a Linux git bisect.

Before doing that, I installed a separate PCIe USB controller using an
ASMedia ASM1042 chipset so I could eliminate the Intel xHCI controller
as a variable.

The LE1000DG behaved poorly there as well.

It enumerated normally on the ASMedia controller:

    Bus 003 Device 003: ID 0764:0501 Cyber Power System, Inc. CP1500 AVR UPS

and the kernel identified it correctly as:

    Product: LE1000DG
    Manufacturer: CPS
    SerialNumber: QBKRP7001634

However, usbhid-ups was unable to reliably retrieve the HID report descriptor:

    Unable to get HID descriptor (Pipe error)
    Unable to get Report descriptor: Resource temporarily unavailable
    No matching HID UPS found

lsusb could still read the normal USB device and configuration
descriptors, but the HID report descriptor remained unavailable.

The more interesting test came afterward.

I temporarily connected an older CyberPower AVR1500/CP1500C UPS that I
already own to the same Proxmox host.

It uses the same VID:PID:

    0764:0501

but is an older USB 1.1 / low-speed device:

    Product: CP 1500C
    bcdUSB: 1.10
    Negotiated speed: Low Speed (1 Mbps)
    HID report descriptor length: 387 bytes

 this older CyberPower UPS worked normally with the same NUT 2.8.1
usbhid-ups driver.

It has been polling continuously with successful quick and full update
cycles. For example:

    RemainingCapacity = 100
    RunTimeToEmpty = 5407
    Input.Voltage = 121
    Output.Voltage = 121

The driver continues to receive HID input reports and complete full
updates without losing communication.

This seems significant because the working test uses:

- The same Proxmox host
- The same current kernel
- The same NUT 2.8.1 installation
- The same usbhid-ups driver
- The same CyberPower VID:PID 0764:0501
- The same Intel xHCI controller

and the older CP1500C works while the newer LE1000DG did not.

I also tested the LE1000DG on the separate ASMedia USB controller and
saw essentially the same communication problems there.

The LE1000DG reported:

    USB 2.00
    Full Speed (12 Mbps)
    HID 1.11
    504-byte report descriptor

while the older working CP1500C reports:

    USB 1.10
    Low Speed (1 Mbps)
    HID 1.10
    387-byte report descriptor

With the older CyberPower UPS remaining stable on the same host,
kernel, NUT installation, and Intel USB controller, I became much less
convinced that the primary issue was a Linux kernel regression or the
Intel xHCI controller.

At this point I suspect the problem may be related more specifically
to the USB/HID implementation in the newer LE1000DG, or an interaction
between that implementation and usbhid-ups/libusb.

Because I was still within the return window, I decided to return the
LE1000DG rather than continue troubleshooting a unit I could no longer
return later.

Given these results, I am also wondering whether there is still much
value in proceeding with the kernel git bisect. The fact that the
older CyberPower unit works reliably on the exact same system seems
like fairly strong evidence against a general kernel USB regression.

I do appreciate all of the time, patches, and troubleshooting help
everyone provided. This turned into a much deeper investigation than I
originally expected, but I learned quite a bit from it.

Thanks again for all of the help.

Jamie

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

[Michal Pecio]

On Thu, 30 Jul 2026 15:28:02 -0400, Jamie Stephens wrote:
> Hi,
> 
> Per the recommendation on Proxmox Bugzilla #7850, I’m reporting what
> appears to be a Linux USB/HID regression affecting a CyberPower
> LE1000DG UPS.
>
> Proxmox Bugzilla #7850: https://bugzilla.proxmox.com/show_bug.cgi?id=7850

So apparently you are running some Ubuntu-based distribution and
"The UPS works correctly with kernel 7.0.2-6-pve, but fails with kernels
7.0.14-5-pve and 7.0.14-6-pve". Also with "Ubuntu mainline 7.1.5".

If your distribution supplies such kernel packages, I would suggest
starting with narrowing it down to a single exact release, e.g.
"7.0.8-3-pve is the first broken one".

This will make bisecting faster, or maybe there will be few enough USB
and HID changes in this release that something will become obvious.

Regards,
Michal