From: bugzilla-daemon@kernel.org
To: linux-usb@vger.kernel.org
Subject: [Bug 219824] [6.13 regression] USB controller just died
Date: Fri, 14 Mar 2025 09:06:39 +0000 [thread overview]
Message-ID: <bug-219824-208809-j7cqbZbT2f@https.bugzilla.kernel.org/> (raw)
In-Reply-To: <bug-219824-208809@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=219824
--- Comment #22 from Artem S. Tashkinov (aros@gmx.com) ---
6.13.7 absolutely includes it:
https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.13.7
> commit 80cb8e694110dee4ac6fbf0956ba7439aeb0603d
> Author: Michal Pecio <michal.pecio@gmail.com>
> Date: Tue Mar 4 13:31:47 2025 +0200
>
> usb: xhci: Fix host controllers "dying" after suspend and resume
>
> commit c7c1f3b05c67173f462d73d301d572b3f9e57e3b upstream.
>
> A recent cleanup went a bit too far and dropped clearing the cycle bit
> of link TRBs, so it stays different from the rest of the ring half of
> the time. Then a race occurs: if the xHC reaches such link TRB before
> more commands are queued, the link's cycle bit unintentionally matches
> the xHC's cycle so it follows the link and waits for further commands.
> If more commands are queued before the xHC gets there, inc_enq() flips
> the bit so the xHC later sees a mismatch and stops executing commands.
>
> This function is called before suspend and 50% of times after resuming
> the xHC is doomed to get stuck sooner or later. Then some Stop Endpoint
> command fails to complete in 5 seconds and this shows up
>
> xhci_hcd 0000:00:10.0: xHCI host not responding to stop endpoint command
> xhci_hcd 0000:00:10.0: xHCI host controller not responding, assume dead
> xhci_hcd 0000:00:10.0: HC died; cleaning up
>
> followed by loss of all USB decives on the affected bus. That's if you
> are lucky, because if Set Deq gets stuck instead, the failure is silent.
>
> Likely responsible for kernel bug 219824. I found this while searching
> for possible causes of that regression and reproduced it locally before
> hearing back from the reporter. To repro, simply wait for link cycle to
> become set (debugfs), then suspend, resume and wait. To accelerate the
> failure I used a script which repeatedly starts and stops a UVC camera.
>
> Some HCs get fully reinitialized on resume and they are not affected.
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
next prev parent reply other threads:[~2025-03-14 9:06 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-26 22:23 [Bug 219824] New: [6.13 regression] USB controller just died bugzilla-daemon
2025-02-26 22:28 ` [Bug 219824] " bugzilla-daemon
2025-02-26 22:31 ` bugzilla-daemon
2025-02-26 22:47 ` bugzilla-daemon
2025-02-27 12:58 ` bugzilla-daemon
2025-02-27 15:12 ` bugzilla-daemon
2025-02-27 16:05 ` bugzilla-daemon
2025-02-27 17:14 ` bugzilla-daemon
2025-02-27 21:07 ` bugzilla-daemon
2025-02-28 19:49 ` bugzilla-daemon
2025-02-28 20:10 ` bugzilla-daemon
2025-03-03 13:54 ` bugzilla-daemon
2025-03-03 15:42 ` bugzilla-daemon
2025-03-03 19:23 ` bugzilla-daemon
2025-03-03 22:38 ` bugzilla-daemon
2025-03-06 11:15 ` bugzilla-daemon
2025-03-06 11:54 ` bugzilla-daemon
2025-03-06 11:57 ` bugzilla-daemon
2025-03-06 12:03 ` bugzilla-daemon
2025-03-07 23:28 ` bugzilla-daemon
2025-03-08 6:56 ` bugzilla-daemon
2025-03-14 8:42 ` bugzilla-daemon
2025-03-14 9:06 ` bugzilla-daemon [this message]
2025-03-14 10:49 ` 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-219824-208809-j7cqbZbT2f@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).