linux-kernel - Re: TI PCIe xHCI and kexec

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 5 Feb 2020 11:37:29 +0200
From:   Mathias Nyman <mathias.nyman@...ux.intel.com>
To:     Joel Stanley <joel@....id.au>,
        Mathias Nyman <mathias.nyman@...el.com>,
        linux-usb@...r.kernel.org
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Michael Ellerman <mpe@...erman.id.au>
Subject: Re: TI PCIe xHCI and kexec

On 5.2.2020 2.55, Joel Stanley wrote:
> I'm supporting a system that uses Linux-as-a-bootloader to load a
> distro kernel via kexec, The systems have a TI TUSB73x0 PCIe
> controller which goes out to lunch after a kexec. This is the distro
> (post-kexec) kernel:
> 
> [    0.235411] pci 0003:01:00.0: xHCI HW did not halt within 16000
> usec status = 0x0
> [    1.037298] xhci_hcd 0003:01:00.0: xHCI Host Controller
> [    1.037367] xhci_hcd 0003:01:00.0: new USB bus registered, assigned
> bus number 1
> [    1.053481] xhci_hcd 0003:01:00.0: Host halt failed, -110
> [    1.053523] xhci_hcd 0003:01:00.0: can't setup: -110
> [    1.053565] xhci_hcd 0003:01:00.0: USB bus 1 deregistered
> [    1.053629] xhci_hcd 0003:01:00.0: init 0003:01:00.0 fail, -110
> [    1.053703] xhci_hcd: probe of 0003:01:00.0 failed with error -110
> 
> There were some fixes made a few years back to improve the situation,
> but we've still had to carry some form of the patch below in the
> bootloader kernel. I would like to rework it so it can be merged.
> 
> diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
> index dbac0fa9748d..eaa94456dd9d 100644
> --- a/drivers/usb/host/xhci.c
> +++ b/drivers/usb/host/xhci.c
> @@ -789,6 +789,9 @@ 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));
> +
> +    /* TI XHCI controllers do not come back after kexec without this hack */
> +    pci_reset_function_locked(to_pci_dev(hcd->self.sysdev));
>   }
>   EXPORT_SYMBOL_GPL(xhci_shutdown);
> 
> I would like some advice on how to implement it in a way that is
> acceptable. Would a quirk on the pci id in xhci_shutdown be ok?

Yes, but as this is a pci specific workaround the quirk should go to
xhci-pci.c: xhci_pci_shutdown(), which was added in v5.5

Is the rootcause known?
Is the only possible solution to reset the pci function?.
Have you tried, or seen this issue on any other controller than this TUSB73x0?

> 
> 0003:01:00.0 USB controller: Texas Instruments TUSB73x0 SuperSpeed USB
> 3.0 xHCI Host Controller (rev 02)
> 
> The full debug log of the distro kernel booting is below.
> 
> [    1.037833] xhci_hcd 0003:01:00.0: USBCMD 0x0:
> [    1.037835] xhci_hcd 0003:01:00.0:   HC is being stopped
> [    1.037837] xhci_hcd 0003:01:00.0:   HC has finished hard reset
> [    1.037839] xhci_hcd 0003:01:00.0:   Event Interrupts disabled
> [    1.037841] xhci_hcd 0003:01:00.0:   Host System Error Interrupts disabled
> [    1.037843] xhci_hcd 0003:01:00.0:   HC has finished light reset
> [    1.037846] xhci_hcd 0003:01:00.0: USBSTS 0x0:
> [    1.037847] xhci_hcd 0003:01:00.0:   Event ring is empty
> [    1.037849] xhci_hcd 0003:01:00.0:   No Host System Error
> [    1.037851] xhci_hcd 0003:01:00.0:   HC is running

Hmm, all bits in both USBCMD and USBSTS are 0. This is a bit suspicious.
Normally at least USBCMD Run/Stop bit, and USBSTS HCHalted bit have
opposite values.

-Mathias