All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mathias Nyman <mathias.nyman@linux.intel.com>
To: Haowen Bai <calvin.bai@ugreen.com>, mathias.nyman@intel.com
Cc: gregkh@linuxfoundation.org, linux-usb@vger.kernel.org,
	linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH] usb: pci-quirks: abort xHCI handoff if MMIO is inaccessible
Date: Thu, 10 Sep 2026 16:35:55 +0300	[thread overview]
Message-ID: <cb0ffb2a-a102-4653-8362-f846b514bce0@linux.intel.com> (raw)
In-Reply-To: <A8558181A93455E3+20260906162614.26940-1-calvin.bai@ugreen.com>

On 9/6/26 19:26, Haowen Bai wrote:
> The xHCI early handoff quirk polls the BIOS ownership, CNR, and HALT bits
> with readl_poll_timeout_atomic(). Unlike xhci_handshake(), handshake()
> does not treat an all-ones read as an inaccessible controller.
> 
> If the controller becomes inaccessible, readl() can return U32_MAX. The CNR
> bit then never clears, and the atomic poll keeps retrying. The atomic poll
> budget is decremented using the requested delay and loop iterations, but
> not the time spent in readl(). Slow failed MMIO reads can therefore keep
> the PCI hotplug thread spinning far beyond the nominal timeout and trigger
> a soft lockup. The 26-second value in the first warning is the watchdog
> threshold, not the handshake timeout; repeated warnings showed the thread
> still stuck up to 260 seconds before a controlled reboot, leaving the
> system unavailable to normal management. Comparing the watchdog timestamps
> with the RBP loop counter in the dumps (about 1,372 iterations in 26 s and
> 15,638 in 260 s) implies roughly 16-19 ms per polling iteration, despite
> configured 10 us delay; these values are inferred, not direct measurements
> of an individual readl().
> 
> Return -ENODEV when the polled register reads U32_MAX and stop the handoff
> before issuing further accesses. This prevents an inaccessible xHCI from
> keeping the PCI hotplug thread busy and making the system unavailable. An
> eGPU may still fail to enumerate, but that failure must remain controlled
> rather than causing a kernel Soft Lockup and taking down SSH or desktop
> management. The existing timeout behavior for non-all-ones reads is
> preserved, matching xhci_handshake().
> 
> A Thunderbolt-attached AMD Radeon Pro W5700 in a Razer Core X enclosure
> reproduced this on an x86_64 UGREEN DXP8800 Plus with an Intel Core
> i5-1235U. The GPU's xHCI function 0000:06:00.2 (1002:7316) triggered
> the soft lockup in irq/123-pciehp; the register dump contained
> RAX=U32_MAX:
> 
>    watchdog: BUG: soft lockup - CPU#6 stuck for 26s! [irq/123-pciehp:139]
>    RIP: 0010:quirk_usb_early_handoff+0x552/0x7e0
>    register state: RAX=00000000ffffffff
> 
> The call trace was:
> 
>    pci_do_fixups
>    pci_bus_add_device
>    pci_bus_add_devices
>    pciehp_configure_device
>    pciehp_handle_presence_or_link_change
>    pciehp_ist
>    irq_thread_fn
> 
> The failure reproduced on two hot-plug attempts and did not occur when the
> enclosure was connected before boot.
> 
> Fixes: 66d4eadd8d06 ("USB: xhci: BIOS handoff and HW initialization.")
> Cc: stable@vger.kernel.org
> Signed-off-by: Haowen Bai <calvin.bai@ugreen.com>
Acked-by: Mathias Nyman <mathias.nyman@linux.intel.com>

  reply	other threads:[~2026-09-10 13:36 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-06 16:26 [PATCH] usb: pci-quirks: abort xHCI handoff if MMIO is inaccessible Haowen Bai
2026-09-10 13:35 ` Mathias Nyman [this message]
2026-09-13 12:53 ` Lukas Wunner

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=cb0ffb2a-a102-4653-8362-f846b514bce0@linux.intel.com \
    --to=mathias.nyman@linux.intel.com \
    --cc=calvin.bai@ugreen.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=mathias.nyman@intel.com \
    --cc=stable@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.