From: Sarah Sharp <sarah.a.sharp@linux.intel.com>
To: David Laight <David.Laight@ACULAB.COM>
Cc: "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
David Miller <davem@davemloft.net>,
Dan Williams <dan.j.williams@intel.com>,
"Nyman, Mathias" <mathias.nyman@intel.com>,
Mark Lord <mlord@pobox.com>,
Alan Stern <stern@rowland.harvard.edu>,
Freddy Xin <freddy@asix.com.tw>
Subject: Re: [PATCH RFC 1/1] usb: Tell xhci when usb data might be misaligned
Date: Thu, 30 Jan 2014 13:18:16 -0800 [thread overview]
Message-ID: <20140130211816.GB3787@xanatos> (raw)
On Thu, Jan 30, 2014 at 05:35:08PM +0100, Peter Stuge wrote:
> David Laight wrote:
> > > Where's the 8k coming from?
> >
> > My memory, I meant 16k :-(
>
> No problem. But what about that alignment? It seems that userspace
> needs to start caring about alignment with xhci, right?
We need to step back and reassess the larger picture here, instead of
trying to fire-fight all the regressions caused by the link TRB commit
(35773dac5f86 "usb: xhci: Link TRB must not occur within a USB payload
burst").
We shouldn't need to make userspace start to worry about alignment at
all. libusb worked in the past, before the link TRB fix went in. We
*cannot* break userspace USB drivers. The breakage needs to be fixed in
the USB core or the xHCI driver.
Commit 35773dac5f86 was meant to be a short-term bandaid fix, but it's
already caused at least four different regressions. Some we've fixed,
some have proposed solutions that David has sent.
The storage layer is getting borked because it submits scatter-gather
lists longer than what will fit on a segment, and now libusb has the
same issue. One xHCI host controller stopped responding to commands,
and reverting the bandaid fix helped. The implications of this change
just keep coming in, and I'm not comfortable wall-papering over the
issues.
On the flip side, it seems that the only devices that have been helped
by the bandaid fix patch are USB ethernet devices using the ax88179_178a
driver. (Mark Lord still needs to confirm which device he uses.) I
have not seen any other reports that other USB ethernet chipsets were
broken in 3.12 by the USB networking layer adding scatter-gather
support.
It should not matter what alignment or length of scatter-gather list the
upper layers pass the xHCI driver, it should just work. I want to do
this fix right, by changing the fundamental way we queue TRBs to the
rings to fit the TD rules. We should break each TD into fragment-sized
chunks, and add a link TRB in the middle of a segment where necessary.
Let's do this fix the right way, instead of wall papering over the
issue. Here's what we should do:
1. Disable scatter-gather for the ax88179_178a driver when it's under an
xHCI host.
2. Revert the following commits:
f2d9b991c549 xhci: Set scatter-gather limit to avoid failed block writes.
d6c9ea9069af xhci: Avoid infinite loop when sg urb requires too many trbs
35773dac5f86 usb: xhci: Link TRB must not occur within a USB payload burst
3. Dan and Mathias can work together to come up with an overall plan to
change the xHCI driver architecture to be fully compliant with the TD
fragment rules. That can be done over the next few kernel releases.
The end result is that we don't destabilize storage or break userspace
USB drivers, we don't break people's xHCI host controllers,
the ax88179_178a USB ethernet devices still work under xHCI (a bit with
worse performance), and other USB ethernet devices still get the
performance improvement introduced in 3.12.
Sarah Sharp
next reply other threads:[~2014-01-30 21:18 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-30 21:18 Sarah Sharp [this message]
2014-01-30 21:39 ` [PATCH RFC 1/1] usb: Tell xhci when usb data might be misaligned Mark Lord
2014-01-30 21:42 ` Mark Lord
2014-01-30 21:43 ` Alan Stern
2014-01-30 21:48 ` Mark Lord
2014-01-30 21:55 ` Sarah Sharp
2014-01-30 22:05 ` Bjørn Mork
2014-01-30 22:07 ` Alan Stern
2014-01-30 21:50 ` Bjørn Mork
2014-01-30 22:15 ` Sarah Sharp
2014-01-31 0:17 ` Ming Lei
2014-01-31 19:00 ` Sarah Sharp
2014-02-01 7:54 ` Ming Lei
2014-02-01 13:30 ` Mark Lord
2014-02-01 14:18 ` Ming Lei
2014-02-01 20:05 ` Mark Lord
[not found] ` <52ED5381.2010106-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org>
2014-02-03 9:54 ` David Laight
2014-02-03 17:56 ` Sarah Sharp
2014-02-03 17:55 ` Sarah Sharp
2014-01-31 15:22 ` David Laight
2014-01-31 10:14 ` David Laight
2014-01-31 13:21 ` Peter Stuge
2014-01-31 13:52 ` David Laight
-- strict thread matches above, loose matches on Subject: below --
2014-01-30 16:00 David Laight
[not found] ` <063D6719AE5E284EB5DD2968C1650D6D0F6B5486-VkEWCZq2GCInGFn1LkZF6NBPR1lH4CV8@public.gmane.org>
2014-01-30 16:17 ` Peter Stuge
[not found] ` <20140130161721.25560.qmail-Y+HMSxxDrH8@public.gmane.org>
2014-01-30 16:30 ` David Laight
[not found] ` <063D6719AE5E284EB5DD2968C1650D6D0F6B553D-VkEWCZq2GCInGFn1LkZF6NBPR1lH4CV8@public.gmane.org>
2014-01-30 16:35 ` Peter Stuge
2014-01-31 9:30 ` David Laight
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=20140130211816.GB3787@xanatos \
--to=sarah.a.sharp@linux.intel.com \
--cc=David.Laight@ACULAB.COM \
--cc=dan.j.williams@intel.com \
--cc=davem@davemloft.net \
--cc=freddy@asix.com.tw \
--cc=gregkh@linuxfoundation.org \
--cc=linux-usb@vger.kernel.org \
--cc=mathias.nyman@intel.com \
--cc=mlord@pobox.com \
--cc=netdev@vger.kernel.org \
--cc=stern@rowland.harvard.edu \
/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).