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

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