All of lore.kernel.org
 help / color / mirror / Atom feed
From: bugzilla-daemon@kernel.org
To: linux-usb@vger.kernel.org
Subject: [Bug 221103] xhci_hcd: System lockup under CPU load during usbfs polling of USB devices on AMD platforms
Date: Sun, 30 Aug 2026 21:51:08 +0000	[thread overview]
Message-ID: <bug-221103-208809-ihEU1YJ6yw@https.bugzilla.kernel.org/> (raw)
In-Reply-To: <bug-221103-208809@https.bugzilla.kernel.org/>

https://bugzilla.kernel.org/show_bug.cgi?id=221103

--- Comment #33 from Andrew Skalski (voltara@gmail.com) ---
(In reply to Michał Pecio from comment #32)
> Your finding is curious. Does it mean it would still work if you add
> msleep(10) immediately before the failing line and not earlier?

Yes it works there as well, except you need to use mdelay instead of msleep. 
For that reason, and because xhci_set_cmd_ring_deq is used elsewhere, I moved
the msleep just outside the atomic section in xhci_resume for the proof of
concept.

The reason I tried adding the delay was because I noticed enabling debug
logging made the problem go away.  This made me suspect the lockup was timing
related.

Thanks for the link to the other bug reports.  I'll have a read through them.


On a separate topic, I did some further investigation into my crashes to tie up
some loose ends about the trigger:

1) I'm pretty confident that it's just the two "1022:14c9" controllers that are
causing my crashes.  I have been running an unpatched kernel with
'/sys/bus/pci/devices/<pci-id>/power/control == on' just for those two, and it
has been perfectly stable.

2) The crashes that resulted from plugging in USB devices were somewhat of a
red herring.  A daemon on my system (colord) was reacting to the plug events by
scanning everything in /dev/bus/usb.  So in all cases the underlying trigger
was actually the same: resuming the "1022:14c9" controllers by accessing their
device nodes in /dev/bus/usb.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

  parent reply	other threads:[~2026-08-30 21:51 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-18 14:52 [Bug 221103] New: xhci_hcd: System lockup under CPU load during rapid usbfs polling of SuperSpeed root hubs on AMD Ryzen platforms bugzilla-daemon
2026-02-20  7:30 ` [Bug 221103] xhci_hcd: System lockup under CPU load during usbfs polling of USB devices on AMD platforms bugzilla-daemon
2026-02-20  8:31 ` bugzilla-daemon
2026-02-20  9:17   ` Greg KH
2026-02-20  9:16 ` bugzilla-daemon
2026-02-20  9:17 ` bugzilla-daemon
2026-02-20  9:24 ` bugzilla-daemon
2026-02-20  9:26 ` bugzilla-daemon
2026-02-20  9:28 ` bugzilla-daemon
2026-02-20  9:40 ` bugzilla-daemon
2026-02-20 10:07 ` bugzilla-daemon
2026-02-20 10:17   ` Greg KH
2026-02-20 10:17 ` bugzilla-daemon
2026-02-20 10:21 ` bugzilla-daemon
2026-02-20 11:19 ` bugzilla-daemon
2026-02-20 14:07 ` bugzilla-daemon
2026-02-20 17:18 ` bugzilla-daemon
2026-02-21  1:12 ` bugzilla-daemon
2026-02-23 13:05 ` bugzilla-daemon
2026-02-23 17:52 ` bugzilla-daemon
2026-02-23 22:33 ` bugzilla-daemon
2026-02-24  7:45 ` bugzilla-daemon
2026-02-24  8:52 ` bugzilla-daemon
2026-02-24 10:19 ` bugzilla-daemon
2026-02-24 12:03 ` bugzilla-daemon
2026-02-24 12:21 ` bugzilla-daemon
2026-02-24 15:42 ` bugzilla-daemon
2026-03-08 17:56 ` bugzilla-daemon
2026-07-09 11:58 ` bugzilla-daemon
2026-08-28  3:49 ` bugzilla-daemon
2026-08-28  5:52 ` bugzilla-daemon
2026-08-28 12:19 ` bugzilla-daemon
2026-08-28 12:28 ` bugzilla-daemon
2026-08-30  1:50 ` bugzilla-daemon
2026-08-30 20:57 ` bugzilla-daemon
2026-08-30 21:51 ` bugzilla-daemon [this message]
2026-08-31  2:56 ` bugzilla-daemon
2026-08-31 15:51 ` bugzilla-daemon
2026-08-31 19:32 ` bugzilla-daemon
2026-09-01  1:56 ` bugzilla-daemon
2026-09-01  9:09 ` bugzilla-daemon
2026-09-01  9:41 ` bugzilla-daemon
2026-09-03 21:59 ` bugzilla-daemon
2026-09-03 22:12 ` bugzilla-daemon

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=bug-221103-208809-ihEU1YJ6yw@https.bugzilla.kernel.org/ \
    --to=bugzilla-daemon@kernel.org \
    --cc=linux-usb@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.