Hello,
I'm working on a driver that does a get_user_pages() for a DMA write. We
have a timeout on the DMA completion where we mark the pages as COW and return
to the application so it can potentially generate more data in order to
increase throughput, etc. The problem is that when we traverse
--- Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> you forgot to attach your source code or provide a URL to it.
Sorry, my bad. I'm just diving into Linux for the first time and wasn't
aware of the protocols. Here's the code fragment I'm currently using:
address = skb_vaddr(skb) &
--- Hugh Dickins <[EMAIL PROTECTED]> wrote:
> I can't speak for Red Hat 4.4; but in general, you should be passing the
> write flag to get_user_pages if you're going to modify the content of
> those pages, which will then allocate the hierarchy needed and break
> COW where necessary.
yes, that
--- Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> On Wed, 2007-06-27 at 11:53 -0700, Casey Leedom wrote:
> > Sorry, my bad. I'm just diving into Linux for the first time and wasn't
> > aware of the protocols. Here's the code fragment I'm currently
Nevermind. I realized I was being an idiot. Sorry for the wasted bandwidth.
Basically, if we have a page that get_user_pages() returned to us, the only
way any part of the PGD/PUD/PMD maping hierarchy can be missing is if the page
is the ZERO_PAGE(). Thus I can use this to detect my ZERO_PA
ra.org; sulr...@codeaurora.org
Cc: linux-arm-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; Sinan
Kaya; Ganesh GR; Casey Leedom; linux-kernel@vger.kernel.org
Subject: [PATCH v4 12/17] net: cxgb4/cxgb4vf: Eliminate duplicate barriers on
weakly-ordered archs
Code includes wmb(
| From: Steve Wise
| Sent: Thursday, March 22, 2018 9:28 AM
|
| | From: Sinan Kaya
| | Date: Thursday, March 22, 2018 7:52 AM
| |
| | Isn't this a PowerPC problem? Why penalize other architectures?
|
| I worry it breaks PPC.
And all other architectures. Aparraently there isn't a formal API
des
Yes, but ...
For instance, I see that the x86 writel() has "memory" in its asm(), which
prevents GCC from reordering generated instructions. And it ~looks like~
arm64 ~sort of~ gets that with the inclusion of __iowmb() (which translates
to wmb() then dsb(st) which finally holds the GCC "memory" b
Okay, thanks Sinan. I ~think~ we're on the same page here.
Our guy Michael Werner is carefully going through our drivers with Steve
Wise. I'd like to let them work on the changes with a lot of thought and
testing before diving in too far.
We had thought that we could get around the lack o
I've looked through the patch and I might be wrong, but it appears
that all the uses of the asynchronous request_firmware_nowait() are
followed immediately by wait_for_completion() calls which essentially
would be the same as the previous code with an added layer of
mechanism. Am I missing s
On 06/23/14 17:29, Luis R. Rodriguez wrote:
On Mon, Jun 23, 2014 at 12:06:48PM -0700, Casey Leedom wrote:
I've looked through the patch and I might be wrong, but it appears that
all the uses of the asynchronous request_firmware_nowait() are followed
immediately by wait_for_compl
On 06/24/14 08:55, Casey Leedom wrote:
On 06/23/14 17:29, Luis R. Rodriguez wrote:
On Mon, Jun 23, 2014 at 12:06:48PM -0700, Casey Leedom wrote:
Also, it might be useful if there was a way for the driver
module to "tell" the timeout mechanism that forward progress _is_ being
ret;
> when any
> } else {
> ...
> release_firmware(cf);
> ...
> }
>
> Cc: Philip Oswald
> Cc: Santosh Rastapur
> Cc: Jeffrey Cheung
> Cc: David Chang
> Cc: Casey Leedom
> Cc: Hariprasad Shenai
> Cc: Takashi I
On 06/24/14 18:50, Luis R. Rodriguez wrote:
On Tue, Jun 24, 2014 at 03:54:44PM -0700, Casey Leedom wrote:
[[ Hopefully this makes it through to the kernel.org lists -- I’m using the
Mac OS/X Mailer and it’s not clear how to force it not to use HTML format.
-- Casey ]]
So does
driver to notify the kernel timeout mechanism that
forward progress is being made ...
Casey
On 06/25/14 10:31, Luis R. Rodriguez wrote:
On Wed, Jun 25, 2014 at 10:12:20AM -0700, Casey Leedom wrote:
On 06/24/14 18:50, Luis R. Rodriguez wrote:
On Tue, Jun 24, 2014 at 03:54:44PM -0700, Casey Leedom
On 08/13/2014 04:33 PM, Anish Bhatt wrote:
Adding Casey who's actually incharge of this code and missing from the CC list
Thanks Anish!
As I mentioned to Anish, there are fundamentally two problems here in
the time being consumed by the cxgb4 PCI probe() function:
1. When various firm
ther changes.
Casey
From: Joe Perches [j...@perches.com]
Sent: Friday, February 13, 2015 6:05 PM
To: Hariprasad S; Casey Leedom; James E.J. Bottomley
Cc: net...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-scsi
Subject: chelsio: Use a more common con
7;s a company holiday. Color me a moron today.)
Casey
From: Joe Perches [j...@perches.com]
Sent: Monday, February 16, 2015 10:21 AM
To: Casey Leedom
Cc: Hariprasad S; James E.J. Bottomley; net...@vger.kernel.org;
linux-kernel@vger.kernel.org; linux-scsi; Dav
se improvements!
And given that it's pretty empty at work here on this holiday and how
beautiful it is outside, I think it's time to head home to enjoy lunch outside!
Casey
From: Joe Perches [j...@perches.com]
Sent: Monday, February 16, 2015 11:
> On Jul 2, 2015, at 11:49 AM, Luis R. Rodriguez wrote:
>
> On Sat, Jun 27, 2015 at 08:00:48AM +1000, Benjamin Herrenschmidt wrote:
>> On Fri, 2015-06-26 at 16:24 +0000, Casey Leedom wrote:
>>> Thanks for looking into this Ben. As it stands now, it seems as
>&g
| From: Luc Van Oostenryck
| Sent: Tuesday, April 24, 2018 6:19:02 AM
|
| The method ndo_start_xmit() is defined as returning an 'netdev_tx_t',
| which is a typedef for an enum type, but the implementation in this
| driver returns an 'int'.
|
| Fix this by returning 'netdev_tx_t' in this driver
/ From: Benjamin Herrenschmidt [b...@kernel.crashing.org]
| Sent: Wednesday, June 24, 2015 4:38 PM
|
| It is to be noted that on powerpc at least, writel() and co will never
| combine due to the memory barriers in them. Only "normal" stores (or
\ __raw_writel) will.
/ From: Benjamin Herrenschmidt
| From: Arnd Bergmann [a...@arndb.de]
| Sent: Thursday, June 25, 2015 1:44 PM
|
| On Thursday 25 June 2015 15:01:56 Casey Leedom wrote:
| >
| > Is there a reference I can read on this so I can understand
| > when and where we can use the __raw_*() APIs? Can these
| > Raw Read/Writ
to
eliminate a wasteful attempt to use write combining on those
architectures where it didn't work.
Casey
From: Benjamin Herrenschmidt [b...@kernel.crashing.org]
Sent: Thursday, June 25, 2015 7:02 PM
To: Casey Leedom
Cc: Arnd Bergmann; Luis R. Rodr
Sorry again for the delay. This time at least partially caused by a
Chelsio-internal Customer Support request to simply disable Relaxed Ordering
entirely due to the performance issues with our 100Gb/s product and relatively
recent Intel Root Complexes. Our Customer Support people are tired o
| From: Ding Tianhong
| Sent: Wednesday, July 12, 2017 6:18 PM
|
| If no other more suggestion, I will send a new version and remove the
| enable_pcie_relaxed_ordering(), thanks. :)
Sounds good to me. (And sorry for forgetting to justify that last message.
I hate working with web-based emai
[[ Sorry for the Double Send: I forgot to switch to Plain Text. Have I
mentioned how much I hate modern Web-based email agents? :-) -- Casey ]]
Yeah, I think this works for now. We'll stumble over what to do when we
want to mix upstream TLPs without Relaxed Ordering Attributes directed at
Reviewed-by: Casey Leedom
By the way, it ~seems~ like the patch set confuses the idea of the PCIe
Capability Device Control[Relaxed Ordering Enable] with the device's ability to
handle incoming TLPs with the Relaxed Ordering Attribute set. These are
completely different things. The PCIe Capability Device Control[Rela
Okay, thanks for the note Alexander. I'll have to look more closely at
the patch on Monday and try it out on one of the targeted systems to verify
the semantics you describe.
However, that said, there is no way to tell a priori where a device will
send TLPs. To simply assume that all TLPs wi
Hey Alexander,
Okay, I understand your point regarding the "most likely scenario" being
TLPs directed upstream to the Root Complex. But I'd still like to make sure
that we have an agreed upon API/methodology for doing Peer-to-Peer with
Relaxed Ordering and no Relaxed Ordering to the Root Compl
Hey Ding, Bjorn, Alexander, et.al.,
Sorry for the insane delay in getting to this and thanks especially to
Ding for picking up the ball on this feature. I got side=-tracked into a
multi-week rewrite of our Firmware/Host Driver Port Capabilities code, then
to the recent Ethernet Plug-Fest at the
| From: Dmitry Torokhov
| Sent: Wednesday, December 20, 2017 9:13 PM
|
| The 2nd issue is that Casey is seeing cxgb4vf driver being loaded.
| This happens because vfio-pci driver binds to the device, which causes
| KOBJ_BIND to get emitted, which causes all modules that match the PCI
| device ID t
/ From: Casey Leedom
| Date: Friday, December 15, 2017 11:17 PST
|
| | From: Dmitry Torokhov
| | Sent: Friday, December 15, 2017 10:53 AM
| |
| | Hmm, can she collect output of 'udevadm monitor -p' at the time you
| | assign the adapter to the VM?
|
| Sure. I'll have Komali
By the way, Komali just reported another bug internally where
instantiating an SR-IOV Virtual Function causes cxgb4vf to be automatically
loaded, which is normal behavior. But then when she attempts to unload
cxgb4vf, it simply gets reloaded again. This is with:
[root@t5nic linux]# git sh
By the way, Komali went back and tried 4.14.7 and it does exhibit the
issue which she originally reported. As noted before, the origin of the new
behavior was tracked down to kernel.org:1455cf8 ... Also as noted, Dmitry's
patch does not solve the problem.
Casey
Thanks Dmitry! I've asked Komali to test it against the problem that she
reported internally. She or I will get back to you on that testing ASAP.
I see that we've now moved on to 4.15 and the problem first showed up in
4.14. Once the fix is verified, should we see if it can get pushed bac
| From: Dmitry Torokhov
| Sent: Thursday, December 14, 2017 12:32 PM
|
| As far as I can see Eric's patch is landed in 4.15-rc1 so I do not
| think we need this patch in .14.
Except that Komali's bisect showed that the bug occured with kernel.org:
1455cf8dbfd06aa7651dcfccbadb7a093944ca65 which
Ah, okay, I see. So it's been getting "broken" and "fixed" for the last six
months or so ... :-) I think it's still broken in the latest 4.14.6 but I'll
have to check with Komali on that. I'm not 100% sure it's important enough to
push back into 4.14.{x} if it is still broken there ...
Ca
Dmitry,
Komali has done some experiments with changing
/lib/udev/rules.d/80-drivers.rules along the
lines you suggested and that seems to be the trick (I'm waiting for
clarification from her).
What's the mechanism for getting that change committed to the various
repositories?
Also, your fi
Hi Dmitry,
Komali reports that she still sees the originally reported issue with your
latest patch. This issue started with kernel.org commit
1455cf8dbfd06aa7651dcfccbadb7a093944ca65 (Wed Jul 19 17:24:30 2017 -0700).
cxgb4vf is getting loaded in the Hypervisor when a cxgb4 Virtual Function
i
| From: Dmitry Torokhov
| Sent: Friday, December 15, 2017 10:53 AM
|
| Hmm, can she collect output of 'udevadm monitor -p' at the time you
| assign the adapter to the VM?
Sure. I'll have Komali report on that.
| Also, do you have any udev rules that is specific to cxgb? Or any other
| custom u
| From: Raj, Ashok
| Sent: Wednesday, August 9, 2017 11:00 AM
|
| On Wed, Aug 09, 2017 at 04:46:07PM +, Casey Leedom wrote:
| > | From: Raj, Ashok
| > | Sent: Wednesday, August 9, 2017 8:58 AM
| > | ...
| > | As Casey pointed out in an earlier thread, we choose the
| From: Robin Murphy
| Sent: Wednesday, September 20, 2017 3:12 AM
|
| On 20/09/17 09:01, Herbert Xu wrote:
| >
| > Harsh Jain wrote:
| >>
| >> While debugging DMA mapping error in chelsio crypto driver we
| >> observed that when scatter/gather list received by driver has
| >> some entry with pag
| From: Raj, Ashok
| Sent: Monday, September 25, 2017 8:54 AM
|
| Not sure how the page->offset would end up being greater than page-size?
|
| If you have additional traces, please send them by.
|
| Is this a new driver? wondering how we didn't run into this?
According to Herbert Xu and one of
| From: Dan Williams
| Sent: Monday, September 25, 2017 12:31 PM
| ...
| IIUC it looks like this has been broken ever since commit e1605495c716
| "intel-iommu: Introduce domain_sg_mapping() to speed up
| intel_map_sg()". I.e. it looks like the calculation for pte_val should
| be:
|
| pteval =
| From: David Woodhouse
| Sent: Monday, September 25, 2017 11:45 AM
|
| On Wed, 2017-09-20 at 16:01 +0800, Herbert Xu wrote:
| > Harsh Jain wrote:
| > >
| > > While debugging DMA mapping error in chelsio crypto driver we
| > observed that when scatter/gather list received by driver has some
| > e
| From: Raj, Ashok
| Sent: Monday, September 25, 2017 12:03 PM
|
| On Mon, Sep 25, 2017 at 01:11:04PM -0700, Dan Williams wrote:
| > On Mon, Sep 25, 2017 at 1:05 PM, Casey Leedom wrote:
| > > | From: Dan Williams
| > > | Sent: Monday, September 25, 2017 12:31 PM
| > >
| From: Robin Murphy
| Sent: Tuesday, September 26, 2017 7:22 AM
|
| On 26/09/17 13:21, Harsh Jain wrote:
| > Find attached new set of log. After repeated tries it panics.
|
| Thanks, that makes things a bit clearer - looks like fixing the physical
| address/pteval calculation to not be off by a p
So just to be 100% sure I understand the patch you're proposing, you got
the first use of VTD_PAGE_SHIFT wrong; it should have been VTD_PAGE_MASK? I.e.
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 6784a05..d43b566 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/dr
| From: Harsh Jain
| Sent: Tuesday, October 3, 2017 5:22 AM
|
| Hi Robin/Ashok,
|
| Find attached trace of DMA write error. I had a look on trace but didn't
| find anything suspicious.
|
| Let me know if you need more trace.
As a reminder, Harsh and Atul will be waking up in a few hours, so if th
| From: Dan Williams
| Sent: Tuesday, September 26, 2017 9:10 AM
|
| On Tue, Sep 26, 2017 at 9:06 AM, Casey Leedom wrote:
| > | From: Robin Murphy
| > | Sent: Tuesday, September 26, 2017 7:22 AM
| > |...
| > ...
| > Regardless, it seems that you agree that there's an
| From: Robin Murphy
| Sent: Wednesday, September 27, 2017 10:18 AM
|
| From my experience, in general terms each scatterlist segment
| represents some contiguous quantity of pages, of which sg->page is the
| first, while sg->length and sg->offset describe the specific bounds of
| that segment's
Hey Raj,
Let us know if you need help in gathering more debugging information. For
the time being we've decided to ERRATA the use of the Intel I/O MMU with
IPsec till we Root Cause the issue. But this is still at the top of Harsh's
bug list.
With Robin's comments, I'm almost sure that the:
| From: Raj, Ashok
| Sent: Wednesday, September 27, 2017 12:07 PM
|
| looking at the debug output i got from Harsh it still looks like a bug in
| the code.
|
| [ 538.284589] __domain_mapping nr_pages 0x1
| [ 538.284600] __domain_mapping sg_res 0x1 sg->dma_address 0xf291000e dma len
| 0x38 pteval
Thanks Robin. Harsh can certainly test your latest patch as soon as he's
back in the office tomorrow morning India time. If your patch works and is
accepted, it sounds like the commit would be important enough to consider
backporting into various Long-Term Support releases and the affected
dist
| From: Harsh Jain
| Sent: Friday, September 29, 2017 1:14:45 AM
|
| Robin,
|
| I tried running patch on our test setup.
|
| With "intel_iommu=on" : I can see single occurrence of DMAR Write failure
| on perf traffic with 10 thread.
|
| [ 749.616480] perf: interrupt took too long (3203 >
| From: Raj, Ashok
| Sent: Thursday, August 3, 2017 1:31 AM
|
| I don't understand this completely.. So your driver would know not to send
| RO TLP's to root complex. But you want to send RO to the NVMe device? This
| is the peer-2-peer case correct?
Yes, this is the "heavy hammer" issue which yo
| From: Raj, Ashok
| Sent: Friday, August 4, 2017 1:21 PM
|
| On Fri, Aug 04, 2017 at 08:20:37PM +, Casey Leedom wrote:
| > ...
| > As I've noted a number of times, it would be great if the Intel Hardware
| > Engineers who attempted to implement the Relaxed Ordering se
| From: Ding Tianhong
| Sent: Thursday, August 3, 2017 6:44 AM
|
| diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
| index 6967c6b..1e1cdbe 100644
| --- a/drivers/pci/quirks.c
| +++ b/drivers/pci/quirks.c
| @@ -4016,6 +4016,44 @@ static void quirk_tw686x_class(struct pci_dev *pdev)
|
| From: Bjorn Helgaas
| Sent: Tuesday, August 8, 2017 4:22 PM
|
| This needs to include a link to the Intel spec
|
(https://software.intel.com/sites/default/files/managed/9e/bc/64-ia-32-architectures-optimization-manual.pdf,
| sec 3.9.1).
In the commit message or as a comment? Regardless, I
| From: Bjorn Helgaas
| Sent: Tuesday, August 8, 2017 7:22 PM
| ...
| and the caller should do something like this:
|
| if (pcie_relaxed_ordering_broken(pci_find_pcie_root_port(pdev)))
| adapter->flags |= ROOT_NO_RELAXED_ORDERING;
|
| That way it's obvious where the issue is, and it'
| From: Ding Tianhong
| Sent: Wednesday, August 9, 2017 5:17 AM
|
| On 2017/8/9 11:02, Bjorn Helgaas wrote:
| >
| > On Wed, Aug 09, 2017 at 01:40:01AM +, Casey Leedom wrote:
| > >
| >> | From: Bjorn Helgaas
| >> | Sent: Tuesday, August 8, 2017 4:22 PM
| >> | ...
| From: Raj, Ashok
| Sent: Wednesday, August 9, 2017 8:58 AM
| ...
| As Casey pointed out in an earlier thread, we choose the heavy hammer
| approach because there are some that can lead to data-corruption as opposed
| to perf degradation.
Careful. As far as I'm aware, there is no Data Corruptio
Attribute clear are allowed to bypass earlier TLPs with
| > Relaxed Ordering set, it would cause Data Corruption, so we need
| > to disable Relaxed Ordering Attribute when Upstream TLPs to the
| > Root Port.
| >
| > Signed-off-by: Casey Leedom
| > Signed-off-by: Ding Tianhong
|
Okay, here you go. As you can tell, it's almost a trivial copy of the
cxgb4 patch.
By the way, I realized that we have yet another hole which is likely not
to be fixable. If we're dealing with a problematic Root Complex, and we
instantiate Virtual Functions and attach them to a Virtual Mach
By the way Ding, two issues:
1. Did we ever get any acknowledgement from either Intel or AMD
on this patch? I know that we can't ensure that, but it sure would
be nice since the PCI Quirks that we're putting in affect their
products.
2. I just realized that there's still a small
| From: Alexander Duyck
| Sent: Wednesday, July 26, 2017 11:44 AM
|
| On Jul 26, 2017 11:26 AM, "Casey Leedom" wrote:
| |
| | I think that the patch will need to be extended to modify
| | drivers/pci.c/iov.c:sriov_enable() to explicitly turn off
| | Relaxed Ordering Ena
| From: Ding Tianhong
| Sent: Wednesday, July 26, 2017 6:01 PM
|
| On 2017/7/27 3:05, Casey Leedom wrote:
| >
| > Ding, send me a note if you'd like me to work that [cxgb4vf patch] up
| > for you.
|
| Ok, you could send the change log and I could put it in the v8 version
| together,
| From: Raj, Ashok
| Sent: Friday, November 17, 2017 7:48 AM
|
| Reported by: Harsh
| Reviewed by: Ashok Raj
| Tested by: Jacob Pan
Thanks everyone! I've updated our internal bug on this issue
and noted that we need to track down the remaining problems
which may be in our own code.
Casey
70 matches
Mail list logo
