On Thu, Mar 06, 2025 at 12:32:59AM +0800, Seïfane Idouchach wrote:
Dear all,
I am reporting what I believe to be regression due to c0a40097f0bc81deafc15f9195d1fb54595cd6d0.
After this change I am experiencing long boot times on a setup that has what seems like a bad usb. The progress of the boot gets halted while retrying (and ultimately failing) to enumerate the USB device and is only allowed to continue after giving up enumerating the USB device. On Arch Linux this manifests itself by a message from SystemD having a wait job on journald. Journald starts just after the enumeration fails with "unable to enumerate USB device". This results in longer boot times on average 1 minute longer than usual (usually around 10s). No stable kernel before this change exhibits the issue all stable kernels after this change exhibit the issue.
See the related USB messages attached below (these messages are continuous and have not been snipped) :
[...] [ 9.640854] usb 1-9: device descriptor read/64, error -110 [ 25.147505] usb 1-9: device descriptor read/64, error -110 [ 25.650779] usb 1-9: new high-speed USB device number 5 using xhci_hcd [ 30.907482] usb 1-9: device descriptor read/64, error -110 [ 46.480900] usb 1-9: device descriptor read/64, error -110 [ 46.589883] usb usb1-port9: attempt power cycle [ 46.990815] usb 1-9: new high-speed USB device number 6 using xhci_hcd [ 51.791571] usb 1-9: Device not responding to setup address. [ 56.801594] usb 1-9: Device not responding to setup address. [ 57.010803] usb 1-9: device not accepting address 6, error -71 [ 57.137485] usb 1-9: new high-speed USB device number 7 using xhci_hcd [ 61.937624] usb 1-9: Device not responding to setup address. [ 66.947485] usb 1-9: Device not responding to setup address. [ 67.154086] usb 1-9: device not accepting address 7, error -71 [ 67.156426] usb usb1-port9: unable to enumerate USB device
That's a real issue, but should not be due to the commit id you referenced.
[...]
This issue does not manifest in 44a45be57f85.
What does that commit have to do with this? That's just a build break fix.
I am available to test any patches to address this on my system since I understand this could be quite hard to replicate on any system. I am available to provide more information if I am able or with guidance to help troubleshoot the issue further.
Wishing you all a good day.
#regzbot introduced: c0a40097f0bc81deafc15f9195d1fb54595cd6d0
We know there are issues here. That commit was "fixed" by commit 15fffc6a5624 ("driver core: Fix uevent_show() vs driver detach race"), but then that caused a different problem, so it was reverted by commit 9a71892cbcdb ("Revert "driver core: Fix uevent_show() vs driver detach race"").
There are many discussions about this on the mailing list, with a proposal to add Dan's "fix" back. If you could try that, it would be great to see.
I think your USB problem is different here, but if you add 15fffc6a5624 ("driver core: Fix uevent_show() vs driver detach race") to your kernel, that would be great to see.
thanks,
greg k-h