Re: IBM Power S822LC: pci 0021:0d:00.0: xHCI HW did not halt within 32000 usec status = 0x0

[Michal Pecio <michal.pecio@gmail.com>]

On Mon, 11 May 2026 23:57:33 +0200, Paul Menzel wrote:
> Am 06.05.26 um 19:30 schrieb Michal Pecio:
> > On Wed, 6 May 2026 18:06:20 +0200, Paul Menzel wrote:  
> >> On the IBM Power S822LC (8335-GCA POWER8), rebooting into Linux 7.1-rc2+
> >> with kexec results in the warning below:
> >>
> >>       [    0.000000] Linux version 7.1.0-rc2+ (x@b) (gcc (Ubuntu 11.2.0-7ubuntu2) 11.2.0, GNU ld (GNU Binutils for Ubuntu) 2.37) #3 SMP PREEMPT Wed May  6 08:50:5
> >>       […]
> >>       [    0.000000] Hardware name: 8335-GCA POWER8 (raw) 0x4d0200 opal:skiboot-5.4.8-5787ad3 PowerNV
> >>       […]
> >>       [    1.593760] NET: Registered PF_UNIX/PF_LOCAL protocol family
> >>       [    1.593859] pci 0021:0d:00.0: enabling device (0140 -> 0142)
> >>       [    1.627080] pci 0021:0d:00.0: xHCI HW did not halt within 32000 usec status = 0x0
> >>       [    1.627094] pci 0021:0d:00.0: quirk_usb_early_handoff+0x0/0x300 took 32465 usecs
> >>       [    1.627123] PCI: CLS 0 bytes, default 128  
> 
> > Does it work any better if kexecing other kernel versions?  
> 
> No, the problem goes as far back as 5.17-rc7. (I didn’t try anything 
> before.)
> 
> > What if you increase XHCI_MAX_HALT_USEC by 10* or 100* ?  
> 
> I have to test this.

I missed your dmesg attachment previously.

This may not help if another halt attempt 200ms later fails too.
Per spec (5.4.1.1), the HC is supposed to complete halt in 16ms.

> > Does the controller work normally after this warning?  
> It does not look like it. In the log attached to my report, later on 
> there is:
> 
>      [    1.739374] xhci_hcd 0021:0d:00.0: xHCI Host Controller
>      [    1.739431] xhci_hcd 0021:0d:00.0: new USB bus registered, 
> assigned bus number 1
>      [    1.794727] Freeing initrd memory: 52928K
>      [    1.801984] xhci_hcd 0021:0d:00.0: Host halt failed, -110
>      [    1.801988] xhci_hcd 0021:0d:00.0: can't setup: -110
>      [    1.802137] xhci_hcd 0021:0d:00.0: USB bus 1 deregistered
>      [    1.802154] xhci_hcd 0021:0d:00.0: init 0021:0d:00.0 fail, -110
>      [    1.802250] xhci_hcd 0021:0d:00.0: probe with driver xhci_hcd 
> failed with error -110

Right, this chip seems stuck and the driver fails to reinitialize it.

> PS: Claude Sonnet 4.6 cooked up the attached patch, which does *not* 
> help though, but does get it to the return code 0x10, which Claude 
> replied to with:
> 
> > ● The status change 0x0 → 0x10 is meaningful: 0x10 is PCD (Port Change Detect, bit 4),
> >   HCHalted=0. The old-kernel reset (from our commit) did take effect …  

Do you mean that running xhci_reset() before kexec() causes the new
kernel to see 0x10 instead of 0x0 in the status register? Is this
reproducible, not random or a one time fluke?

A little odd, one could expect reset to have the opposite effect.

Is there truly some machine firmware running during kexec() and using
the HC, as your LLM says?

I honestly don't know what to do with this. I think I would start with
looking whether xhci_shutdown() in the old kernel manages to halt it
successfully or if it also fails, and what's the USBSTS there.

It seems that you can get such information by enabling dynamic debug

  echo 'module xhci_hcd +p' >/proc/dynamic_debug/control

and capcturing old kernel's log up to kexec() through a serial cable.

Regards,
Michal