Re: [PATCH] usb: xhci: fix maximum event ring segments calculation

[Mathias Nyman]

On 8/31/26 14:36, Thorsten Leemhuis wrote:
> On 8/31/26 13:28, Thorsten Leemhuis wrote:
> > On 8/31/26 11:21, Mathias Nyman wrote:
> > > On 8/31/26 09:55, Thorsten Leemhuis wrote:
> > > > On 8/30/26 05:12, Pierre-David Belanger wrote:
> > > > > The failure on 08dbfad3f504:
> > > > >
> > > > >     xhci_hcd 0000:00:04.0: xHCI Host Controller
> > > > >     xhci_hcd 0000:00:04.0: new USB bus registered, assigned bus number 1
> > > > >     xhci_hcd 0000:00:04.0: Failed to allocate interrupter erst
> > > > >     xhci_hcd 0000:00:04.0: can't setup: -12
> > > > >     xhci_hcd 0000:00:04.0: USB bus 1 deregistered
> > > > >     xhci_hcd 0000:00:04.0: init 0000:00:04.0 fail, -12
> > > > >     xhci_hcd 0000:00:04.0: probe with driver xhci_hcd failed with
> > > > > error -12
> > > > Sadly this missed -rc1, wonder why it wasn't submitted for it to prevent
> > > > more people from running into this, but whatever, that's ship has sailed.
> > >
> > > Looks like at least QEMU and Mediatek users were hit by this issue.
> >
> > Ahh, good to known. And thx for sending one of the fixes to Greg
> > meanwhile (saw that by chance).
> > > Note that this is a v7.3-rc1 regression which was found during merge
> > > window for v7.3-rc1.
> > > v7.3-rc1 came out a few hours ago.
> > > I can't resolve it much earlier than this.
> > Out of curiosity: why?
> >
> > Just ignore the question if it was something like "real life got in the
> > way" or "it fell through the cracks" -- that's how it is sometimes, no
> > worries. But in other cases I'd be glad if you could take a few minutes
> > if you have them to satisfy my curiosity, as in preparation for a
> > maintainer summit proposal I sent[1] I'm just trying to understand
> > better why regression fixes sometimes take quite a while from submission
> > to landing in mainline

No real life or personal issues got in the way.
Assumed severity after first case didn't call for action mid merge window.

> For the record (sorry, this should have bin in above mail!), as it might
> sound hostile without context, as obviously there would not have been
> enough time to fix this if the issue would only have become known during
> the end of the merge window. But that is not the case here afaics
> (please correct me if I'm wrong!), as the first patch to fix this was
> afaics submitted on 2026-08-20:

Sure, I'll describe how it went

2026-08-16 Sunday,

  v7.2 is tagged, merge window opens
  I've sent all my patches, assume Greg has his pull request ready for Linus.

2026-08-20 Thursday,
 
  I see the issue and patch the first time.
  It points to an issue in next, is valid but commit message doesn't call for
  urgency in any way.
  Doesn't specify which hardware is concerned.
  So far one report only. I haven't seen the issue myself so assume it's some obscure
  hardware (pre-production, or virtual/firmware).
  Queue for after rc1.
  No reason to panic or bother Greg or Linus mid merge window at this stage.

2026-08-27 Thursday, a week later, rc1 will be tagged on Sunday

  I get a second report for the same issue, this one shows it concerns Mediatek MT8173.
  Issue gets my attention, rc1 will be tagged on Sunday so I don't even consider stirring
  up anything anymore.

  https://lore.kernel.org/linux-usb/20260827053748.3755-1-getfeus@xxxxxxxxx


2026-08-28 Friday

  One more case, showing this  affects QEMU users as well.
  But no point in sending anything before rc1 anymore, rc1 will be tagged on Sunday
    
2026-08-30 Sunday
  
  another QEMU user reports an issue
  Linus tags 7.3-rc1

2026-08-31 Monday

  Rebase on rc1, compile, quick testrun, submit fix to Greg.

Thanks
Mathias