Linux USB
 help / color / mirror / Atom feed
From: Mathias Nyman <mathias.nyman@linux.intel.com>
To: Andreas Hartmann <andihartmann@01019freenet.de>,
	linux-usb@vger.kernel.org
Subject: Re: USB2 / USB3 compatibility problems: xhci_hcd 0000:00:06.0: WARN Wrong bounce buffer write length: 0 != 512
Date: Thu, 28 Jan 2021 16:14:09 +0200	[thread overview]
Message-ID: <ab675d28-d80f-ed72-5db0-943cb26819f1@linux.intel.com> (raw)
In-Reply-To: <9c3c9dd7-bcfb-785c-8c11-39f78a7fca01@01019freenet.de>


>> If I'm understanding it correctly, you're always creating a bounce
>> buffer though it is not necessary (at least in my case - my test patch
>> proofed, that no changes at all are necessary). Why aren't you checking
>> for URB_NO_TRANSFER_DMA_MAP at the very beginning? Or is it your purpose
>> to first basically test your new code path? That would be ok.

Bounce buffer is only used when there is no other way of meeting the xHCI
alignment requirements. Worst case is once every 255 TRB, and for maximum 1024bytes.
Each TRB can point to 64K of data.

I can't go against the spec just because it doesn't cause issues in your
two usecases. The overhead of the bounce buffer usage is so small there's no
point in that kind of optimization.

URB_NO_TRANSFER_DMA_MAP only indicates the data was DMA mapped before driver 
submitted the URB, so usb core does not need to map it.

I was speculating that it could be a cause why data is so oddly aligned
(urbs with data starting at less than 512 bytes from 64k boundary), and
thus not meeting the xHC boundary and aligment requirements even if data
is otherwise contiguous.

xHC controller doesn't care who mapped the data, or if data is in a sg list
or already contiguous in urb->transfer_buffer as long as we follow
the aligment and boudary rules.

Bug was that driver assumed the data that needed to be bounce
buffered was in a sg list. Your cased proved it could be in
urb->tranfer_buffer instead.

>>
>> I tested with the notebook (in both directions) - it seems to work - I
>> didn't get any problems though I used 24 kB bulk packets. Throughput was
>> unaltered high.
>>
>> I'm doing the same test tomorrow with the other USB 3.1 controller!
> 
> Successfully tested on the other USB 3.1 host.
> 

Thank you, much appreciated.

I think I'll submit this patch as it is (with a proper commit message)
can I add reported-by: Andreas Hartmann <andihartmann@01019freenet.de>, and
tested-by: Andreas Hartmann <andihartmann@01019freenet.de> tags to the patch?

-Mathias

  reply	other threads:[~2021-01-28 14:14 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-22  8:06 USB2 / USB3 compatibility problems: xhci_hcd 0000:00:06.0: WARN Wrong bounce buffer write length: 0 != 512 Andreas Hartmann
2021-01-22  8:09 ` Andreas Hartmann
2021-01-24 17:28   ` Andreas Hartmann
2021-01-25 10:18     ` Andreas Hartmann
2021-01-25 18:28       ` Mathias Nyman
2021-01-25 18:48         ` Andreas Hartmann
2021-01-25 20:06         ` Andreas Hartmann
2021-01-26  7:26           ` Andreas Hartmann
2021-01-26 14:11             ` Mathias Nyman
2021-01-26 17:29               ` Mathias Nyman
2021-01-26 17:48                 ` Andreas Hartmann
2021-01-26 21:16                 ` Andreas Hartmann
2021-01-27  6:43                   ` Andreas Hartmann
2021-01-28 14:14                     ` Mathias Nyman [this message]
2021-01-28 17:01                       ` Andreas Hartmann
2021-01-28 17:36                       ` Andreas Hartmann
2021-01-28 18:27                       ` Andreas Hartmann

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=ab675d28-d80f-ed72-5db0-943cb26819f1@linux.intel.com \
    --to=mathias.nyman@linux.intel.com \
    --cc=andihartmann@01019freenet.de \
    --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