From: Thorsten Leemhuis <email@example.com> To: Hans de Goede <firstname.lastname@example.org>, Mathias Nyman <email@example.com>, Pavankumar Kondeti <firstname.lastname@example.org>, Greg Kroah-Hartman <email@example.com> Cc: linux-usb <firstname.lastname@example.org> Subject: Re: Regression: "xhci: Fix command ring pointer corruption while aborting a command" breaks USB on Intel controllers Date: Sun, 5 Dec 2021 07:46:39 +0100 [thread overview] Message-ID: <email@example.com> (raw) In-Reply-To: <firstname.lastname@example.org> Hi, this is your Linux kernel regression tracker speaking. On 04.12.21 15:15, Hans de Goede wrote: > Hi All, > > There are several bug reports (arch and Fedora) about USB problems > starting with kernel 5.14.14 (5.14.13 is ok): > > https://bugzilla.redhat.com/show_bug.cgi?id=2019788 > https://bbs.archlinux.org/viewtopic.php?pid=2006862 > > And 5.16.6, which has the hub address0_mutex fixes does not > fix these problems for some users. > > Looking at the history between those 2 commit ff0e50d3564f > ("xhci: Fix command ring pointer corruption while aborting a command"): > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ff0e50d3564f > > stood out to me as a possible cause of this. So I've build > a test 5.15.6 kernel for Fedora users with that commit reverted > and 2 users have now reported that this fixes things for them > (see https://bugzilla.redhat.com/show_bug.cgi?id=2019788). > > The reason why this stood out to me is because doing a 32 bit > write over a possibly 64 bit databus to the xHCI controller may > result in the hw doing a 64 bit read + modify 32 bit + 64 bit write, > so I think that the following is happening after the commit: > > sw: read 32 bit > hw: read 64 bit, return 32 bit > sw: modify it > sw: write 32 bit > hw: read 64 bit > hw: modify 32 bit of 64 bit wor5d > hw: write 64 bit > > Which actually makes the chances of hitting the problem the commit > tries to fix larger on controllers using a 64 bit data bus. > > Note this is just a theory, but it seems plausible to me. > > All problem reports are people using integrated Intel xHCI controllers > which I believe are likely to use a 64 bit data-bus. FWIW, the commit is known to cause problems, one of them is found here: https://email@example.com/ This commit should improve the situation (and afaics hopefully fix all problems related to it): https://firstname.lastname@example.org/ Greg wants to sent it upstream today: https://lore.kernel.org/lkml/YatGfEzzniH%2FSrn4@kroah.com/ Guess he soon after will backport it to the stable trees as well. HTH, Ciao, Thorsten #regzbot ^backmonitor https://email@example.com/
next prev parent reply other threads:[~2021-12-05 6:46 UTC|newest] Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-12-04 14:15 Hans de Goede 2021-12-05 6:46 ` Thorsten Leemhuis [this message] 2021-12-05 8:20 ` Greg Kroah-Hartman 2021-12-05 8:20 ` Greg Kroah-Hartman 2021-12-05 12:48 ` Greg Kroah-Hartman 2021-12-07 0:46 ` Tobias Bachmann
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 \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: Regression: "xhci: Fix command ring pointer corruption while aborting a command" breaks USB on Intel controllers' \ /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
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).