From: Greg KH <gregkh@linuxfoundation.org>
To: "Seïfane Idouchach" <seifane53@gmail.com>
Cc: dirk.behme@de.bosch.com, rafael@kernel.org, dakr@kernel.org,
linux-kernel@vger.kernel.org, regressions@lists.linux.dev,
stable@vger.kernel.org
Subject: Re: [REGRESSION] Long boot times due to USB enumeration
Date: Wed, 5 Mar 2025 19:09:49 +0100 [thread overview]
Message-ID: <2025030559-radiated-reviver-eebb@gregkh> (raw)
In-Reply-To: <CAMpRfLORiuJOgUmpmjgCC1LZC1Kp0KFzPGXd9KQZELtr35P+eQ@mail.gmail.com>
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
next prev parent reply other threads:[~2025-03-05 18:26 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-05 16:32 [REGRESSION] Long boot times due to USB enumeration Seïfane Idouchach
2025-03-05 18:09 ` Greg KH [this message]
2025-03-05 19:57 ` Seïfane Idouchach
2025-03-07 12:58 ` Seïfane Idouchach
2025-03-07 14:07 ` Greg KH
2025-03-07 15:45 ` Seïfane Idouchach
2025-03-08 9:06 ` Seïfane Idouchach
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2025030559-radiated-reviver-eebb@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=dakr@kernel.org \
--cc=dirk.behme@de.bosch.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rafael@kernel.org \
--cc=regressions@lists.linux.dev \
--cc=seifane53@gmail.com \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.