USB Error 71 on USB Gamepad

[idemiq]

Describe the bug
Following a clean installation on RPi4, an error is logged to the console at startup which reads:

"usb 1-1.3: device not accepting address 3, error -71"

This occurs when certain peripherals are connected, in this case; a RetroFlag Classic USB Gamepad, whether-or-not other devices are connected, and regardless of physical port assignment.

Version; Raspbian GNU Linux 10.3 (buster), Kernel 4.19.97-v71+

To reproduce
Use the current official Retropie image for Pi4 (md5: 9154d998cba5219ddf23de46d8845f6c) (version correct), attach the example USB peripheral, and boot.

Expected behaviour
USB device addressing should not result in error.

Actual behaviour
Kernel specifies device error, which did not occur in Stretch.

System

• Model: Raspberry Pi Model B Rev 1.2
• OS Version: Raspberry Pi reference 2020-02-13, Raspbian GNU Linux 10.3 (buster)
• Firmware Version: c3c8dbdf147686fb0c3f32aece709d0653368810 (clean) (release) (start)
• Kernel: Linux Pegasus 4.19.97-v71+ problem with device tree overlay at86rf233  #1294 SMP Thu Jan 30 13:21:14 GMT 2020 armv71 GNU/Linux

Logs
usb 1-1.3: new full-speed USB device number 7 using xhci_hcd
usb 1-1.3: New USB device found, idVendor=057e, idProduct=2009, bcdDevide= 2.00
usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-1.3: Product: Pro Controller
usb 1-1.3: Manufacturer: Nintendo Co., Ltd.
usb 1-1.3: SerialNumber: 000000000001
input: Nintendo Co., Ltd. Pro Controller as /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.3/1-1.3:1.0/0003:057E:2009:0004/input/input6
hid-generic 0003:057E:2009.0004: input,hidraw0: USB HID v1.11 Joystick [Nintendo Co., Ltd. Pro Controller] on usb-0000:01:00.0-1.3/input0
usb 1-1.3: USB disconnect, device number 7
usb 1-1.3: new full-speed USB device number 8 using xhci_hcd
usb 1-1.3: New USB device found, idVendor=045e, idProduct=028e, bcdDevide= 1.14
usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-1.3: Product: Controller
usb 1-1.3: Manufacturer: Controller
usb 1-1.3: SerialNumber: Controller
input: Microsoft X-Box 360 pad as /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.3/1-1.3:1.0/0003:057E:2009:0004/input/input7
xpad 1-1.3:1.0: xpad_irq_in - usb_submit_urb failed with result -1

Additional context
Note that only one device was connected, that logged as two profiles.

[P33M]

I went and acquired one of these, and don't see the issue reported. The VID is different, despite being advertised as the same product:
Bus 001 Device 004: ID 045e:028e Microsoft Corp. Xbox360 Controller

That said, the same driver is in use which suggests a common or semi-common hardware platform.

What is the output of sudo rpi-eeprom-update?

[idemiq]

Output is:

BCM2711 detected
BOOTLOADER: up-to-date
CURRENT: Thu 16 Apr 17:11:26 UTC 2020 (1587057086)
LATEST: Tue 10 Sep 10:41:50 UTC 2019 (1568112110)
FW DIR: /lib/firmware/raspberrypi/bootloader/critical
VL805: up-to-date
CURRENT: 000137ad
LATEST: 000137ad

It might be worth mentioning, that the Gamepad edition I have, came as part of this (exact) package.

[P33M]

In which of these conditions does the enumeration error occur?

• When plugged in after the Pi has booted
• When plugged in, working, and the Pi is rebooted via sudo reboot
• When plugged in with the Pi powered off, and the Pi is powered on

There is an update to the bootloader that changes the reboot behaviour, but the first post isn't clear as to what conditions are required to cause the device to fail to enumerate.

[idemiq]

It appears under all of these conditions (reboot, cold boot, wake). Any which would cause the OS to load.

Apologies if the initial post wasn't entirely clear. I did try. :)

[P33M]

I do have the same device as you... but with a different failure mode. On the very first connect to a Pi 4, the device sometimes doesn't respond to the first command sent to it. The rest of the probe sequence completes successfully, though. My guess is the device doesn't have a clean power-on reset behaviour.

As a workaround, I recommend using uhubctl to power cycle the USB ports once during startup - see https://github.com/mvp/uhubctl