From: Michal Pecio <michal.pecio@gmail.com>
To: Wen Xiong <wenxiong@linux.ibm.com>
Cc: mathias.nyman@intel.com, gregkh@linuxfoundation.org,
linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org, wenxiong@us.ibm.com,
Brian King <brking@linux.vnet.ibm.com>,
Samuel Mendoza-Jonas <sam@mendozajonas.com>,
Joel Stanley <joel@jms.id.au>
Subject: Re: [PATCH] xhci: Reset controller on xhci shutdown
Date: Thu, 15 Oct 2026 10:33:07 +0200 [thread overview]
Message-ID: <20261015103307.3ba25345.michal.pecio@gmail.com> (raw)
In-Reply-To: <64515dfd9a6cd8c3f5665e72a6bf6b81@linux.ibm.com>
On Wed, 14 Oct 2026 15:32:22 -0500, Wen Xiong wrote:
> On 2026-10-06 05:55, Michal Pecio wrote:
> > Are you able to capture the original kernel's dmesg (through serial,
> > netconsole, etc) and see if the same "Host halt failed" is there?
> >
> Below is xhci messages after executing a kexec kernel. This is dmesg
> for kexec kernel.
OK, but I asked if you have means of capturing the old kernel's dmesg
*before* the kexec kernel begins running, including any messages from
xhci_shutdown() which may possibly be logged. This can only be done
with a serial cable, the 'netconsole' module or similar tools.
But maybe don't bother with it for now. Instead, try if this modified
version of your patch works or not:
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 34f342d2c7d7..977b2b42bcfd 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -749,6 +749,7 @@ EXPORT_SYMBOL_GPL(xhci_stop);
void xhci_shutdown(struct usb_hcd *hcd)
{
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
+ int err;
if (xhci->quirks & XHCI_SPURIOUS_REBOOT)
usb_disable_xhci_ports(to_pci_dev(hcd->self.sysdev));
@@ -765,7 +766,7 @@ void xhci_shutdown(struct usb_hcd *hcd)
}
spin_lock_irq(&xhci->lock);
- xhci_halt(xhci);
+ err = xhci_halt(xhci);
/*
* Workaround for spurious wakeps at shutdown with HSW, and for boot
@@ -780,6 +781,8 @@ void xhci_shutdown(struct usb_hcd *hcd)
xhci_dbg_trace(xhci, trace_xhci_dbg_init,
"xhci_shutdown completed - status = %x",
readl(&xhci->op_regs->status));
+ if (err)
+ pci_reset_function_locked(to_pci_dev(hcd->self.sysdev));
}
EXPORT_SYMBOL_GPL(xhci_shutdown);
---
> [root@ltc-boston11 ~]# dmesg|grep xhci
> [ 1.085853] xhci_hcd 0005:01:00.0: xHCI Host Controller
> [ 1.085992] xhci_hcd 0005:01:00.0: new USB bus registered, assigned
> bus number 1
> [ 1.144472] xhci_hcd 0005:01:00.0: Host halt failed, -110
> [ 1.144518] xhci_hcd 0005:01:00.0: can't setup: -110
> [ 1.144571] xhci_hcd 0005:01:00.0: USB bus 1 deregistered
> [ 1.144778] xhci_hcd 0005:01:00.0: init 0005:01:00.0 fail, -110
> [ 1.144842] xhci_hcd 0005:01:00.0: probe with driver xhci_hcd failed
> with error -110
What about 'dmesg |grep -i xhci' (and 'grep 0005:01:00.0')?
You are likely getting errors from quirk_usb_handoff_xhci() as well.
This reminds me of a similar issue reported earlier this year:
https://lore.kernel.org/linux-usb/69fa1c3f-3ea9-42cb-a49a-7da39f72806e@molgen.mpg.de/
> This is the reason why we can't see usb devices after a kexec kernel.
No doubt about it.
> > And if you enable dynamic debug before kexec,
> >
> > echo 'module xhci_hcd +p' >/proc/dynamic_debug/control
> >
> > what's printed by the debug message at the end of xhci_shutdown()?
> >
> > Do you also get errors from quirk_usb_handoff_xhci() by any chance?
> >
> After executing a kexec kernel, is the control setting lost?
> I didn't see much useful information in control after a kexec kernel.
Yes, the kexec kernel starts with a clean dynamic debug state.
> Probably we can resubmit the patch with mathias's suggestion.
We could also try the approach in the test patch above, but doing it
properly will require a few more changes. I haven't bothered before
we know whether this helps or not.
If it doesn't help, it will look like you have something (machine FW?)
monkeying with the chip during kexec. Then we could try fixing some
known bugs in quirk_usb_handoff_xhci(). Maybe this will be enough.
Regards,
Michal
prev parent reply other threads:[~2026-10-15 8:33 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-01 22:25 wenxiong
2026-10-01 22:40 ` Mathias Nyman
2026-10-02 14:08 ` Wen Xiong
2026-10-02 8:29 ` Michal Pecio
2026-10-02 14:05 ` Wen Xiong
2026-10-02 14:18 ` Michal Pecio
2026-10-05 13:01 ` Wen Xiong
2026-10-06 10:55 ` Michal Pecio
2026-10-14 20:32 ` Wen Xiong
2026-10-15 8:33 ` Michal Pecio [this message]
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=20261015103307.3ba25345.michal.pecio@gmail.com \
--to=michal.pecio@gmail.com \
--cc=brking@linux.vnet.ibm.com \
--cc=gregkh@linuxfoundation.org \
--cc=joel@jms.id.au \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=mathias.nyman@intel.com \
--cc=sam@mendozajonas.com \
--cc=stable@vger.kernel.org \
--cc=wenxiong@linux.ibm.com \
--cc=wenxiong@us.ibm.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®