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

[Paul Menzel <pmenzel@molgen.mpg.de>]

[-- Attachment #1: Type: text/plain, Size: 2370 bytes --]

[Cc: +linuxppc-dev]

Dear Michal,


Thank you for your reply.

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.

> 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

`lsusb` also does not list the device. But I need to check on hardware.


Kind regards,

Paul


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 …

Please excuse, if I attach/cite hallucinations.

[-- Attachment #2: 0001-usb-xhci-Reset-controller-on-kexec-to-prevent-stale-.patch --]
[-- Type: text/x-patch, Size: 3340 bytes --]

From b110d128ebe662a02319af6899d8dc50759a1147 Mon Sep 17 00:00:00 2001
From: Paul Menzel <pmenzel@molgen.mpg.de>
Date: Mon, 11 May 2026 17:33:35 +0200
Subject: [PATCH] usb: xhci: Reset controller on kexec to prevent stale state
 in next kernel
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

When kexec is used to boot into a new Linux kernel, xhci_shutdown() only
halts the xHCI controller (CMD_RUN=0, waits for STS_HALT) without
resetting it.  After halt, the controller still holds stale internal state
from the old kernel: the DCBAA pointer, scratchpad buffer address, event
and command ring dequeue pointers, and so on, all pointing into the old
kernel's now-invalid memory.

If platform firmware (e.g. OPAL on IBM POWER8) then touches the USB
controller during the kexec transition – for example to provide a USB
keyboard console – it may attempt to use those stale ring-buffer
pointers.  This leaves the controller in an undefined, running state
(STS_HALT=0) when the new kernel arrives.  The new kernel's early
quirk_usb_handoff_xhci() fixup then fails to halt the controller and
the xHCI driver can no longer initialise it, producing:

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

A Petitboot-to-Linux kexec chain works correctly because Petitboot, as
the active USB owner, properly halted the controller; the new kernel
finds it cleanly halted.

Fix this by issuing a controller reset (CMD_RESET) after the halt
whenever kexec is in progress.  The reset clears all internal state
(DCBAA, scratchpad, ring buffers, port state) so that any firmware or
the incoming kernel always starts from a well-known, initialisation-ready
state.  This mirrors the approach already used for the
XHCI_SPURIOUS_WAKEUP and XHCI_RESET_TO_DEFAULT quirks.

Link: https://lore.kernel.org/all/fb68e15d-b8f2-42ac-aa65-0d9fedcfcdbd@molgen.mpg.de/
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Assisted-by: Claude Sonnet 4.6 <noreply@anthropic.com>
---
 drivers/usb/host/xhci.c | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index a54f5b57f2055..55031d03ad40e 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -9,6 +9,7 @@
  */
 
 #include <linux/jiffies.h>
+#include <linux/kexec.h>
 #include <linux/pci.h>
 #include <linux/iommu.h>
 #include <linux/iopoll.h>
@@ -775,11 +776,16 @@ void xhci_shutdown(struct usb_hcd *hcd)
 	xhci_halt(xhci);
 
 	/*
-	 * Workaround for spurious wakeps at shutdown with HSW, and for boot
-	 * firmware delay in ADL-P PCH if port are left in U3 at shutdown
+	 * Workaround for spurious wakeups at shutdown with HSW, and for boot
+	 * firmware delay in ADL-P PCH if ports are left in U3 at shutdown.
+	 * Also reset on kexec to leave the controller in a clean state with
+	 * all internal state (DCBAA, scratchpad, rings) cleared, so the next
+	 * kernel can initialize it without interference from stale pointers
+	 * into the old kernel's memory.
 	 */
 	if (xhci->quirks & XHCI_SPURIOUS_WAKEUP ||
-	    xhci->quirks & XHCI_RESET_TO_DEFAULT)
+	    xhci->quirks & XHCI_RESET_TO_DEFAULT ||
+	    kexec_in_progress)
 		xhci_reset(xhci, XHCI_RESET_SHORT_USEC);
 
 	spin_unlock_irq(&xhci->lock);
-- 
2.54.0