From: Thorsten Leemhuis <regressions@leemhuis.info>
To: Hans de Goede <hdegoede@redhat.com>,
Mathias Nyman <mathias.nyman@intel.com>,
Pavankumar Kondeti <pkondeti@codeaurora.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-usb <linux-usb@vger.kernel.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: <3a5e7a4d-9986-9862-b601-cd7e8bd06855@leemhuis.info> (raw)
In-Reply-To: <0a4d723c-221f-a42a-434c-34283a4cdab7@redhat.com>
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://lore.kernel.org/lkml/35f7428b39f996c793f5b4a6a314772681c73d7a.camel@apache.org/
This commit should improve the situation (and afaics hopefully fix all
problems related to it):
https://lore.kernel.org/stable/20211126122340.1193239-2-mathias.nyman@linux.intel.com/
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://lore.kernel.org/lkml/35f7428b39f996c793f5b4a6a314772681c73d7a.camel@apache.org/
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 Regression: "xhci: Fix command ring pointer corruption while aborting a command" breaks USB on Intel controllers 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 \
--in-reply-to=3a5e7a4d-9986-9862-b601-cd7e8bd06855@leemhuis.info \
--to=regressions@leemhuis.info \
--cc=gregkh@linuxfoundation.org \
--cc=hdegoede@redhat.com \
--cc=linux-usb@vger.kernel.org \
--cc=mathias.nyman@intel.com \
--cc=pkondeti@codeaurora.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).