[systemsettings] [Bug 524082] System Settings startup blocks 12+ seconds in SDL_Init from GameControllerModuleData when no gamepad is connected (regression in 6.7)

https://bugs.kde.org/show_bug.cgi?id=524082

--- Comment #3 from Ivaylo Georgiev <[email protected]> ---
Update as promised in comment 2 — I found the dominant cause of the stall on my
machine, and it is neither the KCM's SDL flags per se nor the udev lookups: a
failing USB3 link. This likely also explains why it doesn't reproduce on
healthy systems (comment 1).

Isolation, using a minimal test program that only calls
SDL_Init(SDL_INIT_GAMECONTROLLER), no GUI:
- default environment: 12-16 s
- SDL_JOYSTICK_DISABLE_UDEV=1 alone: no improvement (~13 s), so the udev cost
from SDL#9092 was NOT the main contributor here
- SDL_JOYSTICK_HIDAPI=0: 0.06 s
- SDL_HIDAPI_LIBUSB=0 alone: 0.10 s -> the entire stall is inside SDL's bundled
libusb HID backend

The system's hidapi (hidraw backend) and system libusb enumerate the same
devices in under 0.01 s.

Sampling /proc/<pid>/wchan during the stall shows the thread blocked in
bConfigurationValue_show, i.e. a sysfs attribute read. SDL's vendored libusb is
built without udev support, so its hid_enumerate reads USB
descriptors/attributes directly from sysfs, and those reads take the kernel's
per-USB-device lock.

The lock holder: the kernel had been logging "usb usb2-port1: Cannot enable.
Maybe the USB cable is bad?" every 4 seconds (55000+ messages over 3 days) — a
USB3 hub whose SuperSpeed link fails to train. Its USB2 side works fine, so all
devices on it function normally and nothing visibly misbehaves; the hub driver
just retries the SS link forever, holding the root hub's device lock, and SDL's
sysfs read blocks behind it for many seconds.

Confirmation: after disabling the SuperSpeed side of that port (echo 1 >
/sys/bus/usb/devices/usb2/2-0:1.0/usb2-port1/disable), SDL_Init dropped from
~15 s to 0.10 s with no SDL hints/env vars at all, and System Settings cold
starts instantly.

One caveat: my journal shows the port retries only began on Aug 14, while the
original 12.3 s measurement in this report is from Aug 9, so slow HIDAPI
probing can evidently also happen without a wedged link (hardware-dependent, as
described). But for a reliable, extreme reproduction: plug in a USB3 hub/device
with a marginal SuperSpeed connection (kernel spamming "Cannot enable" while
USB2 still works) and the multi-second SDL_Init should appear immediately.

The architectural point stands regardless of what makes enumeration slow on a
given machine: a blocking SDL_Init on the System Settings main thread turns any
USB subsystem hiccup into a 10+ second frozen window for the entire
application. Running the game-controller relevance check asynchronously / off
the main thread would make startup robust against this whole class of stalls.

-- 
You are receiving this mail because:
You are watching all bug changes.