From: Kishon Vijay Abraham I <kishon@ti.com>
To: Christoph Hellwig <hch@lst.de>
Cc: "linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>
Subject: Re: pci-usb/pci-sata broken with LPAE config after "reduce use of block bounce buffers"
Date: Thu, 2 Apr 2020 17:31:32 +0530 [thread overview]
Message-ID: <c832540a-802a-e361-758d-67f387ae37a5@ti.com> (raw)
In-Reply-To: <a7d920ab-b681-45bc-677b-3db76e96cf7c@ti.com>
Hi Christoph,
On 2/18/2020 5:45 PM, Kishon Vijay Abraham I wrote:
> Christoph,
>
> On 17/02/20 7:53 pm, Christoph Hellwig wrote:
>> On Wed, Feb 05, 2020 at 05:05:42PM +0100, Christoph Hellwig wrote:
>>> On Wed, Feb 05, 2020 at 03:03:13PM +0530, Kishon Vijay Abraham I wrote:
>>>> Yes, I see the mismatch after reverting the above patches.
>>>
>>> In which case the data mismatch is very likely due to a different root
>>> cause.
>>
>> Did you manage to dig into this a little more?
>
> I'll probably get to this later half of this week. Will update you then.
>
Sorry for the delay in getting back to this. But I guess I have root caused the
issue now.
The issue was because NVMe is requesting a sector size (4096KB) which is more
than what is supported by SWIOTLB default (256KB). NVMe driver actually has a
mechanism to select the correct sector size
dev->ctrl.max_hw_sectors = min_t(u32,
NVME_MAX_KB_SZ << 1, dma_max_mapping_size(dev->dev) >> 9);
However dma_max_mapping_size() here misbehaves and gives 4G. Ideally it should
have given 256KB -> the max supported by SWIOTLB
Tracing through the dma_max_mapping_size(), dma_direct_max_mapping_size() was
giving incorrect value
size_t dma_direct_max_mapping_size(struct device *dev)
{
/* If SWIOTLB is active, use its maximum mapping size */
if (is_swiotlb_active() &&
(dma_addressing_limited(dev) || swiotlb_force == SWIOTLB_FORCE))
return swiotlb_max_mapping_size(dev);
return SIZE_MAX;
}
In the above function swiotlb_max_mapping_size(dev) gives 256KB however
dma_addressing_limited(dev) always returns false. So 256KB is never returned to
the NVMe driver.
Tracing dma_addressing_limited(dev), found a bug in
dma_direct_get_required_mask(). When it passes the physical address to
phys_to_dma_direct(), the upper 32 bit is lost and dma_addressing_limited(dev)
thinks the entire address is accessible by the device.
A patch that type casts the argument of phys_to_dma_direct() like below fixes
the issue.
diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index 32ec69cdba54..0081410334c8 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -51,7 +51,9 @@ static inline struct page *dma_direct_to_page(struct device
*dev, u64 dma_direct_get_required_mask(struct device *dev)
{
- u64 max_dma = phys_to_dma_direct(dev, (max_pfn - 1) << PAGE_SHIFT);
+ u64 max_dma =
+ phys_to_dma_direct(dev,
+ (phys_addr_t)(max_pfn - 1) << PAGE_SHIFT);
return (1ULL << (fls64(max_dma) - 1)) * 2 - 1;
}
If this looks okay to you, I can post a patch for it.
Thanks
Kishon
prev parent reply other threads:[~2020-04-02 12:01 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-15 10:59 pci-usb/pci-sata broken with LPAE config after "reduce use of block bounce buffers" Kishon Vijay Abraham I
2019-11-15 13:06 ` Christoph Hellwig
2019-11-15 14:18 ` Kishon Vijay Abraham I
2019-11-16 16:35 ` Christoph Hellwig
2019-11-18 17:21 ` Robin Murphy
2019-11-25 5:43 ` Kishon Vijay Abraham I
2020-01-27 13:10 ` Kishon Vijay Abraham I
2020-01-27 13:22 ` Robin Murphy
2020-01-29 6:24 ` Kishon Vijay Abraham I
2020-01-30 7:58 ` Christoph Hellwig
2020-01-30 8:09 ` Kishon Vijay Abraham I
2020-01-30 16:42 ` Christoph Hellwig
2020-01-31 11:44 ` Kishon Vijay Abraham I
2020-02-03 14:21 ` Christoph Hellwig
2020-02-05 5:15 ` Kishon Vijay Abraham I
2020-02-05 7:47 ` Christoph Hellwig
2020-02-05 8:32 ` Kishon Vijay Abraham I
2020-02-05 8:48 ` Christoph Hellwig
2020-02-05 9:18 ` Kishon Vijay Abraham I
2020-02-05 9:19 ` Christoph Hellwig
2020-02-05 9:33 ` Kishon Vijay Abraham I
2020-02-05 16:05 ` Christoph Hellwig
2020-02-17 14:23 ` Christoph Hellwig
2020-02-18 12:15 ` Kishon Vijay Abraham I
2020-04-02 12:01 ` Kishon Vijay Abraham I [this message]
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=c832540a-802a-e361-758d-67f387ae37a5@ti.com \
--to=kishon@ti.com \
--cc=hch@lst.de \
--cc=linux-pci@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).