Message-ID: <CAMpRfLMQ=rWBpYCaco5X4Sh1ecHuiqa91TwsBo6m2MA_UMKM+g@mail.gmail.com>
Date: Thu, 6 Mar 2025 03:57:41 +0800
From: Seïfane Idouchach <seifane53@...il.com>
To: Greg KH <gregkh@...uxfoundation.org>
Cc: dirk.behme@...bosch.com, rafael@...nel.org, dakr@...nel.org, 
	linux-kernel@...r.kernel.org, regressions@...ts.linux.dev, 
	stable@...r.kernel.org
Subject: Re: [REGRESSION] Long boot times due to USB enumeration

On Thu, Mar 6, 2025 at 2:26 AM Greg KH <gregkh@...uxfoundation.org> wrote:
>
> 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

Hello Greg,

Thank you for your time.

> What does that commit have to do with this?  That's just a build break
> fix.
This commit comes right before what seems to be the bad commit. I got
to the cited (maybe) bad commit after a bisection and wanted to
confirm the results.

> 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.

After reapplying the patch (15fffc6a5624) at v6.13 (ffd294d346d1), it
indeed does not resolve the issue.
The behavior is bit different than at the reported commit
(c0a40097f0bc) in the sense that it seems that the block is happening
earlier in the boot before even systemd has started because there is
no mention of a wait job.
However the end result is still the same; the boot will only continue
after the "unable to enumerate USB device" message.

staying available if you have anything else

Powered by blists - more mailing lists