Re: 3.14-mw regression: rtl8169 WARNING: DMA-API: exceeded 7 overlapping mappings of pfn 55ebe
On Tue, Feb 25, 2014 at 9:45 AM, Josh Boyer wrote:
> On Thu, Feb 13, 2014 at 4:49 PM, Sander Eikelenboom
> wrote:
>>
>> Thursday, February 13, 2014, 9:14:47 PM, you wrote:
>>
>>> On Tue, 2014-02-11 at 20:17 -0800, Eric Dumazet wrote:
On Tue, 2014-02-11 at 18:07 -0800, Dan Williams wrote:
> The overlap granularity is too large. Multiple dma_map_single
> mappings are allowed to a given page as long as they don't collide on
> the same cache line.
>
I am not sure why you try number of mappings of a page.
Try launching 100 concurrent netperf -t TCP_SENFILE
Same page might be mapped more than 100 times, more than 1 times in
some cases.
>>
>>> Thanks for that test case.
>>
>>> I updated the fix patch with the following.
>>
>>> diff --git a/lib/dma-debug.c b/lib/dma-debug.c
>>> index 42b12740940b..611010df1e9c 100644
>>> --- a/lib/dma-debug.c
>>> +++ b/lib/dma-debug.c
>>> @@ -513,6 +513,13 @@ static int active_cln_insert(struct dma_debug_entry
>>> *entry)
>>> unsigned long flags;
>>> int rc;
>>>
>>> + /* If the device is not writing memory then we don't have any
>>> +* concerns about the cpu consuming stale data. This mitigates
>>> +* legitimate usages of overlapping mappings.
>>> +*/
>> + if (entry->>direction == DMA_TO_DEVICE)
>>> + return 0;
>>> +
>>> spin_lock_irqsave(_lock, flags);
>>> rc = radix_tree_insert(_active_cacheline, to_cln(entry), entry);
>>> if (rc == -EEXIST)
>>> @@ -526,6 +533,10 @@ static void active_cln_remove(struct dma_debug_entry
>>> *entry)
>>> {
>>> unsigned long flags;
>>>
>>> + /* ...mirror the insert case */
>> + if (entry->>direction == DMA_TO_DEVICE)
>>> + return;
>>> +
>>> spin_lock_irqsave(_lock, flags);
>>> /* since we are counting overlaps the final put of the
>>> * cacheline will occur when the overlap count is 0.
>>
>>
>>> Sander, barring a negative test result from you I'll send the attached
>>> patch to Andrew.
>>
>> Hi Dan,
>>
>> That seems to effectively suppress the warning, thanks and:
>>
>> Tested-by; Sander Eikelenboom
>
> Is there a reason this isn't in Linus' tree yet?
>
It's in -mm and now -next, I expect it will go upstream with akpm's next sync.
--
Dan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 3.14-mw regression: rtl8169 WARNING: DMA-API: exceeded 7 overlapping mappings of pfn 55ebe
On Thu, Feb 13, 2014 at 4:49 PM, Sander Eikelenboom
wrote:
>
> Thursday, February 13, 2014, 9:14:47 PM, you wrote:
>
>> On Tue, 2014-02-11 at 20:17 -0800, Eric Dumazet wrote:
>>> On Tue, 2014-02-11 at 18:07 -0800, Dan Williams wrote:
>>>
>>> > The overlap granularity is too large. Multiple dma_map_single
>>> > mappings are allowed to a given page as long as they don't collide on
>>> > the same cache line.
>>> >
>>>
>>> I am not sure why you try number of mappings of a page.
>>>
>>> Try launching 100 concurrent netperf -t TCP_SENFILE
>>>
>>> Same page might be mapped more than 100 times, more than 1 times in
>>> some cases.
>
>> Thanks for that test case.
>
>> I updated the fix patch with the following.
>
>> diff --git a/lib/dma-debug.c b/lib/dma-debug.c
>> index 42b12740940b..611010df1e9c 100644
>> --- a/lib/dma-debug.c
>> +++ b/lib/dma-debug.c
>> @@ -513,6 +513,13 @@ static int active_cln_insert(struct dma_debug_entry
>> *entry)
>> unsigned long flags;
>> int rc;
>>
>> + /* If the device is not writing memory then we don't have any
>> +* concerns about the cpu consuming stale data. This mitigates
>> +* legitimate usages of overlapping mappings.
>> +*/
> + if (entry->>direction == DMA_TO_DEVICE)
>> + return 0;
>> +
>> spin_lock_irqsave(_lock, flags);
>> rc = radix_tree_insert(_active_cacheline, to_cln(entry), entry);
>> if (rc == -EEXIST)
>> @@ -526,6 +533,10 @@ static void active_cln_remove(struct dma_debug_entry
>> *entry)
>> {
>> unsigned long flags;
>>
>> + /* ...mirror the insert case */
> + if (entry->>direction == DMA_TO_DEVICE)
>> + return;
>> +
>> spin_lock_irqsave(_lock, flags);
>> /* since we are counting overlaps the final put of the
>> * cacheline will occur when the overlap count is 0.
>
>
>> Sander, barring a negative test result from you I'll send the attached
>> patch to Andrew.
>
> Hi Dan,
>
> That seems to effectively suppress the warning, thanks and:
>
> Tested-by; Sander Eikelenboom
Is there a reason this isn't in Linus' tree yet?
josh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 3.14-mw regression: rtl8169 WARNING: DMA-API: exceeded 7 overlapping mappings of pfn 55ebe
On Thu, Feb 13, 2014 at 4:49 PM, Sander Eikelenboom
li...@eikelenboom.it wrote:
Thursday, February 13, 2014, 9:14:47 PM, you wrote:
On Tue, 2014-02-11 at 20:17 -0800, Eric Dumazet wrote:
On Tue, 2014-02-11 at 18:07 -0800, Dan Williams wrote:
The overlap granularity is too large. Multiple dma_map_single
mappings are allowed to a given page as long as they don't collide on
the same cache line.
I am not sure why you try number of mappings of a page.
Try launching 100 concurrent netperf -t TCP_SENFILE
Same page might be mapped more than 100 times, more than 1 times in
some cases.
Thanks for that test case.
I updated the fix patch with the following.
diff --git a/lib/dma-debug.c b/lib/dma-debug.c
index 42b12740940b..611010df1e9c 100644
--- a/lib/dma-debug.c
+++ b/lib/dma-debug.c
@@ -513,6 +513,13 @@ static int active_cln_insert(struct dma_debug_entry
*entry)
unsigned long flags;
int rc;
+ /* If the device is not writing memory then we don't have any
+* concerns about the cpu consuming stale data. This mitigates
+* legitimate usages of overlapping mappings.
+*/
+ if (entry-direction == DMA_TO_DEVICE)
+ return 0;
+
spin_lock_irqsave(radix_lock, flags);
rc = radix_tree_insert(dma_active_cacheline, to_cln(entry), entry);
if (rc == -EEXIST)
@@ -526,6 +533,10 @@ static void active_cln_remove(struct dma_debug_entry
*entry)
{
unsigned long flags;
+ /* ...mirror the insert case */
+ if (entry-direction == DMA_TO_DEVICE)
+ return;
+
spin_lock_irqsave(radix_lock, flags);
/* since we are counting overlaps the final put of the
* cacheline will occur when the overlap count is 0.
Sander, barring a negative test result from you I'll send the attached
patch to Andrew.
Hi Dan,
That seems to effectively suppress the warning, thanks and:
Tested-by; Sander Eikelenboom li...@eikelenboom.it
Is there a reason this isn't in Linus' tree yet?
josh
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 3.14-mw regression: rtl8169 WARNING: DMA-API: exceeded 7 overlapping mappings of pfn 55ebe
On Tue, Feb 25, 2014 at 9:45 AM, Josh Boyer jwbo...@fedoraproject.org wrote:
On Thu, Feb 13, 2014 at 4:49 PM, Sander Eikelenboom
li...@eikelenboom.it wrote:
Thursday, February 13, 2014, 9:14:47 PM, you wrote:
On Tue, 2014-02-11 at 20:17 -0800, Eric Dumazet wrote:
On Tue, 2014-02-11 at 18:07 -0800, Dan Williams wrote:
The overlap granularity is too large. Multiple dma_map_single
mappings are allowed to a given page as long as they don't collide on
the same cache line.
I am not sure why you try number of mappings of a page.
Try launching 100 concurrent netperf -t TCP_SENFILE
Same page might be mapped more than 100 times, more than 1 times in
some cases.
Thanks for that test case.
I updated the fix patch with the following.
diff --git a/lib/dma-debug.c b/lib/dma-debug.c
index 42b12740940b..611010df1e9c 100644
--- a/lib/dma-debug.c
+++ b/lib/dma-debug.c
@@ -513,6 +513,13 @@ static int active_cln_insert(struct dma_debug_entry
*entry)
unsigned long flags;
int rc;
+ /* If the device is not writing memory then we don't have any
+* concerns about the cpu consuming stale data. This mitigates
+* legitimate usages of overlapping mappings.
+*/
+ if (entry-direction == DMA_TO_DEVICE)
+ return 0;
+
spin_lock_irqsave(radix_lock, flags);
rc = radix_tree_insert(dma_active_cacheline, to_cln(entry), entry);
if (rc == -EEXIST)
@@ -526,6 +533,10 @@ static void active_cln_remove(struct dma_debug_entry
*entry)
{
unsigned long flags;
+ /* ...mirror the insert case */
+ if (entry-direction == DMA_TO_DEVICE)
+ return;
+
spin_lock_irqsave(radix_lock, flags);
/* since we are counting overlaps the final put of the
* cacheline will occur when the overlap count is 0.
Sander, barring a negative test result from you I'll send the attached
patch to Andrew.
Hi Dan,
That seems to effectively suppress the warning, thanks and:
Tested-by; Sander Eikelenboom li...@eikelenboom.it
Is there a reason this isn't in Linus' tree yet?
It's in -mm and now -next, I expect it will go upstream with akpm's next sync.
--
Dan
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 3.14-mw regression: rtl8169 WARNING: DMA-API: exceeded 7 overlapping mappings of pfn 55ebe
Thursday, February 13, 2014, 9:14:47 PM, you wrote:
> On Tue, 2014-02-11 at 20:17 -0800, Eric Dumazet wrote:
>> On Tue, 2014-02-11 at 18:07 -0800, Dan Williams wrote:
>>
>> > The overlap granularity is too large. Multiple dma_map_single
>> > mappings are allowed to a given page as long as they don't collide on
>> > the same cache line.
>> >
>>
>> I am not sure why you try number of mappings of a page.
>>
>> Try launching 100 concurrent netperf -t TCP_SENFILE
>>
>> Same page might be mapped more than 100 times, more than 1 times in
>> some cases.
> Thanks for that test case.
> I updated the fix patch with the following.
> diff --git a/lib/dma-debug.c b/lib/dma-debug.c
> index 42b12740940b..611010df1e9c 100644
> --- a/lib/dma-debug.c
> +++ b/lib/dma-debug.c
> @@ -513,6 +513,13 @@ static int active_cln_insert(struct dma_debug_entry
> *entry)
> unsigned long flags;
> int rc;
>
> + /* If the device is not writing memory then we don't have any
> +* concerns about the cpu consuming stale data. This mitigates
> +* legitimate usages of overlapping mappings.
> +*/
+ if (entry->>direction == DMA_TO_DEVICE)
> + return 0;
> +
> spin_lock_irqsave(_lock, flags);
> rc = radix_tree_insert(_active_cacheline, to_cln(entry), entry);
> if (rc == -EEXIST)
> @@ -526,6 +533,10 @@ static void active_cln_remove(struct dma_debug_entry
> *entry)
> {
> unsigned long flags;
>
> + /* ...mirror the insert case */
+ if (entry->>direction == DMA_TO_DEVICE)
> + return;
> +
> spin_lock_irqsave(_lock, flags);
> /* since we are counting overlaps the final put of the
> * cacheline will occur when the overlap count is 0.
> Sander, barring a negative test result from you I'll send the attached
> patch to Andrew.
Hi Dan,
That seems to effectively suppress the warning, thanks and:
Tested-by; Sander Eikelenboom
--
Sander
> --
> Dan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 3.14-mw regression: rtl8169 WARNING: DMA-API: exceeded 7 overlapping mappings of pfn 55ebe
On Tue, Feb 11, 2014 at 06:07:10PM -0800, Dan Williams wrote: > The overlap granularity is too large. Multiple dma_map_single > mappings are allowed to a given page as long as they don't collide on > the same cache line. > > > Please try the attached patch to see if it fixes this issue. Works ok for > me. FWIW, since applying this, I haven't seen the 8169 warnings. thanks, Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.14-mw regression: rtl8169 WARNING: DMA-API: exceeded 7 overlapping mappings of pfn 55ebe
On Tue, 2014-02-11 at 20:17 -0800, Eric Dumazet wrote:
> On Tue, 2014-02-11 at 18:07 -0800, Dan Williams wrote:
>
> > The overlap granularity is too large. Multiple dma_map_single
> > mappings are allowed to a given page as long as they don't collide on
> > the same cache line.
> >
>
> I am not sure why you try number of mappings of a page.
>
> Try launching 100 concurrent netperf -t TCP_SENFILE
>
> Same page might be mapped more than 100 times, more than 1 times in
> some cases.
Thanks for that test case.
I updated the fix patch with the following.
diff --git a/lib/dma-debug.c b/lib/dma-debug.c
index 42b12740940b..611010df1e9c 100644
--- a/lib/dma-debug.c
+++ b/lib/dma-debug.c
@@ -513,6 +513,13 @@ static int active_cln_insert(struct dma_debug_entry *entry)
unsigned long flags;
int rc;
+ /* If the device is not writing memory then we don't have any
+* concerns about the cpu consuming stale data. This mitigates
+* legitimate usages of overlapping mappings.
+*/
+ if (entry->direction == DMA_TO_DEVICE)
+ return 0;
+
spin_lock_irqsave(_lock, flags);
rc = radix_tree_insert(_active_cacheline, to_cln(entry), entry);
if (rc == -EEXIST)
@@ -526,6 +533,10 @@ static void active_cln_remove(struct dma_debug_entry
*entry)
{
unsigned long flags;
+ /* ...mirror the insert case */
+ if (entry->direction == DMA_TO_DEVICE)
+ return;
+
spin_lock_irqsave(_lock, flags);
/* since we are counting overlaps the final put of the
* cacheline will occur when the overlap count is 0.
Sander, barring a negative test result from you I'll send the attached
patch to Andrew.
--
Dan
dma debug: account for cachelines and read-only mappings in overlap tracking
From: Dan Williams
While debug_dma_assert_idle() checks if a given *page* is actively
undergoing dma the valid granularity of a dma mapping is a *cacheline*.
Sander's testing shows that the warning message "DMA-API: exceeded 7
overlapping mappings of pfn..." is falsely triggering. The test is
simply mapping multiple cachelines in a given page.
Ultimately we want overlap tracking to be valid as it is a real api
violation, to that end we need to track active mappings by cachelines.
To this end, update the active dma tracking to use the
page-frame-relative cacheline of the mapping as the key, and update
debug_dma_assert_idle() to check for all possible mapped cachelines for
a given page. However, this is only a problem when the dma-mapping is
writable by the device. In fact it is fairly standard for read-only
mappings to have hundreds or thousands of mappings at once. Limiting
the overlap tracking to writable (!DMA_TO_DEVICE) mappings mitigates
false-positive reports of overlap violations.
Note, the radix gang lookup is sub-optimal. It would be best if it
stopped fetching entries once the search passed a page boundary.
Nevertheless, this implementation does not perturb the original net_dma
failing case. That is to say the extra overhead does not show up in
terms of making the failing case pass due to a timing change.
Reported-by: Sander Eikelenboom
Reported-by: Dave Jones
Cc: Konrad Rzeszutek Wilk
Cc: Francois Romieu
Cc: Eric Dumazet
Cc: Wei Liu
Signed-off-by: Dan Williams
---
lib/dma-debug.c | 123 +++
1 files changed, 78 insertions(+), 45 deletions(-)
diff --git a/lib/dma-debug.c b/lib/dma-debug.c
index 2defd1308b04..611010df1e9c 100644
--- a/lib/dma-debug.c
+++ b/lib/dma-debug.c
@@ -424,111 +424,132 @@ void debug_dma_dump_mappings(struct device *dev)
EXPORT_SYMBOL(debug_dma_dump_mappings);
/*
- * For each page mapped (initial page in the case of
- * dma_alloc_coherent/dma_map_{single|page}, or each page in a
- * scatterlist) insert into this tree using the pfn as the key. At
+ * For each mapping (initial cacheline in the case of
+ * dma_alloc_coherent/dma_map_page, initial cacheline in each page of a
+ * scatterlist, or the cacheline specified in dma_map_single) insert
+ * into this tree using the cacheline as the key. At
* dma_unmap_{single|sg|page} or dma_free_coherent delete the entry. If
- * the pfn already exists at insertion time add a tag as a reference
+ * the entry already exists at insertion time add a tag as a reference
* count for the overlapping mappings. For now, the overlap tracking
- * just ensures that 'unmaps' balance 'maps' before marking the pfn
- * idle, but we should also be flagging overlaps as an API violation.
+ * just ensures that 'unmaps' balance 'maps' before marking the
+ * cacheline idle, but we should also be flagging overlaps as an API
+ * violation.
*
* Memory usage is mostly constrained by the maximum number of available
* dma-debug entries in that we need a free dma_debug_entry before
- * inserting into the tree. In the case of dma_map_{single|page} and
- * dma_alloc_coherent there is only one
Re: 3.14-mw regression: rtl8169 WARNING: DMA-API: exceeded 7 overlapping mappings of pfn 55ebe
On Tue, 2014-02-11 at 20:17 -0800, Eric Dumazet wrote:
On Tue, 2014-02-11 at 18:07 -0800, Dan Williams wrote:
The overlap granularity is too large. Multiple dma_map_single
mappings are allowed to a given page as long as they don't collide on
the same cache line.
I am not sure why you try number of mappings of a page.
Try launching 100 concurrent netperf -t TCP_SENFILE
Same page might be mapped more than 100 times, more than 1 times in
some cases.
Thanks for that test case.
I updated the fix patch with the following.
diff --git a/lib/dma-debug.c b/lib/dma-debug.c
index 42b12740940b..611010df1e9c 100644
--- a/lib/dma-debug.c
+++ b/lib/dma-debug.c
@@ -513,6 +513,13 @@ static int active_cln_insert(struct dma_debug_entry *entry)
unsigned long flags;
int rc;
+ /* If the device is not writing memory then we don't have any
+* concerns about the cpu consuming stale data. This mitigates
+* legitimate usages of overlapping mappings.
+*/
+ if (entry-direction == DMA_TO_DEVICE)
+ return 0;
+
spin_lock_irqsave(radix_lock, flags);
rc = radix_tree_insert(dma_active_cacheline, to_cln(entry), entry);
if (rc == -EEXIST)
@@ -526,6 +533,10 @@ static void active_cln_remove(struct dma_debug_entry
*entry)
{
unsigned long flags;
+ /* ...mirror the insert case */
+ if (entry-direction == DMA_TO_DEVICE)
+ return;
+
spin_lock_irqsave(radix_lock, flags);
/* since we are counting overlaps the final put of the
* cacheline will occur when the overlap count is 0.
Sander, barring a negative test result from you I'll send the attached
patch to Andrew.
--
Dan
dma debug: account for cachelines and read-only mappings in overlap tracking
From: Dan Williams dan.j.willi...@intel.com
While debug_dma_assert_idle() checks if a given *page* is actively
undergoing dma the valid granularity of a dma mapping is a *cacheline*.
Sander's testing shows that the warning message DMA-API: exceeded 7
overlapping mappings of pfn... is falsely triggering. The test is
simply mapping multiple cachelines in a given page.
Ultimately we want overlap tracking to be valid as it is a real api
violation, to that end we need to track active mappings by cachelines.
To this end, update the active dma tracking to use the
page-frame-relative cacheline of the mapping as the key, and update
debug_dma_assert_idle() to check for all possible mapped cachelines for
a given page. However, this is only a problem when the dma-mapping is
writable by the device. In fact it is fairly standard for read-only
mappings to have hundreds or thousands of mappings at once. Limiting
the overlap tracking to writable (!DMA_TO_DEVICE) mappings mitigates
false-positive reports of overlap violations.
Note, the radix gang lookup is sub-optimal. It would be best if it
stopped fetching entries once the search passed a page boundary.
Nevertheless, this implementation does not perturb the original net_dma
failing case. That is to say the extra overhead does not show up in
terms of making the failing case pass due to a timing change.
Reported-by: Sander Eikelenboom li...@eikelenboom.it
Reported-by: Dave Jones da...@redhat.com
Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Cc: Francois Romieu rom...@fr.zoreil.com
Cc: Eric Dumazet eric.duma...@gmail.com
Cc: Wei Liu wei.l...@citrix.com
Signed-off-by: Dan Williams dan.j.willi...@intel.com
---
lib/dma-debug.c | 123 +++
1 files changed, 78 insertions(+), 45 deletions(-)
diff --git a/lib/dma-debug.c b/lib/dma-debug.c
index 2defd1308b04..611010df1e9c 100644
--- a/lib/dma-debug.c
+++ b/lib/dma-debug.c
@@ -424,111 +424,132 @@ void debug_dma_dump_mappings(struct device *dev)
EXPORT_SYMBOL(debug_dma_dump_mappings);
/*
- * For each page mapped (initial page in the case of
- * dma_alloc_coherent/dma_map_{single|page}, or each page in a
- * scatterlist) insert into this tree using the pfn as the key. At
+ * For each mapping (initial cacheline in the case of
+ * dma_alloc_coherent/dma_map_page, initial cacheline in each page of a
+ * scatterlist, or the cacheline specified in dma_map_single) insert
+ * into this tree using the cacheline as the key. At
* dma_unmap_{single|sg|page} or dma_free_coherent delete the entry. If
- * the pfn already exists at insertion time add a tag as a reference
+ * the entry already exists at insertion time add a tag as a reference
* count for the overlapping mappings. For now, the overlap tracking
- * just ensures that 'unmaps' balance 'maps' before marking the pfn
- * idle, but we should also be flagging overlaps as an API violation.
+ * just ensures that 'unmaps' balance 'maps' before marking the
+ * cacheline idle, but we should also be flagging overlaps as an API
+ * violation.
*
* Memory usage is mostly constrained by the maximum number of available
* dma-debug entries
Re: 3.14-mw regression: rtl8169 WARNING: DMA-API: exceeded 7 overlapping mappings of pfn 55ebe
On Tue, Feb 11, 2014 at 06:07:10PM -0800, Dan Williams wrote: The overlap granularity is too large. Multiple dma_map_single mappings are allowed to a given page as long as they don't collide on the same cache line. Please try the attached patch to see if it fixes this issue. Works ok for me. FWIW, since applying this, I haven't seen the 8169 warnings. thanks, Dave -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.14-mw regression: rtl8169 WARNING: DMA-API: exceeded 7 overlapping mappings of pfn 55ebe
Thursday, February 13, 2014, 9:14:47 PM, you wrote:
On Tue, 2014-02-11 at 20:17 -0800, Eric Dumazet wrote:
On Tue, 2014-02-11 at 18:07 -0800, Dan Williams wrote:
The overlap granularity is too large. Multiple dma_map_single
mappings are allowed to a given page as long as they don't collide on
the same cache line.
I am not sure why you try number of mappings of a page.
Try launching 100 concurrent netperf -t TCP_SENFILE
Same page might be mapped more than 100 times, more than 1 times in
some cases.
Thanks for that test case.
I updated the fix patch with the following.
diff --git a/lib/dma-debug.c b/lib/dma-debug.c
index 42b12740940b..611010df1e9c 100644
--- a/lib/dma-debug.c
+++ b/lib/dma-debug.c
@@ -513,6 +513,13 @@ static int active_cln_insert(struct dma_debug_entry
*entry)
unsigned long flags;
int rc;
+ /* If the device is not writing memory then we don't have any
+* concerns about the cpu consuming stale data. This mitigates
+* legitimate usages of overlapping mappings.
+*/
+ if (entry-direction == DMA_TO_DEVICE)
+ return 0;
+
spin_lock_irqsave(radix_lock, flags);
rc = radix_tree_insert(dma_active_cacheline, to_cln(entry), entry);
if (rc == -EEXIST)
@@ -526,6 +533,10 @@ static void active_cln_remove(struct dma_debug_entry
*entry)
{
unsigned long flags;
+ /* ...mirror the insert case */
+ if (entry-direction == DMA_TO_DEVICE)
+ return;
+
spin_lock_irqsave(radix_lock, flags);
/* since we are counting overlaps the final put of the
* cacheline will occur when the overlap count is 0.
Sander, barring a negative test result from you I'll send the attached
patch to Andrew.
Hi Dan,
That seems to effectively suppress the warning, thanks and:
Tested-by; Sander Eikelenboom li...@eikelenboom.it
--
Sander
--
Dan
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 3.14-mw regression: rtl8169 WARNING: DMA-API: exceeded 7 overlapping mappings of pfn 55ebe
On Tue, 2014-02-11 at 13:28 -0800, Eric Dumazet wrote: [...] > Incoming frames might be taken out of order-3 pages. > > With regular Ethernet frames, this is 21 frames per order-3 pages. > > ACTIVE_PFN_MAX_OVERLAP seems too small. > > Alternative would be to user order-0 only pages if CONFIG_DMA_API_DEBUG > is set. Not sure if it works if PAGE_SIZE=66536 Indeed, you can get a lot of packet buffers into a 64K page... > diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h > index f589c9af8cbf..1b9995adfd29 100644 > --- a/include/linux/skbuff.h > +++ b/include/linux/skbuff.h > @@ -1924,7 +1924,11 @@ static inline void __skb_queue_purge(struct > sk_buff_head *list) > kfree_skb(skb); > } > > +#if defined(CONFIG_DMA_API_DEBUG) > +#define NETDEV_FRAG_PAGE_MAX_ORDER 0 > +#else > #define NETDEV_FRAG_PAGE_MAX_ORDER get_order(32768) > +#endif > #define NETDEV_FRAG_PAGE_MAX_SIZE (PAGE_SIZE << NETDEV_FRAG_PAGE_MAX_ORDER) > #define NETDEV_PAGECNT_MAX_BIAS NETDEV_FRAG_PAGE_MAX_SIZE > That may be useful for debugging this particular problem, but please don't make debugging options change behaviour like this. Ben. -- Ben Hutchings If more than one person is responsible for a bug, no one is at fault. signature.asc Description: This is a digitally signed message part
Re: 3.14-mw regression: rtl8169 WARNING: DMA-API: exceeded 7 overlapping mappings of pfn 55ebe
On Tue, Feb 11, 2014 at 8:17 PM, Eric Dumazet wrote: > On Tue, 2014-02-11 at 18:07 -0800, Dan Williams wrote: > >> The overlap granularity is too large. Multiple dma_map_single >> mappings are allowed to a given page as long as they don't collide on >> the same cache line. >> > > I am not sure why you try number of mappings of a page. For this debug facility I am tracking whether dma has completed by making sure there are no active dma_map entries in the address range of a page being cow'd. > Try launching 100 concurrent netperf -t TCP_SENFILE > > Same page might be mapped more than 100 times, more than 1 times in > some cases. > Aren't these mapping serialized by the device to some extent? Although multi-queue / multi-device would even defeat that... Hmm, then I think at a minimum the activity tracking needs to be constrained to overlapping DMA_FROM_DEVICE or DMA_BIDIRECTIONAL mappings. However, I am still operating on the assumption that some architectures (especially non-io-coherent or dmabounce architectures) expect a dma mapping to reflect exclusive ownership of the buffer. >From the conversation I had with Russell, back in the day [1]: "When we get to the second async_xor(), as we haven't started to run any of these operations, the source and destination buffers are still mapped. However, we ignore that and call dma_map_page() on them again - this is illegal because the CPU does not own these buffers." It might be the case that we can't have a general overlap detection facility as it will flag stable use cases that nonetheless violate the exclusivity expectation. -- Dan [1]: http://marc.info/?l=linux-arm-kernel=129389649101566=2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.14-mw regression: rtl8169 WARNING: DMA-API: exceeded 7 overlapping mappings of pfn 55ebe
On Tue, Feb 11, 2014 at 8:17 PM, Eric Dumazet eric.duma...@gmail.com wrote: On Tue, 2014-02-11 at 18:07 -0800, Dan Williams wrote: The overlap granularity is too large. Multiple dma_map_single mappings are allowed to a given page as long as they don't collide on the same cache line. I am not sure why you try number of mappings of a page. For this debug facility I am tracking whether dma has completed by making sure there are no active dma_map entries in the address range of a page being cow'd. Try launching 100 concurrent netperf -t TCP_SENFILE Same page might be mapped more than 100 times, more than 1 times in some cases. Aren't these mapping serialized by the device to some extent? Although multi-queue / multi-device would even defeat that... Hmm, then I think at a minimum the activity tracking needs to be constrained to overlapping DMA_FROM_DEVICE or DMA_BIDIRECTIONAL mappings. However, I am still operating on the assumption that some architectures (especially non-io-coherent or dmabounce architectures) expect a dma mapping to reflect exclusive ownership of the buffer. From the conversation I had with Russell, back in the day [1]: When we get to the second async_xor(), as we haven't started to run any of these operations, the source and destination buffers are still mapped. However, we ignore that and call dma_map_page() on them again - this is illegal because the CPU does not own these buffers. It might be the case that we can't have a general overlap detection facility as it will flag stable use cases that nonetheless violate the exclusivity expectation. -- Dan [1]: http://marc.info/?l=linux-arm-kernelm=129389649101566w=2 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.14-mw regression: rtl8169 WARNING: DMA-API: exceeded 7 overlapping mappings of pfn 55ebe
On Tue, 2014-02-11 at 13:28 -0800, Eric Dumazet wrote: [...] Incoming frames might be taken out of order-3 pages. With regular Ethernet frames, this is 21 frames per order-3 pages. ACTIVE_PFN_MAX_OVERLAP seems too small. Alternative would be to user order-0 only pages if CONFIG_DMA_API_DEBUG is set. Not sure if it works if PAGE_SIZE=66536 Indeed, you can get a lot of packet buffers into a 64K page... diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h index f589c9af8cbf..1b9995adfd29 100644 --- a/include/linux/skbuff.h +++ b/include/linux/skbuff.h @@ -1924,7 +1924,11 @@ static inline void __skb_queue_purge(struct sk_buff_head *list) kfree_skb(skb); } +#if defined(CONFIG_DMA_API_DEBUG) +#define NETDEV_FRAG_PAGE_MAX_ORDER 0 +#else #define NETDEV_FRAG_PAGE_MAX_ORDER get_order(32768) +#endif #define NETDEV_FRAG_PAGE_MAX_SIZE (PAGE_SIZE NETDEV_FRAG_PAGE_MAX_ORDER) #define NETDEV_PAGECNT_MAX_BIAS NETDEV_FRAG_PAGE_MAX_SIZE That may be useful for debugging this particular problem, but please don't make debugging options change behaviour like this. Ben. -- Ben Hutchings If more than one person is responsible for a bug, no one is at fault. signature.asc Description: This is a digitally signed message part
Re: 3.14-mw regression: rtl8169 WARNING: DMA-API: exceeded 7 overlapping mappings of pfn 55ebe
On Tue, 2014-02-11 at 18:07 -0800, Dan Williams wrote: > The overlap granularity is too large. Multiple dma_map_single > mappings are allowed to a given page as long as they don't collide on > the same cache line. > I am not sure why you try number of mappings of a page. Try launching 100 concurrent netperf -t TCP_SENFILE Same page might be mapped more than 100 times, more than 1 times in some cases. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.14-mw regression: rtl8169 WARNING: DMA-API: exceeded 7 overlapping mappings of pfn 55ebe
On Tue, Feb 11, 2014 at 11:56 AM, Sander Eikelenboom
wrote:
> Hi Dan,
>
> FYI just tested and put Xen out of the equation (booting baremetal) and it
> still persists.
>
> I tried something else .. don't know if it gives you anymore insights, but
> it's worth the try:
This is great! See below:
>
> diff --git a/lib/dma-debug.c b/lib/dma-debug.c
> index 2defd13..0fe5b75 100644
> --- a/lib/dma-debug.c
> +++ b/lib/dma-debug.c
> @@ -474,11 +474,11 @@ static int active_pfn_set_overlap(unsigned long pfn,
> int overlap)
> return overlap;
> }
>
> -static void active_pfn_inc_overlap(unsigned long pfn)
> +static void active_pfn_inc_overlap(struct dma_debug_entry *ent)
> {
> - int overlap = active_pfn_read_overlap(pfn);
> + int overlap = active_pfn_read_overlap(ent->pfn);
>
> - overlap = active_pfn_set_overlap(pfn, ++overlap);
> + overlap = active_pfn_set_overlap(ent->pfn, ++overlap);
>
> /* If we overflowed the overlap counter then we're potentially
> * leaking dma-mappings. Otherwise, if maps and unmaps are
> @@ -486,15 +486,43 @@ static void active_pfn_inc_overlap(unsigned long pfn)
> * debug_dma_assert_idle() as the pfn may be marked idle
> * prematurely.
> */
> +
> WARN_ONCE(overlap > ACTIVE_PFN_MAX_OVERLAP,
> "DMA-API: exceeded %d overlapping mappings of pfn %lx\n",
> - ACTIVE_PFN_MAX_OVERLAP, pfn);
> + ACTIVE_PFN_MAX_OVERLAP, ent->pfn);
> +
> + if(overlap > ACTIVE_PFN_MAX_OVERLAP){
> +
> + dev_info(ent->dev, "DMA-API: exceeded %d overlapping mappings
> of pfn %lx .. start dump\n", ACTIVE_PFN_MAX_OVERLAP, ent->pfn);
> + int idx;
> +
> + for (idx = 0; idx < HASH_SIZE; idx++) {
> +struct hash_bucket *bucket = _entry_hash[idx];
> +struct dma_debug_entry *entry;
> + unsigned long flags;
> +
> +list_for_each_entry(entry, >list, list) {
> + if (entry->pfn == ent->pfn) {
> + dev_info(entry->dev, "%s idx %d
> P=%Lx N=%lx D=%Lx L=%Lx %s %s\n",
> +type2name[entry->type], idx,
> +phys_addr(entry), entry->pfn,
> +entry->dev_addr, entry->size,
> +dir2name[entry->direction],
> +
> maperr2str[entry->map_err_type]);
> + }
> +}
> + }
> + dev_info(ent->dev, "DMA-API: exceeded %d overlapping mappings
> of pfn %lx .. end of dump\n", ACTIVE_PFN_MAX_OVERLAP, ent->pfn);
> + }
> }
>
>
> @@ -505,10 +533,10 @@ static int active_pfn_insert(struct dma_debug_entry
> *entry)
>
> spin_lock_irqsave(_lock, flags);
> rc = radix_tree_insert(_active_pfn, entry->pfn, entry);
> - if (rc == -EEXIST)
> - active_pfn_inc_overlap(entry->pfn);
> + if (rc == -EEXIST){
> + active_pfn_inc_overlap(entry);
> + }
> spin_unlock_irqrestore(_lock, flags);
> -
> return rc;
> }
>
>
> This results in:
> [ 27.708678] r8169 :0a:00.0 eth1: link down
> [ 27.712102] r8169 :0a:00.0 eth1: link down
> [ 28.015340] r8169 :0b:00.0 eth0: link down
> [ 28.015368] r8169 :0b:00.0 eth0: link down
> [ 29.654844] r8169 :0b:00.0 eth0: link up
> [ 30.278542] r8169 :0a:00.0 eth1: link up
> [ 60.829503] EXT4-fs (dm-2): mounted filesystem with ordered data mode.
> Opts: barrier=1,errors=remount-ro
> [ 69.708979] EXT4-fs (dm-42): mounted filesystem with ordered data mode.
> Opts: barrier=1,errors=remount-ro
> [ 76.128678] EXT4-fs (dm-43): mounted filesystem with ordered data mode.
> Opts: barrier=1,errors=remount-ro
> [ 82.922836] EXT4-fs (dm-44): mounted filesystem with ordered data mode.
> Opts: barrier=1,errors=remount-ro
> [ 89.232889] EXT4-fs (dm-45): mounted filesystem with ordered data mode.
> Opts: barrier=1,errors=remount-ro
> [ 95.359859] EXT4-fs (dm-46): mounted filesystem with ordered data mode.
> Opts: barrier=1,errors=remount-ro
> [ 101.638559] EXT4-fs (sdb1): mounted filesystem with ordered data mode.
> Opts: barrier=1,errors=remount-ro
> [ 218.073407] [ cut here ]
> [ 218.080983] WARNING: CPU: 5 PID: 0 at lib/dma-debug.c:492
> add_dma_entry+0xf1/0x210()
> [ 218.088550] DMA-API: exceeded 7 overlapping mappings of pfn 3c421
> [ 218.095988] Modules linked in:
> [ 218.103270] CPU: 5 PID: 0 Comm: swapper/5 Tainted: GW
> 3.14.0-rc2-20140211-pcireset-net-btrevert-xenblock-dmadebug5+ #1
> [ 218.110712] Hardware name: MSI MS-7640/890FXA-GD70 (MS-7640) , BIOS
> V1.8B1 09/13/2010
> [ 218.118134] 0009 88003fd437b8
Re: 3.14-mw regression: rtl8169 WARNING: DMA-API: exceeded 7 overlapping mappings of pfn 55ebe
Tuesday, February 11, 2014, 10:28:52 PM, you wrote:
> On Tue, 2014-02-11 at 20:56 +0100, Sander Eikelenboom wrote:
>> Hi Dan,
>>
>> FYI just tested and put Xen out of the equation (booting baremetal) and it
>> still persists.
>>
>> I tried something else .. don't know if it gives you anymore insights, but
>> it's worth the try:
>>
>> diff --git a/lib/dma-debug.c b/lib/dma-debug.c
>> index 2defd13..0fe5b75 100644
>> --- a/lib/dma-debug.c
>> +++ b/lib/dma-debug.c
>> @@ -474,11 +474,11 @@ static int active_pfn_set_overlap(unsigned long pfn,
>> int overlap)
>> return overlap;
>> }
>>
>> -static void active_pfn_inc_overlap(unsigned long pfn)
>> +static void active_pfn_inc_overlap(struct dma_debug_entry *ent)
>> {
>> - int overlap = active_pfn_read_overlap(pfn);
>> + int overlap = active_pfn_read_overlap(ent->pfn);
>>
>> - overlap = active_pfn_set_overlap(pfn, ++overlap);
>> + overlap = active_pfn_set_overlap(ent->pfn, ++overlap);
>>
>> /* If we overflowed the overlap counter then we're potentially
>> * leaking dma-mappings. Otherwise, if maps and unmaps are
>> @@ -486,15 +486,43 @@ static void active_pfn_inc_overlap(unsigned long pfn)
>> * debug_dma_assert_idle() as the pfn may be marked idle
>> * prematurely.
>> */
>> +
>> WARN_ONCE(overlap > ACTIVE_PFN_MAX_OVERLAP,
>> "DMA-API: exceeded %d overlapping mappings of pfn %lx\n",
>> - ACTIVE_PFN_MAX_OVERLAP, pfn);
>> + ACTIVE_PFN_MAX_OVERLAP, ent->pfn);
>> +
>> + if(overlap > ACTIVE_PFN_MAX_OVERLAP){
>> +
>> + dev_info(ent->dev, "DMA-API: exceeded %d overlapping
>> mappings of pfn %lx .. start dump\n", ACTIVE_PFN_MAX_OVERLAP, ent->pfn);
>> + int idx;
>> +
>> + for (idx = 0; idx < HASH_SIZE; idx++) {
>> +struct hash_bucket *bucket = _entry_hash[idx];
>> +struct dma_debug_entry *entry;
>> + unsigned long flags;
>> +
>> +list_for_each_entry(entry, >list, list) {
>> + if (entry->pfn == ent->pfn) {
>> + dev_info(entry->dev, "%s idx %d
>> P=%Lx N=%lx D=%Lx L=%Lx %s %s\n",
>> +type2name[entry->type], idx,
>> +phys_addr(entry),
>> entry->pfn,
>> +entry->dev_addr,
>> entry->size,
>> +dir2name[entry->direction],
>> +
>> maperr2str[entry->map_err_type]);
>> + }
>> +}
>> + }
>> + dev_info(ent->dev, "DMA-API: exceeded %d overlapping
>> mappings of pfn %lx .. end of dump\n", ACTIVE_PFN_MAX_OVERLAP, ent->pfn);
>> + }
>> }
>>
>>
>> @@ -505,10 +533,10 @@ static int active_pfn_insert(struct dma_debug_entry
>> *entry)
>>
>> spin_lock_irqsave(_lock, flags);
>> rc = radix_tree_insert(_active_pfn, entry->pfn, entry);
>> - if (rc == -EEXIST)
>> - active_pfn_inc_overlap(entry->pfn);
>> + if (rc == -EEXIST){
>> + active_pfn_inc_overlap(entry);
>> + }
>> spin_unlock_irqrestore(_lock, flags);
>> -
>> return rc;
>> }
>>
>>
>> This results in:
>> [ 27.708678] r8169 :0a:00.0 eth1: link down
>> [ 27.712102] r8169 :0a:00.0 eth1: link down
>> [ 28.015340] r8169 :0b:00.0 eth0: link down
>> [ 28.015368] r8169 :0b:00.0 eth0: link down
>> [ 29.654844] r8169 :0b:00.0 eth0: link up
>> [ 30.278542] r8169 :0a:00.0 eth1: link up
>> [ 60.829503] EXT4-fs (dm-2): mounted filesystem with ordered data mode.
>> Opts: barrier=1,errors=remount-ro
>> [ 69.708979] EXT4-fs (dm-42): mounted filesystem with ordered data mode.
>> Opts: barrier=1,errors=remount-ro
>> [ 76.128678] EXT4-fs (dm-43): mounted filesystem with ordered data mode.
>> Opts: barrier=1,errors=remount-ro
>> [ 82.922836] EXT4-fs (dm-44): mounted filesystem with ordered data mode.
>> Opts: barrier=1,errors=remount-ro
>> [ 89.232889] EXT4-fs (dm-45): mounted filesystem with ordered data mode.
>> Opts: barrier=1,errors=remount-ro
>> [ 95.359859] EXT4-fs (dm-46): mounted filesystem with ordered data mode.
>> Opts: barrier=1,errors=remount-ro
>> [ 101.638559] EXT4-fs (sdb1): mounted filesystem with ordered data mode.
>> Opts: barrier=1,errors=remount-ro
>> [ 218.073407] [ cut here ]
>> [ 218.080983] WARNING: CPU: 5 PID: 0 at lib/dma-debug.c:492
>> add_dma_entry+0xf1/0x210()
>> [ 218.088550] DMA-API: exceeded 7 overlapping mappings of pfn 3c421
>> [ 218.095988] Modules linked in:
>> [ 218.103270] CPU: 5 PID: 0 Comm: swapper/5 Tainted: GW
>>
Re: 3.14-mw regression: rtl8169 WARNING: DMA-API: exceeded 7 overlapping mappings of pfn 55ebe
On Tue, 2014-02-11 at 20:56 +0100, Sander Eikelenboom wrote:
> Hi Dan,
>
> FYI just tested and put Xen out of the equation (booting baremetal) and it
> still persists.
>
> I tried something else .. don't know if it gives you anymore insights, but
> it's worth the try:
>
> diff --git a/lib/dma-debug.c b/lib/dma-debug.c
> index 2defd13..0fe5b75 100644
> --- a/lib/dma-debug.c
> +++ b/lib/dma-debug.c
> @@ -474,11 +474,11 @@ static int active_pfn_set_overlap(unsigned long pfn,
> int overlap)
> return overlap;
> }
>
> -static void active_pfn_inc_overlap(unsigned long pfn)
> +static void active_pfn_inc_overlap(struct dma_debug_entry *ent)
> {
> - int overlap = active_pfn_read_overlap(pfn);
> + int overlap = active_pfn_read_overlap(ent->pfn);
>
> - overlap = active_pfn_set_overlap(pfn, ++overlap);
> + overlap = active_pfn_set_overlap(ent->pfn, ++overlap);
>
> /* If we overflowed the overlap counter then we're potentially
> * leaking dma-mappings. Otherwise, if maps and unmaps are
> @@ -486,15 +486,43 @@ static void active_pfn_inc_overlap(unsigned long pfn)
> * debug_dma_assert_idle() as the pfn may be marked idle
> * prematurely.
> */
> +
> WARN_ONCE(overlap > ACTIVE_PFN_MAX_OVERLAP,
> "DMA-API: exceeded %d overlapping mappings of pfn %lx\n",
> - ACTIVE_PFN_MAX_OVERLAP, pfn);
> + ACTIVE_PFN_MAX_OVERLAP, ent->pfn);
> +
> + if(overlap > ACTIVE_PFN_MAX_OVERLAP){
> +
> + dev_info(ent->dev, "DMA-API: exceeded %d overlapping mappings
> of pfn %lx .. start dump\n", ACTIVE_PFN_MAX_OVERLAP, ent->pfn);
> + int idx;
> +
> + for (idx = 0; idx < HASH_SIZE; idx++) {
> +struct hash_bucket *bucket = _entry_hash[idx];
> +struct dma_debug_entry *entry;
> + unsigned long flags;
> +
> +list_for_each_entry(entry, >list, list) {
> + if (entry->pfn == ent->pfn) {
> + dev_info(entry->dev, "%s idx %d
> P=%Lx N=%lx D=%Lx L=%Lx %s %s\n",
> +type2name[entry->type], idx,
> +phys_addr(entry), entry->pfn,
> +entry->dev_addr, entry->size,
> +dir2name[entry->direction],
> +
> maperr2str[entry->map_err_type]);
> + }
> +}
> + }
> + dev_info(ent->dev, "DMA-API: exceeded %d overlapping mappings
> of pfn %lx .. end of dump\n", ACTIVE_PFN_MAX_OVERLAP, ent->pfn);
> + }
> }
>
>
> @@ -505,10 +533,10 @@ static int active_pfn_insert(struct dma_debug_entry
> *entry)
>
> spin_lock_irqsave(_lock, flags);
> rc = radix_tree_insert(_active_pfn, entry->pfn, entry);
> - if (rc == -EEXIST)
> - active_pfn_inc_overlap(entry->pfn);
> + if (rc == -EEXIST){
> + active_pfn_inc_overlap(entry);
> + }
> spin_unlock_irqrestore(_lock, flags);
> -
> return rc;
> }
>
>
> This results in:
> [ 27.708678] r8169 :0a:00.0 eth1: link down
> [ 27.712102] r8169 :0a:00.0 eth1: link down
> [ 28.015340] r8169 :0b:00.0 eth0: link down
> [ 28.015368] r8169 :0b:00.0 eth0: link down
> [ 29.654844] r8169 :0b:00.0 eth0: link up
> [ 30.278542] r8169 :0a:00.0 eth1: link up
> [ 60.829503] EXT4-fs (dm-2): mounted filesystem with ordered data mode.
> Opts: barrier=1,errors=remount-ro
> [ 69.708979] EXT4-fs (dm-42): mounted filesystem with ordered data mode.
> Opts: barrier=1,errors=remount-ro
> [ 76.128678] EXT4-fs (dm-43): mounted filesystem with ordered data mode.
> Opts: barrier=1,errors=remount-ro
> [ 82.922836] EXT4-fs (dm-44): mounted filesystem with ordered data mode.
> Opts: barrier=1,errors=remount-ro
> [ 89.232889] EXT4-fs (dm-45): mounted filesystem with ordered data mode.
> Opts: barrier=1,errors=remount-ro
> [ 95.359859] EXT4-fs (dm-46): mounted filesystem with ordered data mode.
> Opts: barrier=1,errors=remount-ro
> [ 101.638559] EXT4-fs (sdb1): mounted filesystem with ordered data mode.
> Opts: barrier=1,errors=remount-ro
> [ 218.073407] [ cut here ]
> [ 218.080983] WARNING: CPU: 5 PID: 0 at lib/dma-debug.c:492
> add_dma_entry+0xf1/0x210()
> [ 218.088550] DMA-API: exceeded 7 overlapping mappings of pfn 3c421
> [ 218.095988] Modules linked in:
> [ 218.103270] CPU: 5 PID: 0 Comm: swapper/5 Tainted: GW
> 3.14.0-rc2-20140211-pcireset-net-btrevert-xenblock-dmadebug5+ #1
> [ 218.110712] Hardware name: MSI MS-7640/890FXA-GD70 (MS-7640) , BIOS
> V1.8B1 09/13/2010
> [ 218.118134] 0009 88003fd437b8 81b809c4
>
Re: 3.14-mw regression: rtl8169 WARNING: DMA-API: exceeded 7 overlapping mappings of pfn 55ebe
Hi Dan,
FYI just tested and put Xen out of the equation (booting baremetal) and it
still persists.
I tried something else .. don't know if it gives you anymore insights, but it's
worth the try:
diff --git a/lib/dma-debug.c b/lib/dma-debug.c
index 2defd13..0fe5b75 100644
--- a/lib/dma-debug.c
+++ b/lib/dma-debug.c
@@ -474,11 +474,11 @@ static int active_pfn_set_overlap(unsigned long pfn, int
overlap)
return overlap;
}
-static void active_pfn_inc_overlap(unsigned long pfn)
+static void active_pfn_inc_overlap(struct dma_debug_entry *ent)
{
- int overlap = active_pfn_read_overlap(pfn);
+ int overlap = active_pfn_read_overlap(ent->pfn);
- overlap = active_pfn_set_overlap(pfn, ++overlap);
+ overlap = active_pfn_set_overlap(ent->pfn, ++overlap);
/* If we overflowed the overlap counter then we're potentially
* leaking dma-mappings. Otherwise, if maps and unmaps are
@@ -486,15 +486,43 @@ static void active_pfn_inc_overlap(unsigned long pfn)
* debug_dma_assert_idle() as the pfn may be marked idle
* prematurely.
*/
+
WARN_ONCE(overlap > ACTIVE_PFN_MAX_OVERLAP,
"DMA-API: exceeded %d overlapping mappings of pfn %lx\n",
- ACTIVE_PFN_MAX_OVERLAP, pfn);
+ ACTIVE_PFN_MAX_OVERLAP, ent->pfn);
+
+ if(overlap > ACTIVE_PFN_MAX_OVERLAP){
+
+ dev_info(ent->dev, "DMA-API: exceeded %d overlapping mappings
of pfn %lx .. start dump\n", ACTIVE_PFN_MAX_OVERLAP, ent->pfn);
+ int idx;
+
+ for (idx = 0; idx < HASH_SIZE; idx++) {
+struct hash_bucket *bucket = _entry_hash[idx];
+struct dma_debug_entry *entry;
+ unsigned long flags;
+
+list_for_each_entry(entry, >list, list) {
+ if (entry->pfn == ent->pfn) {
+ dev_info(entry->dev, "%s idx %d
P=%Lx N=%lx D=%Lx L=%Lx %s %s\n",
+type2name[entry->type], idx,
+phys_addr(entry), entry->pfn,
+entry->dev_addr, entry->size,
+dir2name[entry->direction],
+
maperr2str[entry->map_err_type]);
+ }
+}
+ }
+ dev_info(ent->dev, "DMA-API: exceeded %d overlapping mappings
of pfn %lx .. end of dump\n", ACTIVE_PFN_MAX_OVERLAP, ent->pfn);
+ }
}
@@ -505,10 +533,10 @@ static int active_pfn_insert(struct dma_debug_entry
*entry)
spin_lock_irqsave(_lock, flags);
rc = radix_tree_insert(_active_pfn, entry->pfn, entry);
- if (rc == -EEXIST)
- active_pfn_inc_overlap(entry->pfn);
+ if (rc == -EEXIST){
+ active_pfn_inc_overlap(entry);
+ }
spin_unlock_irqrestore(_lock, flags);
-
return rc;
}
This results in:
[ 27.708678] r8169 :0a:00.0 eth1: link down
[ 27.712102] r8169 :0a:00.0 eth1: link down
[ 28.015340] r8169 :0b:00.0 eth0: link down
[ 28.015368] r8169 :0b:00.0 eth0: link down
[ 29.654844] r8169 :0b:00.0 eth0: link up
[ 30.278542] r8169 :0a:00.0 eth1: link up
[ 60.829503] EXT4-fs (dm-2): mounted filesystem with ordered data mode. Opts:
barrier=1,errors=remount-ro
[ 69.708979] EXT4-fs (dm-42): mounted filesystem with ordered data mode.
Opts: barrier=1,errors=remount-ro
[ 76.128678] EXT4-fs (dm-43): mounted filesystem with ordered data mode.
Opts: barrier=1,errors=remount-ro
[ 82.922836] EXT4-fs (dm-44): mounted filesystem with ordered data mode.
Opts: barrier=1,errors=remount-ro
[ 89.232889] EXT4-fs (dm-45): mounted filesystem with ordered data mode.
Opts: barrier=1,errors=remount-ro
[ 95.359859] EXT4-fs (dm-46): mounted filesystem with ordered data mode.
Opts: barrier=1,errors=remount-ro
[ 101.638559] EXT4-fs (sdb1): mounted filesystem with ordered data mode. Opts:
barrier=1,errors=remount-ro
[ 218.073407] [ cut here ]
[ 218.080983] WARNING: CPU: 5 PID: 0 at lib/dma-debug.c:492
add_dma_entry+0xf1/0x210()
[ 218.088550] DMA-API: exceeded 7 overlapping mappings of pfn 3c421
[ 218.095988] Modules linked in:
[ 218.103270] CPU: 5 PID: 0 Comm: swapper/5 Tainted: GW
3.14.0-rc2-20140211-pcireset-net-btrevert-xenblock-dmadebug5+ #1
[ 218.110712] Hardware name: MSI MS-7640/890FXA-GD70 (MS-7640) , BIOS V1.8B1
09/13/2010
[ 218.118134] 0009 88003fd437b8 81b809c4
88003e308000
[ 218.125556] 88003fd43808 88003fd437f8 810c985c
[ 218.132917] ffef 0036 88003d9d3c00
0282
[ 218.140154] Call Trace:
[ 218.147193][] dump_stack+0x46/0x58
[ 218.154271] []
Re: 3.14-mw regression: rtl8169 WARNING: DMA-API: exceeded 7 overlapping mappings of pfn 55ebe
Hi Dan,
FYI just tested and put Xen out of the equation (booting baremetal) and it
still persists.
I tried something else .. don't know if it gives you anymore insights, but it's
worth the try:
diff --git a/lib/dma-debug.c b/lib/dma-debug.c
index 2defd13..0fe5b75 100644
--- a/lib/dma-debug.c
+++ b/lib/dma-debug.c
@@ -474,11 +474,11 @@ static int active_pfn_set_overlap(unsigned long pfn, int
overlap)
return overlap;
}
-static void active_pfn_inc_overlap(unsigned long pfn)
+static void active_pfn_inc_overlap(struct dma_debug_entry *ent)
{
- int overlap = active_pfn_read_overlap(pfn);
+ int overlap = active_pfn_read_overlap(ent-pfn);
- overlap = active_pfn_set_overlap(pfn, ++overlap);
+ overlap = active_pfn_set_overlap(ent-pfn, ++overlap);
/* If we overflowed the overlap counter then we're potentially
* leaking dma-mappings. Otherwise, if maps and unmaps are
@@ -486,15 +486,43 @@ static void active_pfn_inc_overlap(unsigned long pfn)
* debug_dma_assert_idle() as the pfn may be marked idle
* prematurely.
*/
+
WARN_ONCE(overlap ACTIVE_PFN_MAX_OVERLAP,
DMA-API: exceeded %d overlapping mappings of pfn %lx\n,
- ACTIVE_PFN_MAX_OVERLAP, pfn);
+ ACTIVE_PFN_MAX_OVERLAP, ent-pfn);
+
+ if(overlap ACTIVE_PFN_MAX_OVERLAP){
+
+ dev_info(ent-dev, DMA-API: exceeded %d overlapping mappings
of pfn %lx .. start dump\n, ACTIVE_PFN_MAX_OVERLAP, ent-pfn);
+ int idx;
+
+ for (idx = 0; idx HASH_SIZE; idx++) {
+struct hash_bucket *bucket = dma_entry_hash[idx];
+struct dma_debug_entry *entry;
+ unsigned long flags;
+
+list_for_each_entry(entry, bucket-list, list) {
+ if (entry-pfn == ent-pfn) {
+ dev_info(entry-dev, %s idx %d
P=%Lx N=%lx D=%Lx L=%Lx %s %s\n,
+type2name[entry-type], idx,
+phys_addr(entry), entry-pfn,
+entry-dev_addr, entry-size,
+dir2name[entry-direction],
+
maperr2str[entry-map_err_type]);
+ }
+}
+ }
+ dev_info(ent-dev, DMA-API: exceeded %d overlapping mappings
of pfn %lx .. end of dump\n, ACTIVE_PFN_MAX_OVERLAP, ent-pfn);
+ }
}
@@ -505,10 +533,10 @@ static int active_pfn_insert(struct dma_debug_entry
*entry)
spin_lock_irqsave(radix_lock, flags);
rc = radix_tree_insert(dma_active_pfn, entry-pfn, entry);
- if (rc == -EEXIST)
- active_pfn_inc_overlap(entry-pfn);
+ if (rc == -EEXIST){
+ active_pfn_inc_overlap(entry);
+ }
spin_unlock_irqrestore(radix_lock, flags);
-
return rc;
}
This results in:
[ 27.708678] r8169 :0a:00.0 eth1: link down
[ 27.712102] r8169 :0a:00.0 eth1: link down
[ 28.015340] r8169 :0b:00.0 eth0: link down
[ 28.015368] r8169 :0b:00.0 eth0: link down
[ 29.654844] r8169 :0b:00.0 eth0: link up
[ 30.278542] r8169 :0a:00.0 eth1: link up
[ 60.829503] EXT4-fs (dm-2): mounted filesystem with ordered data mode. Opts:
barrier=1,errors=remount-ro
[ 69.708979] EXT4-fs (dm-42): mounted filesystem with ordered data mode.
Opts: barrier=1,errors=remount-ro
[ 76.128678] EXT4-fs (dm-43): mounted filesystem with ordered data mode.
Opts: barrier=1,errors=remount-ro
[ 82.922836] EXT4-fs (dm-44): mounted filesystem with ordered data mode.
Opts: barrier=1,errors=remount-ro
[ 89.232889] EXT4-fs (dm-45): mounted filesystem with ordered data mode.
Opts: barrier=1,errors=remount-ro
[ 95.359859] EXT4-fs (dm-46): mounted filesystem with ordered data mode.
Opts: barrier=1,errors=remount-ro
[ 101.638559] EXT4-fs (sdb1): mounted filesystem with ordered data mode. Opts:
barrier=1,errors=remount-ro
[ 218.073407] [ cut here ]
[ 218.080983] WARNING: CPU: 5 PID: 0 at lib/dma-debug.c:492
add_dma_entry+0xf1/0x210()
[ 218.088550] DMA-API: exceeded 7 overlapping mappings of pfn 3c421
[ 218.095988] Modules linked in:
[ 218.103270] CPU: 5 PID: 0 Comm: swapper/5 Tainted: GW
3.14.0-rc2-20140211-pcireset-net-btrevert-xenblock-dmadebug5+ #1
[ 218.110712] Hardware name: MSI MS-7640/890FXA-GD70 (MS-7640) , BIOS V1.8B1
09/13/2010
[ 218.118134] 0009 88003fd437b8 81b809c4
88003e308000
[ 218.125556] 88003fd43808 88003fd437f8 810c985c
[ 218.132917] ffef 0036 88003d9d3c00
0282
[ 218.140154] Call Trace:
[ 218.147193] IRQ [81b809c4] dump_stack+0x46/0x58
[ 218.154271]
Re: 3.14-mw regression: rtl8169 WARNING: DMA-API: exceeded 7 overlapping mappings of pfn 55ebe
On Tue, 2014-02-11 at 20:56 +0100, Sander Eikelenboom wrote:
Hi Dan,
FYI just tested and put Xen out of the equation (booting baremetal) and it
still persists.
I tried something else .. don't know if it gives you anymore insights, but
it's worth the try:
diff --git a/lib/dma-debug.c b/lib/dma-debug.c
index 2defd13..0fe5b75 100644
--- a/lib/dma-debug.c
+++ b/lib/dma-debug.c
@@ -474,11 +474,11 @@ static int active_pfn_set_overlap(unsigned long pfn,
int overlap)
return overlap;
}
-static void active_pfn_inc_overlap(unsigned long pfn)
+static void active_pfn_inc_overlap(struct dma_debug_entry *ent)
{
- int overlap = active_pfn_read_overlap(pfn);
+ int overlap = active_pfn_read_overlap(ent-pfn);
- overlap = active_pfn_set_overlap(pfn, ++overlap);
+ overlap = active_pfn_set_overlap(ent-pfn, ++overlap);
/* If we overflowed the overlap counter then we're potentially
* leaking dma-mappings. Otherwise, if maps and unmaps are
@@ -486,15 +486,43 @@ static void active_pfn_inc_overlap(unsigned long pfn)
* debug_dma_assert_idle() as the pfn may be marked idle
* prematurely.
*/
+
WARN_ONCE(overlap ACTIVE_PFN_MAX_OVERLAP,
DMA-API: exceeded %d overlapping mappings of pfn %lx\n,
- ACTIVE_PFN_MAX_OVERLAP, pfn);
+ ACTIVE_PFN_MAX_OVERLAP, ent-pfn);
+
+ if(overlap ACTIVE_PFN_MAX_OVERLAP){
+
+ dev_info(ent-dev, DMA-API: exceeded %d overlapping mappings
of pfn %lx .. start dump\n, ACTIVE_PFN_MAX_OVERLAP, ent-pfn);
+ int idx;
+
+ for (idx = 0; idx HASH_SIZE; idx++) {
+struct hash_bucket *bucket = dma_entry_hash[idx];
+struct dma_debug_entry *entry;
+ unsigned long flags;
+
+list_for_each_entry(entry, bucket-list, list) {
+ if (entry-pfn == ent-pfn) {
+ dev_info(entry-dev, %s idx %d
P=%Lx N=%lx D=%Lx L=%Lx %s %s\n,
+type2name[entry-type], idx,
+phys_addr(entry), entry-pfn,
+entry-dev_addr, entry-size,
+dir2name[entry-direction],
+
maperr2str[entry-map_err_type]);
+ }
+}
+ }
+ dev_info(ent-dev, DMA-API: exceeded %d overlapping mappings
of pfn %lx .. end of dump\n, ACTIVE_PFN_MAX_OVERLAP, ent-pfn);
+ }
}
@@ -505,10 +533,10 @@ static int active_pfn_insert(struct dma_debug_entry
*entry)
spin_lock_irqsave(radix_lock, flags);
rc = radix_tree_insert(dma_active_pfn, entry-pfn, entry);
- if (rc == -EEXIST)
- active_pfn_inc_overlap(entry-pfn);
+ if (rc == -EEXIST){
+ active_pfn_inc_overlap(entry);
+ }
spin_unlock_irqrestore(radix_lock, flags);
-
return rc;
}
This results in:
[ 27.708678] r8169 :0a:00.0 eth1: link down
[ 27.712102] r8169 :0a:00.0 eth1: link down
[ 28.015340] r8169 :0b:00.0 eth0: link down
[ 28.015368] r8169 :0b:00.0 eth0: link down
[ 29.654844] r8169 :0b:00.0 eth0: link up
[ 30.278542] r8169 :0a:00.0 eth1: link up
[ 60.829503] EXT4-fs (dm-2): mounted filesystem with ordered data mode.
Opts: barrier=1,errors=remount-ro
[ 69.708979] EXT4-fs (dm-42): mounted filesystem with ordered data mode.
Opts: barrier=1,errors=remount-ro
[ 76.128678] EXT4-fs (dm-43): mounted filesystem with ordered data mode.
Opts: barrier=1,errors=remount-ro
[ 82.922836] EXT4-fs (dm-44): mounted filesystem with ordered data mode.
Opts: barrier=1,errors=remount-ro
[ 89.232889] EXT4-fs (dm-45): mounted filesystem with ordered data mode.
Opts: barrier=1,errors=remount-ro
[ 95.359859] EXT4-fs (dm-46): mounted filesystem with ordered data mode.
Opts: barrier=1,errors=remount-ro
[ 101.638559] EXT4-fs (sdb1): mounted filesystem with ordered data mode.
Opts: barrier=1,errors=remount-ro
[ 218.073407] [ cut here ]
[ 218.080983] WARNING: CPU: 5 PID: 0 at lib/dma-debug.c:492
add_dma_entry+0xf1/0x210()
[ 218.088550] DMA-API: exceeded 7 overlapping mappings of pfn 3c421
[ 218.095988] Modules linked in:
[ 218.103270] CPU: 5 PID: 0 Comm: swapper/5 Tainted: GW
3.14.0-rc2-20140211-pcireset-net-btrevert-xenblock-dmadebug5+ #1
[ 218.110712] Hardware name: MSI MS-7640/890FXA-GD70 (MS-7640) , BIOS
V1.8B1 09/13/2010
[ 218.118134] 0009 88003fd437b8 81b809c4
88003e308000
[ 218.125556] 88003fd43808 88003fd437f8 810c985c
[ 218.132917]
Re: 3.14-mw regression: rtl8169 WARNING: DMA-API: exceeded 7 overlapping mappings of pfn 55ebe
Tuesday, February 11, 2014, 10:28:52 PM, you wrote:
On Tue, 2014-02-11 at 20:56 +0100, Sander Eikelenboom wrote:
Hi Dan,
FYI just tested and put Xen out of the equation (booting baremetal) and it
still persists.
I tried something else .. don't know if it gives you anymore insights, but
it's worth the try:
diff --git a/lib/dma-debug.c b/lib/dma-debug.c
index 2defd13..0fe5b75 100644
--- a/lib/dma-debug.c
+++ b/lib/dma-debug.c
@@ -474,11 +474,11 @@ static int active_pfn_set_overlap(unsigned long pfn,
int overlap)
return overlap;
}
-static void active_pfn_inc_overlap(unsigned long pfn)
+static void active_pfn_inc_overlap(struct dma_debug_entry *ent)
{
- int overlap = active_pfn_read_overlap(pfn);
+ int overlap = active_pfn_read_overlap(ent-pfn);
- overlap = active_pfn_set_overlap(pfn, ++overlap);
+ overlap = active_pfn_set_overlap(ent-pfn, ++overlap);
/* If we overflowed the overlap counter then we're potentially
* leaking dma-mappings. Otherwise, if maps and unmaps are
@@ -486,15 +486,43 @@ static void active_pfn_inc_overlap(unsigned long pfn)
* debug_dma_assert_idle() as the pfn may be marked idle
* prematurely.
*/
+
WARN_ONCE(overlap ACTIVE_PFN_MAX_OVERLAP,
DMA-API: exceeded %d overlapping mappings of pfn %lx\n,
- ACTIVE_PFN_MAX_OVERLAP, pfn);
+ ACTIVE_PFN_MAX_OVERLAP, ent-pfn);
+
+ if(overlap ACTIVE_PFN_MAX_OVERLAP){
+
+ dev_info(ent-dev, DMA-API: exceeded %d overlapping
mappings of pfn %lx .. start dump\n, ACTIVE_PFN_MAX_OVERLAP, ent-pfn);
+ int idx;
+
+ for (idx = 0; idx HASH_SIZE; idx++) {
+struct hash_bucket *bucket = dma_entry_hash[idx];
+struct dma_debug_entry *entry;
+ unsigned long flags;
+
+list_for_each_entry(entry, bucket-list, list) {
+ if (entry-pfn == ent-pfn) {
+ dev_info(entry-dev, %s idx %d
P=%Lx N=%lx D=%Lx L=%Lx %s %s\n,
+type2name[entry-type], idx,
+phys_addr(entry),
entry-pfn,
+entry-dev_addr,
entry-size,
+dir2name[entry-direction],
+
maperr2str[entry-map_err_type]);
+ }
+}
+ }
+ dev_info(ent-dev, DMA-API: exceeded %d overlapping
mappings of pfn %lx .. end of dump\n, ACTIVE_PFN_MAX_OVERLAP, ent-pfn);
+ }
}
@@ -505,10 +533,10 @@ static int active_pfn_insert(struct dma_debug_entry
*entry)
spin_lock_irqsave(radix_lock, flags);
rc = radix_tree_insert(dma_active_pfn, entry-pfn, entry);
- if (rc == -EEXIST)
- active_pfn_inc_overlap(entry-pfn);
+ if (rc == -EEXIST){
+ active_pfn_inc_overlap(entry);
+ }
spin_unlock_irqrestore(radix_lock, flags);
-
return rc;
}
This results in:
[ 27.708678] r8169 :0a:00.0 eth1: link down
[ 27.712102] r8169 :0a:00.0 eth1: link down
[ 28.015340] r8169 :0b:00.0 eth0: link down
[ 28.015368] r8169 :0b:00.0 eth0: link down
[ 29.654844] r8169 :0b:00.0 eth0: link up
[ 30.278542] r8169 :0a:00.0 eth1: link up
[ 60.829503] EXT4-fs (dm-2): mounted filesystem with ordered data mode.
Opts: barrier=1,errors=remount-ro
[ 69.708979] EXT4-fs (dm-42): mounted filesystem with ordered data mode.
Opts: barrier=1,errors=remount-ro
[ 76.128678] EXT4-fs (dm-43): mounted filesystem with ordered data mode.
Opts: barrier=1,errors=remount-ro
[ 82.922836] EXT4-fs (dm-44): mounted filesystem with ordered data mode.
Opts: barrier=1,errors=remount-ro
[ 89.232889] EXT4-fs (dm-45): mounted filesystem with ordered data mode.
Opts: barrier=1,errors=remount-ro
[ 95.359859] EXT4-fs (dm-46): mounted filesystem with ordered data mode.
Opts: barrier=1,errors=remount-ro
[ 101.638559] EXT4-fs (sdb1): mounted filesystem with ordered data mode.
Opts: barrier=1,errors=remount-ro
[ 218.073407] [ cut here ]
[ 218.080983] WARNING: CPU: 5 PID: 0 at lib/dma-debug.c:492
add_dma_entry+0xf1/0x210()
[ 218.088550] DMA-API: exceeded 7 overlapping mappings of pfn 3c421
[ 218.095988] Modules linked in:
[ 218.103270] CPU: 5 PID: 0 Comm: swapper/5 Tainted: GW
3.14.0-rc2-20140211-pcireset-net-btrevert-xenblock-dmadebug5+ #1
[ 218.110712] Hardware name: MSI MS-7640/890FXA-GD70 (MS-7640) , BIOS
V1.8B1 09/13/2010
[ 218.118134] 0009 88003fd437b8 81b809c4
88003e308000
[ 218.125556] 88003fd43808
Re: 3.14-mw regression: rtl8169 WARNING: DMA-API: exceeded 7 overlapping mappings of pfn 55ebe
On Tue, Feb 11, 2014 at 11:56 AM, Sander Eikelenboom
li...@eikelenboom.it wrote:
Hi Dan,
FYI just tested and put Xen out of the equation (booting baremetal) and it
still persists.
I tried something else .. don't know if it gives you anymore insights, but
it's worth the try:
This is great! See below:
diff --git a/lib/dma-debug.c b/lib/dma-debug.c
index 2defd13..0fe5b75 100644
--- a/lib/dma-debug.c
+++ b/lib/dma-debug.c
@@ -474,11 +474,11 @@ static int active_pfn_set_overlap(unsigned long pfn,
int overlap)
return overlap;
}
-static void active_pfn_inc_overlap(unsigned long pfn)
+static void active_pfn_inc_overlap(struct dma_debug_entry *ent)
{
- int overlap = active_pfn_read_overlap(pfn);
+ int overlap = active_pfn_read_overlap(ent-pfn);
- overlap = active_pfn_set_overlap(pfn, ++overlap);
+ overlap = active_pfn_set_overlap(ent-pfn, ++overlap);
/* If we overflowed the overlap counter then we're potentially
* leaking dma-mappings. Otherwise, if maps and unmaps are
@@ -486,15 +486,43 @@ static void active_pfn_inc_overlap(unsigned long pfn)
* debug_dma_assert_idle() as the pfn may be marked idle
* prematurely.
*/
+
WARN_ONCE(overlap ACTIVE_PFN_MAX_OVERLAP,
DMA-API: exceeded %d overlapping mappings of pfn %lx\n,
- ACTIVE_PFN_MAX_OVERLAP, pfn);
+ ACTIVE_PFN_MAX_OVERLAP, ent-pfn);
+
+ if(overlap ACTIVE_PFN_MAX_OVERLAP){
+
+ dev_info(ent-dev, DMA-API: exceeded %d overlapping mappings
of pfn %lx .. start dump\n, ACTIVE_PFN_MAX_OVERLAP, ent-pfn);
+ int idx;
+
+ for (idx = 0; idx HASH_SIZE; idx++) {
+struct hash_bucket *bucket = dma_entry_hash[idx];
+struct dma_debug_entry *entry;
+ unsigned long flags;
+
+list_for_each_entry(entry, bucket-list, list) {
+ if (entry-pfn == ent-pfn) {
+ dev_info(entry-dev, %s idx %d
P=%Lx N=%lx D=%Lx L=%Lx %s %s\n,
+type2name[entry-type], idx,
+phys_addr(entry), entry-pfn,
+entry-dev_addr, entry-size,
+dir2name[entry-direction],
+
maperr2str[entry-map_err_type]);
+ }
+}
+ }
+ dev_info(ent-dev, DMA-API: exceeded %d overlapping mappings
of pfn %lx .. end of dump\n, ACTIVE_PFN_MAX_OVERLAP, ent-pfn);
+ }
}
@@ -505,10 +533,10 @@ static int active_pfn_insert(struct dma_debug_entry
*entry)
spin_lock_irqsave(radix_lock, flags);
rc = radix_tree_insert(dma_active_pfn, entry-pfn, entry);
- if (rc == -EEXIST)
- active_pfn_inc_overlap(entry-pfn);
+ if (rc == -EEXIST){
+ active_pfn_inc_overlap(entry);
+ }
spin_unlock_irqrestore(radix_lock, flags);
-
return rc;
}
This results in:
[ 27.708678] r8169 :0a:00.0 eth1: link down
[ 27.712102] r8169 :0a:00.0 eth1: link down
[ 28.015340] r8169 :0b:00.0 eth0: link down
[ 28.015368] r8169 :0b:00.0 eth0: link down
[ 29.654844] r8169 :0b:00.0 eth0: link up
[ 30.278542] r8169 :0a:00.0 eth1: link up
[ 60.829503] EXT4-fs (dm-2): mounted filesystem with ordered data mode.
Opts: barrier=1,errors=remount-ro
[ 69.708979] EXT4-fs (dm-42): mounted filesystem with ordered data mode.
Opts: barrier=1,errors=remount-ro
[ 76.128678] EXT4-fs (dm-43): mounted filesystem with ordered data mode.
Opts: barrier=1,errors=remount-ro
[ 82.922836] EXT4-fs (dm-44): mounted filesystem with ordered data mode.
Opts: barrier=1,errors=remount-ro
[ 89.232889] EXT4-fs (dm-45): mounted filesystem with ordered data mode.
Opts: barrier=1,errors=remount-ro
[ 95.359859] EXT4-fs (dm-46): mounted filesystem with ordered data mode.
Opts: barrier=1,errors=remount-ro
[ 101.638559] EXT4-fs (sdb1): mounted filesystem with ordered data mode.
Opts: barrier=1,errors=remount-ro
[ 218.073407] [ cut here ]
[ 218.080983] WARNING: CPU: 5 PID: 0 at lib/dma-debug.c:492
add_dma_entry+0xf1/0x210()
[ 218.088550] DMA-API: exceeded 7 overlapping mappings of pfn 3c421
[ 218.095988] Modules linked in:
[ 218.103270] CPU: 5 PID: 0 Comm: swapper/5 Tainted: GW
3.14.0-rc2-20140211-pcireset-net-btrevert-xenblock-dmadebug5+ #1
[ 218.110712] Hardware name: MSI MS-7640/890FXA-GD70 (MS-7640) , BIOS
V1.8B1 09/13/2010
[ 218.118134] 0009 88003fd437b8 81b809c4
88003e308000
[ 218.125556] 88003fd43808 88003fd437f8 810c985c
Re: 3.14-mw regression: rtl8169 WARNING: DMA-API: exceeded 7 overlapping mappings of pfn 55ebe
On Tue, 2014-02-11 at 18:07 -0800, Dan Williams wrote: The overlap granularity is too large. Multiple dma_map_single mappings are allowed to a given page as long as they don't collide on the same cache line. I am not sure why you try number of mappings of a page. Try launching 100 concurrent netperf -t TCP_SENFILE Same page might be mapped more than 100 times, more than 1 times in some cases. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.14-mw regression: rtl8169 WARNING: DMA-API: exceeded 7 overlapping mappings of pfn 55ebe
On Thu, Feb 6, 2014 at 6:27 AM, Sander Eikelenboom wrote: Not using it seems to prevent the warning, but before 3.14 i have never seen this (with r8169.use_dac=1) > >> If you are still hitting this with the patch: > >> 59f2e7df574c dma-debug: fix overlap detection > >> ...then I'm more inclined to think it is an actual positive report. > >> If you don't mind I'll send some debug patches to narrow this down. > > Please do .. sounds better than bisecting :-) > Hi, attached is a patch that should give some insight whether the driver is triggering many overlapping mappings. Try it on top of 3.14-rc1. Thank you for the debug help! debug-overlap Description: Binary data
Re: 3.14-mw regression: rtl8169 WARNING: DMA-API: exceeded 7 overlapping mappings of pfn 55ebe
Thursday, February 6, 2014, 3:26:09 PM, you wrote: > On Thu, Feb 6, 2014 at 5:09 AM, Sander Eikelenboom > wrote: >> Hmm ok that last message was false .. sorry for that .. it did happen again >> without r8169.use_dac=1, it just doesn't seem to happen all the time... >> >> Konrad / Wei, do you happen to know of any xen related change that went into >> 3.14 merge window that relates to dma / xen networking ? >> >> -- >> Sander >> >> complete stacktrace: >> >> [ 342.710738] [ cut here ] >> [ 342.726890] WARNING: CPU: 0 PID: 0 at lib/dma-debug.c:491 >> add_dma_entry+0x105/0x130() >> [ 342.743210] DMA-API: exceeded 7 overlapping mappings of pfn 40b00 >> [ 342.759510] Modules linked in: >> [ 342.775557] CPU: 0 PID: 0 Comm: swapper/0 Not tainted >> 3.14.0-rc1-20140206-pcireset-net-btrevert+ #1 >> [ 342.791706] Hardware name: MSI MS-7640/890FXA-GD70 (MS-7640) , BIOS >> V1.8B1 09/13/2010 >> [ 342.807627] 0009 88005f603828 81ad29fc >> 822134e0 >> [ 342.823430] 88005f603878 88005f603868 810bdf62 >> 8800 >> [ 342.839081] 00040b00 ffef 822102e0 >> 8800592b9098 >> [ 342.854572] Call Trace: >> [ 342.869748][] dump_stack+0x46/0x58 >> [ 342.884915] [] warn_slowpath_common+0x82/0xb0 >> [ 342.899710] [] warn_slowpath_fmt+0x41/0x50 >> [ 342.914395] [] ? active_pfn_read_overlap+0x3a/0x70 >> [ 342.929166] [] add_dma_entry+0x105/0x130 >> [ 342.943733] [] debug_dma_map_page+0x126/0x150 >> [ 342.957988] [] rtl8169_start_xmit+0x216/0xa20 >> [ 342.972306] [] ? dev_queue_xmit_nit+0x1ef/0x260 >> [ 342.986523] [] ? dev_loopback_xmit+0x1e0/0x1e0 >> [ 343.000689] [] dev_hard_start_xmit+0x2e6/0x4a0 >> [ 343.014466] [] sch_direct_xmit+0xfe/0x280 >> [ 343.028052] [] __dev_queue_xmit+0x23c/0x630 >> [ 343.041338] [] ? dev_hard_start_xmit+0x4a0/0x4a0 >> [ 343.054483] [] ? ip_output+0x54/0xf0 >> [ 343.067659] [] dev_queue_xmit+0xb/0x10 >> [ 343.080804] [] ip_finish_output+0x2cb/0x670 >> [ 343.093746] [] ? ip_output+0x54/0xf0 >> [ 343.106391] [] ip_output+0x54/0xf0 >> [ 343.118683] [] ip_forward_finish+0x71/0x1a0 >> [ 343.130901] [] ip_forward+0x1a3/0x440 >> [ 343.142829] [] ? lock_is_held+0x8b/0xb0 >> [ 343.154346] [] ip_rcv_finish+0x150/0x660 >> [ 343.165748] [] ip_rcv+0x22b/0x370 >> [ 343.176838] [] ? packet_rcv_spkt+0x42/0x190 >> [ 343.187659] [] __netif_receive_skb_core+0x6d2/0x8a0 >> [ 343.198209] [] ? __netif_receive_skb_core+0x114/0x8a0 >> [ 343.208819] [] ? xen_clocksource_read+0x20/0x30 >> [ 343.219471] [] ? getnstimeofday+0x9/0x30 >> [ 343.229862] [] __netif_receive_skb+0x1c/0x70 >> [ 343.239953] [] netif_receive_skb_internal+0x1e/0xf0 >> [ 343.249908] [] napi_gro_receive+0x70/0xa0 >> [ 343.259509] [] rtl8169_poll+0x2d3/0x680 >> [ 343.268982] [] ? _raw_spin_unlock_irq+0x2b/0x50 >> [ 343.278091] [] net_rx_action+0x161/0x260 >> [ 343.287056] [] __do_softirq+0x12c/0x280 >> [ 343.295756] [] irq_exit+0xa2/0xd0 >> [ 343.304235] [] xen_evtchn_do_upcall+0x2f/0x40 >> [ 343.312387] [] xen_do_hypervisor_callback+0x1e/0x30 >> [ 343.320389][] ? xen_hypercall_sched_op+0xa/0x20 >> [ 343.328171] [] ? xen_hypercall_sched_op+0xa/0x20 >> [ 343.335738] [] ? xen_safe_halt+0x10/0x20 >> [ 343.343142] [] ? default_idle+0x18/0x20 >> [ 343.350202] [] ? arch_cpu_idle+0x2e/0x40 >> [ 343.356994] [] ? cpu_startup_entry+0x91/0x1e0 >> [ 343.363658] [] ? rest_init+0xb7/0xc0 >> [ 343.369924] [] ? csum_partial_copy_generic+0x170/0x170 >> [ 343.376057] [] ? start_kernel+0x409/0x416 >> [ 343.381972] [] ? repair_env_string+0x5e/0x5e >> [ 343.387573] [] ? x86_64_start_reservations+0x2a/0x2c >> [ 343.393152] [] ? xen_start_kernel+0x586/0x588 >> [ 343.398628] ---[ end trace 8379b598fb7ef5ee ]--- >> >> >> >> >> >> Thursday, February 6, 2014, 12:36:31 PM, you wrote: >> >>> Hi Dan / Francois, >> >>> Didn't have time to test it before, but the patch doesn't seem to help. >>> I'm still getting the "DMA-API: exceeded 7 overlapping mappings of pfn >>> 55ebe", >>> but i see now i forgot to mention i use r8169.use_dac=1 ... >> >>> Not using it seems to prevent the warning, but before 3.14 i have never >>> seen this (with r8169.use_dac=1) > If you are still hitting this with the patch: > 59f2e7df574c dma-debug: fix overlap detection > ...then I'm more inclined to think it is an actual positive report. > If you don't mind I'll send some debug patches to narrow this down. Please do .. sounds better than bisecting :-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.14-mw regression: rtl8169 WARNING: DMA-API: exceeded 7 overlapping mappings of pfn 55ebe
On Thu, Feb 6, 2014 at 5:09 AM, Sander Eikelenboom wrote: > Hmm ok that last message was false .. sorry for that .. it did happen again > without r8169.use_dac=1, it just doesn't seem to happen all the time... > > Konrad / Wei, do you happen to know of any xen related change that went into > 3.14 merge window that relates to dma / xen networking ? > > -- > Sander > > complete stacktrace: > > [ 342.710738] [ cut here ] > [ 342.726890] WARNING: CPU: 0 PID: 0 at lib/dma-debug.c:491 > add_dma_entry+0x105/0x130() > [ 342.743210] DMA-API: exceeded 7 overlapping mappings of pfn 40b00 > [ 342.759510] Modules linked in: > [ 342.775557] CPU: 0 PID: 0 Comm: swapper/0 Not tainted > 3.14.0-rc1-20140206-pcireset-net-btrevert+ #1 > [ 342.791706] Hardware name: MSI MS-7640/890FXA-GD70 (MS-7640) , BIOS > V1.8B1 09/13/2010 > [ 342.807627] 0009 88005f603828 81ad29fc > 822134e0 > [ 342.823430] 88005f603878 88005f603868 810bdf62 > 8800 > [ 342.839081] 00040b00 ffef 822102e0 > 8800592b9098 > [ 342.854572] Call Trace: > [ 342.869748][] dump_stack+0x46/0x58 > [ 342.884915] [] warn_slowpath_common+0x82/0xb0 > [ 342.899710] [] warn_slowpath_fmt+0x41/0x50 > [ 342.914395] [] ? active_pfn_read_overlap+0x3a/0x70 > [ 342.929166] [] add_dma_entry+0x105/0x130 > [ 342.943733] [] debug_dma_map_page+0x126/0x150 > [ 342.957988] [] rtl8169_start_xmit+0x216/0xa20 > [ 342.972306] [] ? dev_queue_xmit_nit+0x1ef/0x260 > [ 342.986523] [] ? dev_loopback_xmit+0x1e0/0x1e0 > [ 343.000689] [] dev_hard_start_xmit+0x2e6/0x4a0 > [ 343.014466] [] sch_direct_xmit+0xfe/0x280 > [ 343.028052] [] __dev_queue_xmit+0x23c/0x630 > [ 343.041338] [] ? dev_hard_start_xmit+0x4a0/0x4a0 > [ 343.054483] [] ? ip_output+0x54/0xf0 > [ 343.067659] [] dev_queue_xmit+0xb/0x10 > [ 343.080804] [] ip_finish_output+0x2cb/0x670 > [ 343.093746] [] ? ip_output+0x54/0xf0 > [ 343.106391] [] ip_output+0x54/0xf0 > [ 343.118683] [] ip_forward_finish+0x71/0x1a0 > [ 343.130901] [] ip_forward+0x1a3/0x440 > [ 343.142829] [] ? lock_is_held+0x8b/0xb0 > [ 343.154346] [] ip_rcv_finish+0x150/0x660 > [ 343.165748] [] ip_rcv+0x22b/0x370 > [ 343.176838] [] ? packet_rcv_spkt+0x42/0x190 > [ 343.187659] [] __netif_receive_skb_core+0x6d2/0x8a0 > [ 343.198209] [] ? __netif_receive_skb_core+0x114/0x8a0 > [ 343.208819] [] ? xen_clocksource_read+0x20/0x30 > [ 343.219471] [] ? getnstimeofday+0x9/0x30 > [ 343.229862] [] __netif_receive_skb+0x1c/0x70 > [ 343.239953] [] netif_receive_skb_internal+0x1e/0xf0 > [ 343.249908] [] napi_gro_receive+0x70/0xa0 > [ 343.259509] [] rtl8169_poll+0x2d3/0x680 > [ 343.268982] [] ? _raw_spin_unlock_irq+0x2b/0x50 > [ 343.278091] [] net_rx_action+0x161/0x260 > [ 343.287056] [] __do_softirq+0x12c/0x280 > [ 343.295756] [] irq_exit+0xa2/0xd0 > [ 343.304235] [] xen_evtchn_do_upcall+0x2f/0x40 > [ 343.312387] [] xen_do_hypervisor_callback+0x1e/0x30 > [ 343.320389][] ? xen_hypercall_sched_op+0xa/0x20 > [ 343.328171] [] ? xen_hypercall_sched_op+0xa/0x20 > [ 343.335738] [] ? xen_safe_halt+0x10/0x20 > [ 343.343142] [] ? default_idle+0x18/0x20 > [ 343.350202] [] ? arch_cpu_idle+0x2e/0x40 > [ 343.356994] [] ? cpu_startup_entry+0x91/0x1e0 > [ 343.363658] [] ? rest_init+0xb7/0xc0 > [ 343.369924] [] ? csum_partial_copy_generic+0x170/0x170 > [ 343.376057] [] ? start_kernel+0x409/0x416 > [ 343.381972] [] ? repair_env_string+0x5e/0x5e > [ 343.387573] [] ? x86_64_start_reservations+0x2a/0x2c > [ 343.393152] [] ? xen_start_kernel+0x586/0x588 > [ 343.398628] ---[ end trace 8379b598fb7ef5ee ]--- > > > > > > Thursday, February 6, 2014, 12:36:31 PM, you wrote: > >> Hi Dan / Francois, > >> Didn't have time to test it before, but the patch doesn't seem to help. >> I'm still getting the "DMA-API: exceeded 7 overlapping mappings of pfn >> 55ebe", >> but i see now i forgot to mention i use r8169.use_dac=1 ... > >> Not using it seems to prevent the warning, but before 3.14 i have never seen >> this (with r8169.use_dac=1) If you are still hitting this with the patch: 59f2e7df574c dma-debug: fix overlap detection ...then I'm more inclined to think it is an actual positive report. If you don't mind I'll send some debug patches to narrow this down. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.14-mw regression: rtl8169 WARNING: DMA-API: exceeded 7 overlapping mappings of pfn 55ebe
Hmm ok that last message was false .. sorry for that .. it did happen again without r8169.use_dac=1, it just doesn't seem to happen all the time... Konrad / Wei, do you happen to know of any xen related change that went into 3.14 merge window that relates to dma / xen networking ? -- Sander complete stacktrace: [ 342.710738] [ cut here ] [ 342.726890] WARNING: CPU: 0 PID: 0 at lib/dma-debug.c:491 add_dma_entry+0x105/0x130() [ 342.743210] DMA-API: exceeded 7 overlapping mappings of pfn 40b00 [ 342.759510] Modules linked in: [ 342.775557] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.14.0-rc1-20140206-pcireset-net-btrevert+ #1 [ 342.791706] Hardware name: MSI MS-7640/890FXA-GD70 (MS-7640) , BIOS V1.8B1 09/13/2010 [ 342.807627] 0009 88005f603828 81ad29fc 822134e0 [ 342.823430] 88005f603878 88005f603868 810bdf62 8800 [ 342.839081] 00040b00 ffef 822102e0 8800592b9098 [ 342.854572] Call Trace: [ 342.869748][] dump_stack+0x46/0x58 [ 342.884915] [] warn_slowpath_common+0x82/0xb0 [ 342.899710] [] warn_slowpath_fmt+0x41/0x50 [ 342.914395] [] ? active_pfn_read_overlap+0x3a/0x70 [ 342.929166] [] add_dma_entry+0x105/0x130 [ 342.943733] [] debug_dma_map_page+0x126/0x150 [ 342.957988] [] rtl8169_start_xmit+0x216/0xa20 [ 342.972306] [] ? dev_queue_xmit_nit+0x1ef/0x260 [ 342.986523] [] ? dev_loopback_xmit+0x1e0/0x1e0 [ 343.000689] [] dev_hard_start_xmit+0x2e6/0x4a0 [ 343.014466] [] sch_direct_xmit+0xfe/0x280 [ 343.028052] [] __dev_queue_xmit+0x23c/0x630 [ 343.041338] [] ? dev_hard_start_xmit+0x4a0/0x4a0 [ 343.054483] [] ? ip_output+0x54/0xf0 [ 343.067659] [] dev_queue_xmit+0xb/0x10 [ 343.080804] [] ip_finish_output+0x2cb/0x670 [ 343.093746] [] ? ip_output+0x54/0xf0 [ 343.106391] [] ip_output+0x54/0xf0 [ 343.118683] [] ip_forward_finish+0x71/0x1a0 [ 343.130901] [] ip_forward+0x1a3/0x440 [ 343.142829] [] ? lock_is_held+0x8b/0xb0 [ 343.154346] [] ip_rcv_finish+0x150/0x660 [ 343.165748] [] ip_rcv+0x22b/0x370 [ 343.176838] [] ? packet_rcv_spkt+0x42/0x190 [ 343.187659] [] __netif_receive_skb_core+0x6d2/0x8a0 [ 343.198209] [] ? __netif_receive_skb_core+0x114/0x8a0 [ 343.208819] [] ? xen_clocksource_read+0x20/0x30 [ 343.219471] [] ? getnstimeofday+0x9/0x30 [ 343.229862] [] __netif_receive_skb+0x1c/0x70 [ 343.239953] [] netif_receive_skb_internal+0x1e/0xf0 [ 343.249908] [] napi_gro_receive+0x70/0xa0 [ 343.259509] [] rtl8169_poll+0x2d3/0x680 [ 343.268982] [] ? _raw_spin_unlock_irq+0x2b/0x50 [ 343.278091] [] net_rx_action+0x161/0x260 [ 343.287056] [] __do_softirq+0x12c/0x280 [ 343.295756] [] irq_exit+0xa2/0xd0 [ 343.304235] [] xen_evtchn_do_upcall+0x2f/0x40 [ 343.312387] [] xen_do_hypervisor_callback+0x1e/0x30 [ 343.320389][] ? xen_hypercall_sched_op+0xa/0x20 [ 343.328171] [] ? xen_hypercall_sched_op+0xa/0x20 [ 343.335738] [] ? xen_safe_halt+0x10/0x20 [ 343.343142] [] ? default_idle+0x18/0x20 [ 343.350202] [] ? arch_cpu_idle+0x2e/0x40 [ 343.356994] [] ? cpu_startup_entry+0x91/0x1e0 [ 343.363658] [] ? rest_init+0xb7/0xc0 [ 343.369924] [] ? csum_partial_copy_generic+0x170/0x170 [ 343.376057] [] ? start_kernel+0x409/0x416 [ 343.381972] [] ? repair_env_string+0x5e/0x5e [ 343.387573] [] ? x86_64_start_reservations+0x2a/0x2c [ 343.393152] [] ? xen_start_kernel+0x586/0x588 [ 343.398628] ---[ end trace 8379b598fb7ef5ee ]--- Thursday, February 6, 2014, 12:36:31 PM, you wrote: > Hi Dan / Francois, > Didn't have time to test it before, but the patch doesn't seem to help. > I'm still getting the "DMA-API: exceeded 7 overlapping mappings of pfn 55ebe", > but i see now i forgot to mention i use r8169.use_dac=1 ... > Not using it seems to prevent the warning, but before 3.14 i have never seen > this (with r8169.use_dac=1) > -- > Sander > Wednesday, January 29, 2014, 4:06:24 AM, you wrote: >> On Sun, Jan 26, 2014 at 4:03 PM, Francois Romieu >> wrote: >>> Sander Eikelenboom : >>> [...] I have got a regression with a 3.14-mw kernel (last commit is 4ba9920e5e9c0e16b5ed24292d45322907bb9035): It looks like it's related to the rtl8169 ... -- Sander Jan 26 11:36:26 serveerstertje kernel: [ 89.105537] [ cut here ] Jan 26 11:36:26 serveerstertje kernel: [ 89.116779] WARNING: CPU: 0 PID: 0 at lib/dma-debug.c:491 add_dma_entry+0x103/0x130() Jan 26 11:36:26 serveerstertje kernel: [ 89.128148] DMA-API: exceeded 7 overlapping mappings of pfn 55ebe Jan 26 11:36:26 serveerstertje kernel: [ 89.139397] Modules linked in: Jan 26 11:36:26 serveerstertje kernel: [ 89.150535] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.13.0-20140125-mw-pcireset+ #1 Jan 26 11:36:26 serveerstertje kernel: [ 89.161784] Hardware name: MSI MS-7640/890FXA-GD70 (MS-7640) , BIOS V1.8B1 09/13/2010 Jan
Re: 3.14-mw regression: rtl8169 WARNING: DMA-API: exceeded 7 overlapping mappings of pfn 55ebe
Hi Dan / Francois, Didn't have time to test it before, but the patch doesn't seem to help. I'm still getting the "DMA-API: exceeded 7 overlapping mappings of pfn 55ebe", but i see now i forgot to mention i use r8169.use_dac=1 ... Not using it seems to prevent the warning, but before 3.14 i have never seen this (with r8169.use_dac=1) -- Sander Wednesday, January 29, 2014, 4:06:24 AM, you wrote: > On Sun, Jan 26, 2014 at 4:03 PM, Francois Romieu wrote: >> Sander Eikelenboom : >> [...] >>> I have got a regression with a 3.14-mw kernel (last commit is >>> 4ba9920e5e9c0e16b5ed24292d45322907bb9035): >>> It looks like it's related to the rtl8169 ... >>> >>> -- >>> Sander >>> >>> Jan 26 11:36:26 serveerstertje kernel: [ 89.105537] [ cut >>> here ] >>> Jan 26 11:36:26 serveerstertje kernel: [ 89.116779] WARNING: CPU: 0 PID: >>> 0 at lib/dma-debug.c:491 add_dma_entry+0x103/0x130() >>> Jan 26 11:36:26 serveerstertje kernel: [ 89.128148] DMA-API: exceeded 7 >>> overlapping mappings of pfn 55ebe >>> Jan 26 11:36:26 serveerstertje kernel: [ 89.139397] Modules linked in: >>> Jan 26 11:36:26 serveerstertje kernel: [ 89.150535] CPU: 0 PID: 0 Comm: >>> swapper/0 Not tainted 3.13.0-20140125-mw-pcireset+ #1 >>> Jan 26 11:36:26 serveerstertje kernel: [ 89.161784] Hardware name: MSI >>> MS-7640/890FXA-GD70 (MS-7640) , BIOS V1.8B1 09/13/2010 >>> Jan 26 11:36:26 serveerstertje kernel: [ 89.172965] 0009 >>> 88005f603838 81acbcfa 822134e0 >>> Jan 26 11:36:26 serveerstertje kernel: [ 89.184156] 88005f603888 >>> 88005f603878 810bdf62 8800 >>> Jan 26 11:36:26 serveerstertje kernel: [ 89.195186] 00055ebe >>> ffef 0200 8800592ea098 >>> Jan 26 11:36:26 serveerstertje kernel: [ 89.206227] Call Trace: >>> Jan 26 11:36:26 serveerstertje kernel: [ 89.217027] >>> [] dump_stack+0x46/0x58 >>> Jan 26 11:36:26 serveerstertje kernel: [ 89.227907] [] >>> warn_slowpath_common+0x82/0xb0 >>> Jan 26 11:36:26 serveerstertje kernel: [ 89.238678] [] >>> warn_slowpath_fmt+0x41/0x50 >>> Jan 26 11:36:26 serveerstertje kernel: [ 89.249336] [] >>> ? active_pfn_read_overlap+0x3a/0x70 >>> Jan 26 11:36:26 serveerstertje kernel: [ 89.259904] [] >>> add_dma_entry+0x103/0x130 >>> Jan 26 11:36:26 serveerstertje kernel: [ 89.270416] [] >>> debug_dma_map_page+0x126/0x150 >>> Jan 26 11:36:26 serveerstertje kernel: [ 89.280840] [] >>> rtl8169_start_xmit+0x216/0xa20 >> [r8169 and xen stuff] >> >> Dan, I miss the part of the debug code that tells where the mappings were >> previously set. > In this case it was a facepalm mistake on my part. The mappings were > not being properly accounted in the last revision of the patch I sent. > I copied you on the fix [1]. > -- > Dan > [1]: http://marc.info/?l=linux-netdev=139096447627032=2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.14-mw regression: rtl8169 WARNING: DMA-API: exceeded 7 overlapping mappings of pfn 55ebe
Hi Dan / Francois, Didn't have time to test it before, but the patch doesn't seem to help. I'm still getting the DMA-API: exceeded 7 overlapping mappings of pfn 55ebe, but i see now i forgot to mention i use r8169.use_dac=1 ... Not using it seems to prevent the warning, but before 3.14 i have never seen this (with r8169.use_dac=1) -- Sander Wednesday, January 29, 2014, 4:06:24 AM, you wrote: On Sun, Jan 26, 2014 at 4:03 PM, Francois Romieu rom...@fr.zoreil.com wrote: Sander Eikelenboom li...@eikelenboom.it : [...] I have got a regression with a 3.14-mw kernel (last commit is 4ba9920e5e9c0e16b5ed24292d45322907bb9035): It looks like it's related to the rtl8169 ... -- Sander Jan 26 11:36:26 serveerstertje kernel: [ 89.105537] [ cut here ] Jan 26 11:36:26 serveerstertje kernel: [ 89.116779] WARNING: CPU: 0 PID: 0 at lib/dma-debug.c:491 add_dma_entry+0x103/0x130() Jan 26 11:36:26 serveerstertje kernel: [ 89.128148] DMA-API: exceeded 7 overlapping mappings of pfn 55ebe Jan 26 11:36:26 serveerstertje kernel: [ 89.139397] Modules linked in: Jan 26 11:36:26 serveerstertje kernel: [ 89.150535] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.13.0-20140125-mw-pcireset+ #1 Jan 26 11:36:26 serveerstertje kernel: [ 89.161784] Hardware name: MSI MS-7640/890FXA-GD70 (MS-7640) , BIOS V1.8B1 09/13/2010 Jan 26 11:36:26 serveerstertje kernel: [ 89.172965] 0009 88005f603838 81acbcfa 822134e0 Jan 26 11:36:26 serveerstertje kernel: [ 89.184156] 88005f603888 88005f603878 810bdf62 8800 Jan 26 11:36:26 serveerstertje kernel: [ 89.195186] 00055ebe ffef 0200 8800592ea098 Jan 26 11:36:26 serveerstertje kernel: [ 89.206227] Call Trace: Jan 26 11:36:26 serveerstertje kernel: [ 89.217027] IRQ [81acbcfa] dump_stack+0x46/0x58 Jan 26 11:36:26 serveerstertje kernel: [ 89.227907] [810bdf62] warn_slowpath_common+0x82/0xb0 Jan 26 11:36:26 serveerstertje kernel: [ 89.238678] [810be031] warn_slowpath_fmt+0x41/0x50 Jan 26 11:36:26 serveerstertje kernel: [ 89.249336] [81471c5a] ? active_pfn_read_overlap+0x3a/0x70 Jan 26 11:36:26 serveerstertje kernel: [ 89.259904] [814729e3] add_dma_entry+0x103/0x130 Jan 26 11:36:26 serveerstertje kernel: [ 89.270416] [81472de6] debug_dma_map_page+0x126/0x150 Jan 26 11:36:26 serveerstertje kernel: [ 89.280840] [81714686] rtl8169_start_xmit+0x216/0xa20 [r8169 and xen stuff] Dan, I miss the part of the debug code that tells where the mappings were previously set. In this case it was a facepalm mistake on my part. The mappings were not being properly accounted in the last revision of the patch I sent. I copied you on the fix [1]. -- Dan [1]: http://marc.info/?l=linux-netdevm=139096447627032w=2 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.14-mw regression: rtl8169 WARNING: DMA-API: exceeded 7 overlapping mappings of pfn 55ebe
Hmm ok that last message was false .. sorry for that .. it did happen again without r8169.use_dac=1, it just doesn't seem to happen all the time... Konrad / Wei, do you happen to know of any xen related change that went into 3.14 merge window that relates to dma / xen networking ? -- Sander complete stacktrace: [ 342.710738] [ cut here ] [ 342.726890] WARNING: CPU: 0 PID: 0 at lib/dma-debug.c:491 add_dma_entry+0x105/0x130() [ 342.743210] DMA-API: exceeded 7 overlapping mappings of pfn 40b00 [ 342.759510] Modules linked in: [ 342.775557] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.14.0-rc1-20140206-pcireset-net-btrevert+ #1 [ 342.791706] Hardware name: MSI MS-7640/890FXA-GD70 (MS-7640) , BIOS V1.8B1 09/13/2010 [ 342.807627] 0009 88005f603828 81ad29fc 822134e0 [ 342.823430] 88005f603878 88005f603868 810bdf62 8800 [ 342.839081] 00040b00 ffef 822102e0 8800592b9098 [ 342.854572] Call Trace: [ 342.869748] IRQ [81ad29fc] dump_stack+0x46/0x58 [ 342.884915] [810bdf62] warn_slowpath_common+0x82/0xb0 [ 342.899710] [810be031] warn_slowpath_fmt+0x41/0x50 [ 342.914395] [8147853a] ? active_pfn_read_overlap+0x3a/0x70 [ 342.929166] [814792c5] add_dma_entry+0x105/0x130 [ 342.943733] [814796c6] debug_dma_map_page+0x126/0x150 [ 342.957988] [8171c8b6] rtl8169_start_xmit+0x216/0xa20 [ 342.972306] [8195f08f] ? dev_queue_xmit_nit+0x1ef/0x260 [ 342.986523] [8195eea0] ? dev_loopback_xmit+0x1e0/0x1e0 [ 343.000689] [819631e6] dev_hard_start_xmit+0x2e6/0x4a0 [ 343.014466] [81980f3e] sch_direct_xmit+0xfe/0x280 [ 343.028052] [819635dc] __dev_queue_xmit+0x23c/0x630 [ 343.041338] [819633a0] ? dev_hard_start_xmit+0x4a0/0x4a0 [ 343.054483] [81a0a334] ? ip_output+0x54/0xf0 [ 343.067659] [819639eb] dev_queue_xmit+0xb/0x10 [ 343.080804] [81a0890b] ip_finish_output+0x2cb/0x670 [ 343.093746] [81a0a334] ? ip_output+0x54/0xf0 [ 343.106391] [81a0a334] ip_output+0x54/0xf0 [ 343.118683] [81a05791] ip_forward_finish+0x71/0x1a0 [ 343.130901] [81a05a63] ip_forward+0x1a3/0x440 [ 343.142829] [810ffebb] ? lock_is_held+0x8b/0xb0 [ 343.154346] [81a035c0] ip_rcv_finish+0x150/0x660 [ 343.165748] [81a0406b] ip_rcv+0x22b/0x370 [ 343.176838] [81a60972] ? packet_rcv_spkt+0x42/0x190 [ 343.187659] [819609d2] __netif_receive_skb_core+0x6d2/0x8a0 [ 343.198209] [81960414] ? __netif_receive_skb_core+0x114/0x8a0 [ 343.208819] [81009010] ? xen_clocksource_read+0x20/0x30 [ 343.219471] [81116e49] ? getnstimeofday+0x9/0x30 [ 343.229862] [81960bbc] __netif_receive_skb+0x1c/0x70 [ 343.239953] [81960c2e] netif_receive_skb_internal+0x1e/0xf0 [ 343.249908] [81962110] napi_gro_receive+0x70/0xa0 [ 343.259509] [817198a3] rtl8169_poll+0x2d3/0x680 [ 343.268982] [81adcd2b] ? _raw_spin_unlock_irq+0x2b/0x50 [ 343.278091] [819610d1] net_rx_action+0x161/0x260 [ 343.287056] [810c28ec] __do_softirq+0x12c/0x280 [ 343.295756] [810c2da2] irq_exit+0xa2/0xd0 [ 343.304235] [814ffd5f] xen_evtchn_do_upcall+0x2f/0x40 [ 343.312387] [81adf15e] xen_do_hypervisor_callback+0x1e/0x30 [ 343.320389] EOI [810013aa] ? xen_hypercall_sched_op+0xa/0x20 [ 343.328171] [810013aa] ? xen_hypercall_sched_op+0xa/0x20 [ 343.335738] [81008c70] ? xen_safe_halt+0x10/0x20 [ 343.343142] [81018748] ? default_idle+0x18/0x20 [ 343.350202] [81018f5e] ? arch_cpu_idle+0x2e/0x40 [ 343.356994] [8110b551] ? cpu_startup_entry+0x91/0x1e0 [ 343.363658] [81ac7d87] ? rest_init+0xb7/0xc0 [ 343.369924] [81ac7cd0] ? csum_partial_copy_generic+0x170/0x170 [ 343.376057] [8230ff1c] ? start_kernel+0x409/0x416 [ 343.381972] [8230f912] ? repair_env_string+0x5e/0x5e [ 343.387573] [8230f5f8] ? x86_64_start_reservations+0x2a/0x2c [ 343.393152] [82312e28] ? xen_start_kernel+0x586/0x588 [ 343.398628] ---[ end trace 8379b598fb7ef5ee ]--- Thursday, February 6, 2014, 12:36:31 PM, you wrote: Hi Dan / Francois, Didn't have time to test it before, but the patch doesn't seem to help. I'm still getting the DMA-API: exceeded 7 overlapping mappings of pfn 55ebe, but i see now i forgot to mention i use r8169.use_dac=1 ... Not using it seems to prevent the warning, but before 3.14 i have never seen this (with r8169.use_dac=1) -- Sander Wednesday, January 29, 2014, 4:06:24 AM, you wrote: On Sun, Jan 26, 2014 at 4:03 PM, Francois Romieu rom...@fr.zoreil.com wrote: Sander Eikelenboom li...@eikelenboom.it : [...] I have got a regression with a 3.14-mw kernel (last commit is
Re: 3.14-mw regression: rtl8169 WARNING: DMA-API: exceeded 7 overlapping mappings of pfn 55ebe
On Thu, Feb 6, 2014 at 5:09 AM, Sander Eikelenboom li...@eikelenboom.it wrote: Hmm ok that last message was false .. sorry for that .. it did happen again without r8169.use_dac=1, it just doesn't seem to happen all the time... Konrad / Wei, do you happen to know of any xen related change that went into 3.14 merge window that relates to dma / xen networking ? -- Sander complete stacktrace: [ 342.710738] [ cut here ] [ 342.726890] WARNING: CPU: 0 PID: 0 at lib/dma-debug.c:491 add_dma_entry+0x105/0x130() [ 342.743210] DMA-API: exceeded 7 overlapping mappings of pfn 40b00 [ 342.759510] Modules linked in: [ 342.775557] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.14.0-rc1-20140206-pcireset-net-btrevert+ #1 [ 342.791706] Hardware name: MSI MS-7640/890FXA-GD70 (MS-7640) , BIOS V1.8B1 09/13/2010 [ 342.807627] 0009 88005f603828 81ad29fc 822134e0 [ 342.823430] 88005f603878 88005f603868 810bdf62 8800 [ 342.839081] 00040b00 ffef 822102e0 8800592b9098 [ 342.854572] Call Trace: [ 342.869748] IRQ [81ad29fc] dump_stack+0x46/0x58 [ 342.884915] [810bdf62] warn_slowpath_common+0x82/0xb0 [ 342.899710] [810be031] warn_slowpath_fmt+0x41/0x50 [ 342.914395] [8147853a] ? active_pfn_read_overlap+0x3a/0x70 [ 342.929166] [814792c5] add_dma_entry+0x105/0x130 [ 342.943733] [814796c6] debug_dma_map_page+0x126/0x150 [ 342.957988] [8171c8b6] rtl8169_start_xmit+0x216/0xa20 [ 342.972306] [8195f08f] ? dev_queue_xmit_nit+0x1ef/0x260 [ 342.986523] [8195eea0] ? dev_loopback_xmit+0x1e0/0x1e0 [ 343.000689] [819631e6] dev_hard_start_xmit+0x2e6/0x4a0 [ 343.014466] [81980f3e] sch_direct_xmit+0xfe/0x280 [ 343.028052] [819635dc] __dev_queue_xmit+0x23c/0x630 [ 343.041338] [819633a0] ? dev_hard_start_xmit+0x4a0/0x4a0 [ 343.054483] [81a0a334] ? ip_output+0x54/0xf0 [ 343.067659] [819639eb] dev_queue_xmit+0xb/0x10 [ 343.080804] [81a0890b] ip_finish_output+0x2cb/0x670 [ 343.093746] [81a0a334] ? ip_output+0x54/0xf0 [ 343.106391] [81a0a334] ip_output+0x54/0xf0 [ 343.118683] [81a05791] ip_forward_finish+0x71/0x1a0 [ 343.130901] [81a05a63] ip_forward+0x1a3/0x440 [ 343.142829] [810ffebb] ? lock_is_held+0x8b/0xb0 [ 343.154346] [81a035c0] ip_rcv_finish+0x150/0x660 [ 343.165748] [81a0406b] ip_rcv+0x22b/0x370 [ 343.176838] [81a60972] ? packet_rcv_spkt+0x42/0x190 [ 343.187659] [819609d2] __netif_receive_skb_core+0x6d2/0x8a0 [ 343.198209] [81960414] ? __netif_receive_skb_core+0x114/0x8a0 [ 343.208819] [81009010] ? xen_clocksource_read+0x20/0x30 [ 343.219471] [81116e49] ? getnstimeofday+0x9/0x30 [ 343.229862] [81960bbc] __netif_receive_skb+0x1c/0x70 [ 343.239953] [81960c2e] netif_receive_skb_internal+0x1e/0xf0 [ 343.249908] [81962110] napi_gro_receive+0x70/0xa0 [ 343.259509] [817198a3] rtl8169_poll+0x2d3/0x680 [ 343.268982] [81adcd2b] ? _raw_spin_unlock_irq+0x2b/0x50 [ 343.278091] [819610d1] net_rx_action+0x161/0x260 [ 343.287056] [810c28ec] __do_softirq+0x12c/0x280 [ 343.295756] [810c2da2] irq_exit+0xa2/0xd0 [ 343.304235] [814ffd5f] xen_evtchn_do_upcall+0x2f/0x40 [ 343.312387] [81adf15e] xen_do_hypervisor_callback+0x1e/0x30 [ 343.320389] EOI [810013aa] ? xen_hypercall_sched_op+0xa/0x20 [ 343.328171] [810013aa] ? xen_hypercall_sched_op+0xa/0x20 [ 343.335738] [81008c70] ? xen_safe_halt+0x10/0x20 [ 343.343142] [81018748] ? default_idle+0x18/0x20 [ 343.350202] [81018f5e] ? arch_cpu_idle+0x2e/0x40 [ 343.356994] [8110b551] ? cpu_startup_entry+0x91/0x1e0 [ 343.363658] [81ac7d87] ? rest_init+0xb7/0xc0 [ 343.369924] [81ac7cd0] ? csum_partial_copy_generic+0x170/0x170 [ 343.376057] [8230ff1c] ? start_kernel+0x409/0x416 [ 343.381972] [8230f912] ? repair_env_string+0x5e/0x5e [ 343.387573] [8230f5f8] ? x86_64_start_reservations+0x2a/0x2c [ 343.393152] [82312e28] ? xen_start_kernel+0x586/0x588 [ 343.398628] ---[ end trace 8379b598fb7ef5ee ]--- Thursday, February 6, 2014, 12:36:31 PM, you wrote: Hi Dan / Francois, Didn't have time to test it before, but the patch doesn't seem to help. I'm still getting the DMA-API: exceeded 7 overlapping mappings of pfn 55ebe, but i see now i forgot to mention i use r8169.use_dac=1 ... Not using it seems to prevent the warning, but before 3.14 i have never seen this (with r8169.use_dac=1) If you are still hitting this with the patch: 59f2e7df574c dma-debug: fix overlap detection ...then I'm more inclined to think it is an
Re: 3.14-mw regression: rtl8169 WARNING: DMA-API: exceeded 7 overlapping mappings of pfn 55ebe
Thursday, February 6, 2014, 3:26:09 PM, you wrote: On Thu, Feb 6, 2014 at 5:09 AM, Sander Eikelenboom li...@eikelenboom.it wrote: Hmm ok that last message was false .. sorry for that .. it did happen again without r8169.use_dac=1, it just doesn't seem to happen all the time... Konrad / Wei, do you happen to know of any xen related change that went into 3.14 merge window that relates to dma / xen networking ? -- Sander complete stacktrace: [ 342.710738] [ cut here ] [ 342.726890] WARNING: CPU: 0 PID: 0 at lib/dma-debug.c:491 add_dma_entry+0x105/0x130() [ 342.743210] DMA-API: exceeded 7 overlapping mappings of pfn 40b00 [ 342.759510] Modules linked in: [ 342.775557] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.14.0-rc1-20140206-pcireset-net-btrevert+ #1 [ 342.791706] Hardware name: MSI MS-7640/890FXA-GD70 (MS-7640) , BIOS V1.8B1 09/13/2010 [ 342.807627] 0009 88005f603828 81ad29fc 822134e0 [ 342.823430] 88005f603878 88005f603868 810bdf62 8800 [ 342.839081] 00040b00 ffef 822102e0 8800592b9098 [ 342.854572] Call Trace: [ 342.869748] IRQ [81ad29fc] dump_stack+0x46/0x58 [ 342.884915] [810bdf62] warn_slowpath_common+0x82/0xb0 [ 342.899710] [810be031] warn_slowpath_fmt+0x41/0x50 [ 342.914395] [8147853a] ? active_pfn_read_overlap+0x3a/0x70 [ 342.929166] [814792c5] add_dma_entry+0x105/0x130 [ 342.943733] [814796c6] debug_dma_map_page+0x126/0x150 [ 342.957988] [8171c8b6] rtl8169_start_xmit+0x216/0xa20 [ 342.972306] [8195f08f] ? dev_queue_xmit_nit+0x1ef/0x260 [ 342.986523] [8195eea0] ? dev_loopback_xmit+0x1e0/0x1e0 [ 343.000689] [819631e6] dev_hard_start_xmit+0x2e6/0x4a0 [ 343.014466] [81980f3e] sch_direct_xmit+0xfe/0x280 [ 343.028052] [819635dc] __dev_queue_xmit+0x23c/0x630 [ 343.041338] [819633a0] ? dev_hard_start_xmit+0x4a0/0x4a0 [ 343.054483] [81a0a334] ? ip_output+0x54/0xf0 [ 343.067659] [819639eb] dev_queue_xmit+0xb/0x10 [ 343.080804] [81a0890b] ip_finish_output+0x2cb/0x670 [ 343.093746] [81a0a334] ? ip_output+0x54/0xf0 [ 343.106391] [81a0a334] ip_output+0x54/0xf0 [ 343.118683] [81a05791] ip_forward_finish+0x71/0x1a0 [ 343.130901] [81a05a63] ip_forward+0x1a3/0x440 [ 343.142829] [810ffebb] ? lock_is_held+0x8b/0xb0 [ 343.154346] [81a035c0] ip_rcv_finish+0x150/0x660 [ 343.165748] [81a0406b] ip_rcv+0x22b/0x370 [ 343.176838] [81a60972] ? packet_rcv_spkt+0x42/0x190 [ 343.187659] [819609d2] __netif_receive_skb_core+0x6d2/0x8a0 [ 343.198209] [81960414] ? __netif_receive_skb_core+0x114/0x8a0 [ 343.208819] [81009010] ? xen_clocksource_read+0x20/0x30 [ 343.219471] [81116e49] ? getnstimeofday+0x9/0x30 [ 343.229862] [81960bbc] __netif_receive_skb+0x1c/0x70 [ 343.239953] [81960c2e] netif_receive_skb_internal+0x1e/0xf0 [ 343.249908] [81962110] napi_gro_receive+0x70/0xa0 [ 343.259509] [817198a3] rtl8169_poll+0x2d3/0x680 [ 343.268982] [81adcd2b] ? _raw_spin_unlock_irq+0x2b/0x50 [ 343.278091] [819610d1] net_rx_action+0x161/0x260 [ 343.287056] [810c28ec] __do_softirq+0x12c/0x280 [ 343.295756] [810c2da2] irq_exit+0xa2/0xd0 [ 343.304235] [814ffd5f] xen_evtchn_do_upcall+0x2f/0x40 [ 343.312387] [81adf15e] xen_do_hypervisor_callback+0x1e/0x30 [ 343.320389] EOI [810013aa] ? xen_hypercall_sched_op+0xa/0x20 [ 343.328171] [810013aa] ? xen_hypercall_sched_op+0xa/0x20 [ 343.335738] [81008c70] ? xen_safe_halt+0x10/0x20 [ 343.343142] [81018748] ? default_idle+0x18/0x20 [ 343.350202] [81018f5e] ? arch_cpu_idle+0x2e/0x40 [ 343.356994] [8110b551] ? cpu_startup_entry+0x91/0x1e0 [ 343.363658] [81ac7d87] ? rest_init+0xb7/0xc0 [ 343.369924] [81ac7cd0] ? csum_partial_copy_generic+0x170/0x170 [ 343.376057] [8230ff1c] ? start_kernel+0x409/0x416 [ 343.381972] [8230f912] ? repair_env_string+0x5e/0x5e [ 343.387573] [8230f5f8] ? x86_64_start_reservations+0x2a/0x2c [ 343.393152] [82312e28] ? xen_start_kernel+0x586/0x588 [ 343.398628] ---[ end trace 8379b598fb7ef5ee ]--- Thursday, February 6, 2014, 12:36:31 PM, you wrote: Hi Dan / Francois, Didn't have time to test it before, but the patch doesn't seem to help. I'm still getting the DMA-API: exceeded 7 overlapping mappings of pfn 55ebe, but i see now i forgot to mention i use r8169.use_dac=1 ... Not using it seems to prevent the warning, but before 3.14 i have never seen this (with r8169.use_dac=1) If you are still hitting this with the patch: 59f2e7df574c dma-debug: fix
Re: 3.14-mw regression: rtl8169 WARNING: DMA-API: exceeded 7 overlapping mappings of pfn 55ebe
On Thu, Feb 6, 2014 at 6:27 AM, Sander Eikelenboom li...@eikelenboom.it wrote: Not using it seems to prevent the warning, but before 3.14 i have never seen this (with r8169.use_dac=1) If you are still hitting this with the patch: 59f2e7df574c dma-debug: fix overlap detection ...then I'm more inclined to think it is an actual positive report. If you don't mind I'll send some debug patches to narrow this down. Please do .. sounds better than bisecting :-) Hi, attached is a patch that should give some insight whether the driver is triggering many overlapping mappings. Try it on top of 3.14-rc1. Thank you for the debug help! debug-overlap Description: Binary data
Re: 3.14-mw regression: rtl8169 WARNING: DMA-API: exceeded 7 overlapping mappings of pfn 55ebe
On Sun, Jan 26, 2014 at 4:03 PM, Francois Romieu wrote: > Sander Eikelenboom : > [...] >> I have got a regression with a 3.14-mw kernel (last commit is >> 4ba9920e5e9c0e16b5ed24292d45322907bb9035): >> It looks like it's related to the rtl8169 ... >> >> -- >> Sander >> >> Jan 26 11:36:26 serveerstertje kernel: [ 89.105537] [ cut here >> ] >> Jan 26 11:36:26 serveerstertje kernel: [ 89.116779] WARNING: CPU: 0 PID: 0 >> at lib/dma-debug.c:491 add_dma_entry+0x103/0x130() >> Jan 26 11:36:26 serveerstertje kernel: [ 89.128148] DMA-API: exceeded 7 >> overlapping mappings of pfn 55ebe >> Jan 26 11:36:26 serveerstertje kernel: [ 89.139397] Modules linked in: >> Jan 26 11:36:26 serveerstertje kernel: [ 89.150535] CPU: 0 PID: 0 Comm: >> swapper/0 Not tainted 3.13.0-20140125-mw-pcireset+ #1 >> Jan 26 11:36:26 serveerstertje kernel: [ 89.161784] Hardware name: MSI >> MS-7640/890FXA-GD70 (MS-7640) , BIOS V1.8B1 09/13/2010 >> Jan 26 11:36:26 serveerstertje kernel: [ 89.172965] 0009 >> 88005f603838 81acbcfa 822134e0 >> Jan 26 11:36:26 serveerstertje kernel: [ 89.184156] 88005f603888 >> 88005f603878 810bdf62 8800 >> Jan 26 11:36:26 serveerstertje kernel: [ 89.195186] 00055ebe >> ffef 0200 8800592ea098 >> Jan 26 11:36:26 serveerstertje kernel: [ 89.206227] Call Trace: >> Jan 26 11:36:26 serveerstertje kernel: [ 89.217027] >> [] dump_stack+0x46/0x58 >> Jan 26 11:36:26 serveerstertje kernel: [ 89.227907] [] >> warn_slowpath_common+0x82/0xb0 >> Jan 26 11:36:26 serveerstertje kernel: [ 89.238678] [] >> warn_slowpath_fmt+0x41/0x50 >> Jan 26 11:36:26 serveerstertje kernel: [ 89.249336] [] >> ? active_pfn_read_overlap+0x3a/0x70 >> Jan 26 11:36:26 serveerstertje kernel: [ 89.259904] [] >> add_dma_entry+0x103/0x130 >> Jan 26 11:36:26 serveerstertje kernel: [ 89.270416] [] >> debug_dma_map_page+0x126/0x150 >> Jan 26 11:36:26 serveerstertje kernel: [ 89.280840] [] >> rtl8169_start_xmit+0x216/0xa20 > [r8169 and xen stuff] > > Dan, I miss the part of the debug code that tells where the mappings were > previously set. In this case it was a facepalm mistake on my part. The mappings were not being properly accounted in the last revision of the patch I sent. I copied you on the fix [1]. -- Dan [1]: http://marc.info/?l=linux-netdev=139096447627032=2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.14-mw regression: rtl8169 WARNING: DMA-API: exceeded 7 overlapping mappings of pfn 55ebe
On Sun, Jan 26, 2014 at 4:03 PM, Francois Romieu rom...@fr.zoreil.com wrote: Sander Eikelenboom li...@eikelenboom.it : [...] I have got a regression with a 3.14-mw kernel (last commit is 4ba9920e5e9c0e16b5ed24292d45322907bb9035): It looks like it's related to the rtl8169 ... -- Sander Jan 26 11:36:26 serveerstertje kernel: [ 89.105537] [ cut here ] Jan 26 11:36:26 serveerstertje kernel: [ 89.116779] WARNING: CPU: 0 PID: 0 at lib/dma-debug.c:491 add_dma_entry+0x103/0x130() Jan 26 11:36:26 serveerstertje kernel: [ 89.128148] DMA-API: exceeded 7 overlapping mappings of pfn 55ebe Jan 26 11:36:26 serveerstertje kernel: [ 89.139397] Modules linked in: Jan 26 11:36:26 serveerstertje kernel: [ 89.150535] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.13.0-20140125-mw-pcireset+ #1 Jan 26 11:36:26 serveerstertje kernel: [ 89.161784] Hardware name: MSI MS-7640/890FXA-GD70 (MS-7640) , BIOS V1.8B1 09/13/2010 Jan 26 11:36:26 serveerstertje kernel: [ 89.172965] 0009 88005f603838 81acbcfa 822134e0 Jan 26 11:36:26 serveerstertje kernel: [ 89.184156] 88005f603888 88005f603878 810bdf62 8800 Jan 26 11:36:26 serveerstertje kernel: [ 89.195186] 00055ebe ffef 0200 8800592ea098 Jan 26 11:36:26 serveerstertje kernel: [ 89.206227] Call Trace: Jan 26 11:36:26 serveerstertje kernel: [ 89.217027] IRQ [81acbcfa] dump_stack+0x46/0x58 Jan 26 11:36:26 serveerstertje kernel: [ 89.227907] [810bdf62] warn_slowpath_common+0x82/0xb0 Jan 26 11:36:26 serveerstertje kernel: [ 89.238678] [810be031] warn_slowpath_fmt+0x41/0x50 Jan 26 11:36:26 serveerstertje kernel: [ 89.249336] [81471c5a] ? active_pfn_read_overlap+0x3a/0x70 Jan 26 11:36:26 serveerstertje kernel: [ 89.259904] [814729e3] add_dma_entry+0x103/0x130 Jan 26 11:36:26 serveerstertje kernel: [ 89.270416] [81472de6] debug_dma_map_page+0x126/0x150 Jan 26 11:36:26 serveerstertje kernel: [ 89.280840] [81714686] rtl8169_start_xmit+0x216/0xa20 [r8169 and xen stuff] Dan, I miss the part of the debug code that tells where the mappings were previously set. In this case it was a facepalm mistake on my part. The mappings were not being properly accounted in the last revision of the patch I sent. I copied you on the fix [1]. -- Dan [1]: http://marc.info/?l=linux-netdevm=139096447627032w=2 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.14-mw regression: rtl8169 WARNING: DMA-API: exceeded 7 overlapping mappings of pfn 55ebe
Sander Eikelenboom : [...] > I have got a regression with a 3.14-mw kernel (last commit is > 4ba9920e5e9c0e16b5ed24292d45322907bb9035): > It looks like it's related to the rtl8169 ... > > -- > Sander > > Jan 26 11:36:26 serveerstertje kernel: [ 89.105537] [ cut here > ] > Jan 26 11:36:26 serveerstertje kernel: [ 89.116779] WARNING: CPU: 0 PID: 0 > at lib/dma-debug.c:491 add_dma_entry+0x103/0x130() > Jan 26 11:36:26 serveerstertje kernel: [ 89.128148] DMA-API: exceeded 7 > overlapping mappings of pfn 55ebe > Jan 26 11:36:26 serveerstertje kernel: [ 89.139397] Modules linked in: > Jan 26 11:36:26 serveerstertje kernel: [ 89.150535] CPU: 0 PID: 0 Comm: > swapper/0 Not tainted 3.13.0-20140125-mw-pcireset+ #1 > Jan 26 11:36:26 serveerstertje kernel: [ 89.161784] Hardware name: MSI > MS-7640/890FXA-GD70 (MS-7640) , BIOS V1.8B1 09/13/2010 > Jan 26 11:36:26 serveerstertje kernel: [ 89.172965] 0009 > 88005f603838 81acbcfa 822134e0 > Jan 26 11:36:26 serveerstertje kernel: [ 89.184156] 88005f603888 > 88005f603878 810bdf62 8800 > Jan 26 11:36:26 serveerstertje kernel: [ 89.195186] 00055ebe > ffef 0200 8800592ea098 > Jan 26 11:36:26 serveerstertje kernel: [ 89.206227] Call Trace: > Jan 26 11:36:26 serveerstertje kernel: [ 89.217027] > [] dump_stack+0x46/0x58 > Jan 26 11:36:26 serveerstertje kernel: [ 89.227907] [] > warn_slowpath_common+0x82/0xb0 > Jan 26 11:36:26 serveerstertje kernel: [ 89.238678] [] > warn_slowpath_fmt+0x41/0x50 > Jan 26 11:36:26 serveerstertje kernel: [ 89.249336] [] ? > active_pfn_read_overlap+0x3a/0x70 > Jan 26 11:36:26 serveerstertje kernel: [ 89.259904] [] > add_dma_entry+0x103/0x130 > Jan 26 11:36:26 serveerstertje kernel: [ 89.270416] [] > debug_dma_map_page+0x126/0x150 > Jan 26 11:36:26 serveerstertje kernel: [ 89.280840] [] > rtl8169_start_xmit+0x216/0xa20 [r8169 and xen stuff] Dan, I miss the part of the debug code that tells where the mappings were previously set. -- Ueimor -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
3.14-mw regression: rtl8169 WARNING: DMA-API: exceeded 7 overlapping mappings of pfn 55ebe
Hi, I have got a regression with a 3.14-mw kernel (last commit is 4ba9920e5e9c0e16b5ed24292d45322907bb9035): It looks like it's related to the rtl8169 ... -- Sander Jan 26 11:36:26 serveerstertje kernel: [ 89.105537] [ cut here ] Jan 26 11:36:26 serveerstertje kernel: [ 89.116779] WARNING: CPU: 0 PID: 0 at lib/dma-debug.c:491 add_dma_entry+0x103/0x130() Jan 26 11:36:26 serveerstertje kernel: [ 89.128148] DMA-API: exceeded 7 overlapping mappings of pfn 55ebe Jan 26 11:36:26 serveerstertje kernel: [ 89.139397] Modules linked in: Jan 26 11:36:26 serveerstertje kernel: [ 89.150535] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.13.0-20140125-mw-pcireset+ #1 Jan 26 11:36:26 serveerstertje kernel: [ 89.161784] Hardware name: MSI MS-7640/890FXA-GD70 (MS-7640) , BIOS V1.8B1 09/13/2010 Jan 26 11:36:26 serveerstertje kernel: [ 89.172965] 0009 88005f603838 81acbcfa 822134e0 Jan 26 11:36:26 serveerstertje kernel: [ 89.184156] 88005f603888 88005f603878 810bdf62 8800 Jan 26 11:36:26 serveerstertje kernel: [ 89.195186] 00055ebe ffef 0200 8800592ea098 Jan 26 11:36:26 serveerstertje kernel: [ 89.206227] Call Trace: Jan 26 11:36:26 serveerstertje kernel: [ 89.217027] [] dump_stack+0x46/0x58 Jan 26 11:36:26 serveerstertje kernel: [ 89.227907] [] warn_slowpath_common+0x82/0xb0 Jan 26 11:36:26 serveerstertje kernel: [ 89.238678] [] warn_slowpath_fmt+0x41/0x50 Jan 26 11:36:26 serveerstertje kernel: [ 89.249336] [] ? active_pfn_read_overlap+0x3a/0x70 Jan 26 11:36:26 serveerstertje kernel: [ 89.259904] [] add_dma_entry+0x103/0x130 Jan 26 11:36:26 serveerstertje kernel: [ 89.270416] [] debug_dma_map_page+0x126/0x150 Jan 26 11:36:26 serveerstertje kernel: [ 89.280840] [] rtl8169_start_xmit+0x216/0xa20 Jan 26 11:36:26 serveerstertje kernel: [ 89.291073] [] ? __kfree_skb+0x3a/0xb0 Jan 26 11:36:26 serveerstertje kernel: [ 89.301252] [] ? dev_queue_xmit_nit+0x1ef/0x260 Jan 26 11:36:26 serveerstertje kernel: [ 89.311392] [] ? dev_loopback_xmit+0x1e0/0x1e0 Jan 26 11:36:26 serveerstertje kernel: [ 89.321418] [] dev_hard_start_xmit+0x2e6/0x4a0 Jan 26 11:36:26 serveerstertje kernel: [ 89.331236] [] sch_direct_xmit+0xfe/0x280 Jan 26 11:36:26 serveerstertje kernel: [ 89.341013] [] __dev_queue_xmit+0x23c/0x630 Jan 26 11:36:26 serveerstertje kernel: [ 89.350668] [] ? dev_hard_start_xmit+0x4a0/0x4a0 Jan 26 11:36:26 serveerstertje kernel: [ 89.360264] [] ? ip_output+0x54/0xf0 Jan 26 11:36:26 serveerstertje kernel: [ 89.369698] [] dev_queue_xmit+0xb/0x10 Jan 26 11:36:26 serveerstertje kernel: [ 89.379034] [] ip_finish_output+0x2cb/0x670 Jan 26 11:36:26 serveerstertje kernel: [ 89.388373] [] ? ip_output+0x54/0xf0 Jan 26 11:36:26 serveerstertje kernel: [ 89.397498] [] ip_output+0x54/0xf0 Jan 26 11:36:26 serveerstertje kernel: [ 89.406584] [] ip_forward_finish+0x71/0x1a0 Jan 26 11:36:26 serveerstertje kernel: [ 89.415534] [] ip_forward+0x1a3/0x440 Jan 26 11:36:26 serveerstertje kernel: [ 89.424400] [] ip_rcv_finish+0x150/0x650 Jan 26 11:36:26 serveerstertje kernel: [ 89.433108] [] ip_rcv+0x22b/0x370 Jan 26 11:36:26 serveerstertje kernel: [ 89.441737] [] ? packet_rcv_spkt+0x42/0x190 Jan 26 11:36:26 serveerstertje kernel: [ 89.450226] [] __netif_receive_skb_core+0x6d2/0x8a0 Jan 26 11:36:26 serveerstertje kernel: [ 89.458687] [] ? __netif_receive_skb_core+0x114/0x8a0 Jan 26 11:36:26 serveerstertje kernel: [ 89.467109] [] ? xen_clocksource_read+0x20/0x30 Jan 26 11:36:26 serveerstertje kernel: [ 89.475362] [] ? getnstimeofday+0x9/0x30 Jan 26 11:36:26 serveerstertje kernel: [ 89.483548] [] __netif_receive_skb+0x1c/0x70 Jan 26 11:36:26 serveerstertje kernel: [ 89.491608] [] netif_receive_skb_internal+0x1e/0xf0 Jan 26 11:36:26 serveerstertje kernel: [ 89.499596] [] napi_gro_receive+0x70/0xa0 Jan 26 11:36:26 serveerstertje kernel: [ 89.507486] [] rtl8169_poll+0x2d3/0x680 Jan 26 11:36:26 serveerstertje kernel: [ 89.515222] [] net_rx_action+0x161/0x260 Jan 26 11:36:26 serveerstertje kernel: [ 89.523097] [] __do_softirq+0x11d/0x250 Jan 26 11:36:26 serveerstertje kernel: [ 89.530973] [] irq_exit+0xa2/0xd0 Jan 26 11:36:26 serveerstertje kernel: [ 89.538915] [] xen_evtchn_do_upcall+0x2f/0x40 Jan 26 11:36:26 serveerstertje kernel: [ 89.546876] [] xen_do_hypervisor_callback+0x1e/0x30 Jan 26 11:36:26 serveerstertje kernel: [ 89.554591] [] ? xen_hypercall_sched_op+0xa/0x20 Jan 26 11:36:26 serveerstertje kernel: [ 89.562139] [] ? xen_hypercall_sched_op+0xa/0x20 Jan 26 11:36:26 serveerstertje kernel: [ 89.569503] [] ? xen_safe_halt+0x10/0x20 Jan 26 11:36:26 serveerstertje kernel: [ 89.576788] [] ? default_idle+0x18/0x20 Jan 26 11:36:26 serveerstertje kernel: [ 89.583863] [] ? arch_cpu_idle+0x2e/0x40 Jan 26 11:36:26 serveerstertje kernel: [
3.14-mw regression: rtl8169 WARNING: DMA-API: exceeded 7 overlapping mappings of pfn 55ebe
Hi, I have got a regression with a 3.14-mw kernel (last commit is 4ba9920e5e9c0e16b5ed24292d45322907bb9035): It looks like it's related to the rtl8169 ... -- Sander Jan 26 11:36:26 serveerstertje kernel: [ 89.105537] [ cut here ] Jan 26 11:36:26 serveerstertje kernel: [ 89.116779] WARNING: CPU: 0 PID: 0 at lib/dma-debug.c:491 add_dma_entry+0x103/0x130() Jan 26 11:36:26 serveerstertje kernel: [ 89.128148] DMA-API: exceeded 7 overlapping mappings of pfn 55ebe Jan 26 11:36:26 serveerstertje kernel: [ 89.139397] Modules linked in: Jan 26 11:36:26 serveerstertje kernel: [ 89.150535] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.13.0-20140125-mw-pcireset+ #1 Jan 26 11:36:26 serveerstertje kernel: [ 89.161784] Hardware name: MSI MS-7640/890FXA-GD70 (MS-7640) , BIOS V1.8B1 09/13/2010 Jan 26 11:36:26 serveerstertje kernel: [ 89.172965] 0009 88005f603838 81acbcfa 822134e0 Jan 26 11:36:26 serveerstertje kernel: [ 89.184156] 88005f603888 88005f603878 810bdf62 8800 Jan 26 11:36:26 serveerstertje kernel: [ 89.195186] 00055ebe ffef 0200 8800592ea098 Jan 26 11:36:26 serveerstertje kernel: [ 89.206227] Call Trace: Jan 26 11:36:26 serveerstertje kernel: [ 89.217027] IRQ [81acbcfa] dump_stack+0x46/0x58 Jan 26 11:36:26 serveerstertje kernel: [ 89.227907] [810bdf62] warn_slowpath_common+0x82/0xb0 Jan 26 11:36:26 serveerstertje kernel: [ 89.238678] [810be031] warn_slowpath_fmt+0x41/0x50 Jan 26 11:36:26 serveerstertje kernel: [ 89.249336] [81471c5a] ? active_pfn_read_overlap+0x3a/0x70 Jan 26 11:36:26 serveerstertje kernel: [ 89.259904] [814729e3] add_dma_entry+0x103/0x130 Jan 26 11:36:26 serveerstertje kernel: [ 89.270416] [81472de6] debug_dma_map_page+0x126/0x150 Jan 26 11:36:26 serveerstertje kernel: [ 89.280840] [81714686] rtl8169_start_xmit+0x216/0xa20 Jan 26 11:36:26 serveerstertje kernel: [ 89.291073] [8194] ? __kfree_skb+0x3a/0xb0 Jan 26 11:36:26 serveerstertje kernel: [ 89.301252] [81955a3f] ? dev_queue_xmit_nit+0x1ef/0x260 Jan 26 11:36:26 serveerstertje kernel: [ 89.311392] [81955850] ? dev_loopback_xmit+0x1e0/0x1e0 Jan 26 11:36:26 serveerstertje kernel: [ 89.321418] [81959b96] dev_hard_start_xmit+0x2e6/0x4a0 Jan 26 11:36:26 serveerstertje kernel: [ 89.331236] [819778fe] sch_direct_xmit+0xfe/0x280 Jan 26 11:36:26 serveerstertje kernel: [ 89.341013] [81959f8c] __dev_queue_xmit+0x23c/0x630 Jan 26 11:36:26 serveerstertje kernel: [ 89.350668] [81959d50] ? dev_hard_start_xmit+0x4a0/0x4a0 Jan 26 11:36:26 serveerstertje kernel: [ 89.360264] [81a00ce4] ? ip_output+0x54/0xf0 Jan 26 11:36:26 serveerstertje kernel: [ 89.369698] [8195a39b] dev_queue_xmit+0xb/0x10 Jan 26 11:36:26 serveerstertje kernel: [ 89.379034] [819ff2bb] ip_finish_output+0x2cb/0x670 Jan 26 11:36:26 serveerstertje kernel: [ 89.388373] [81a00ce4] ? ip_output+0x54/0xf0 Jan 26 11:36:26 serveerstertje kernel: [ 89.397498] [81a00ce4] ip_output+0x54/0xf0 Jan 26 11:36:26 serveerstertje kernel: [ 89.406584] [819fc141] ip_forward_finish+0x71/0x1a0 Jan 26 11:36:26 serveerstertje kernel: [ 89.415534] [819fc413] ip_forward+0x1a3/0x440 Jan 26 11:36:26 serveerstertje kernel: [ 89.424400] [819f9f80] ip_rcv_finish+0x150/0x650 Jan 26 11:36:26 serveerstertje kernel: [ 89.433108] [819faa1b] ip_rcv+0x22b/0x370 Jan 26 11:36:26 serveerstertje kernel: [ 89.441737] [81a57322] ? packet_rcv_spkt+0x42/0x190 Jan 26 11:36:26 serveerstertje kernel: [ 89.450226] [81957382] __netif_receive_skb_core+0x6d2/0x8a0 Jan 26 11:36:26 serveerstertje kernel: [ 89.458687] [81956dc4] ? __netif_receive_skb_core+0x114/0x8a0 Jan 26 11:36:26 serveerstertje kernel: [ 89.467109] [81008f50] ? xen_clocksource_read+0x20/0x30 Jan 26 11:36:26 serveerstertje kernel: [ 89.475362] [81116e09] ? getnstimeofday+0x9/0x30 Jan 26 11:36:26 serveerstertje kernel: [ 89.483548] [8195756c] __netif_receive_skb+0x1c/0x70 Jan 26 11:36:26 serveerstertje kernel: [ 89.491608] [819575de] netif_receive_skb_internal+0x1e/0xf0 Jan 26 11:36:26 serveerstertje kernel: [ 89.499596] [81958ac0] napi_gro_receive+0x70/0xa0 Jan 26 11:36:26 serveerstertje kernel: [ 89.507486] [81711673] rtl8169_poll+0x2d3/0x680 Jan 26 11:36:26 serveerstertje kernel: [ 89.515222] [81957a81] net_rx_action+0x161/0x260 Jan 26 11:36:26 serveerstertje kernel: [ 89.523097] [810c28dd] __do_softirq+0x11d/0x250 Jan 26 11:36:26 serveerstertje kernel: [ 89.530973] [810c2d72] irq_exit+0xa2/0xd0 Jan 26 11:36:26 serveerstertje kernel: [ 89.538915] [814f94bf] xen_evtchn_do_upcall+0x2f/0x40 Jan 26
Re: 3.14-mw regression: rtl8169 WARNING: DMA-API: exceeded 7 overlapping mappings of pfn 55ebe
Sander Eikelenboom li...@eikelenboom.it : [...] I have got a regression with a 3.14-mw kernel (last commit is 4ba9920e5e9c0e16b5ed24292d45322907bb9035): It looks like it's related to the rtl8169 ... -- Sander Jan 26 11:36:26 serveerstertje kernel: [ 89.105537] [ cut here ] Jan 26 11:36:26 serveerstertje kernel: [ 89.116779] WARNING: CPU: 0 PID: 0 at lib/dma-debug.c:491 add_dma_entry+0x103/0x130() Jan 26 11:36:26 serveerstertje kernel: [ 89.128148] DMA-API: exceeded 7 overlapping mappings of pfn 55ebe Jan 26 11:36:26 serveerstertje kernel: [ 89.139397] Modules linked in: Jan 26 11:36:26 serveerstertje kernel: [ 89.150535] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.13.0-20140125-mw-pcireset+ #1 Jan 26 11:36:26 serveerstertje kernel: [ 89.161784] Hardware name: MSI MS-7640/890FXA-GD70 (MS-7640) , BIOS V1.8B1 09/13/2010 Jan 26 11:36:26 serveerstertje kernel: [ 89.172965] 0009 88005f603838 81acbcfa 822134e0 Jan 26 11:36:26 serveerstertje kernel: [ 89.184156] 88005f603888 88005f603878 810bdf62 8800 Jan 26 11:36:26 serveerstertje kernel: [ 89.195186] 00055ebe ffef 0200 8800592ea098 Jan 26 11:36:26 serveerstertje kernel: [ 89.206227] Call Trace: Jan 26 11:36:26 serveerstertje kernel: [ 89.217027] IRQ [81acbcfa] dump_stack+0x46/0x58 Jan 26 11:36:26 serveerstertje kernel: [ 89.227907] [810bdf62] warn_slowpath_common+0x82/0xb0 Jan 26 11:36:26 serveerstertje kernel: [ 89.238678] [810be031] warn_slowpath_fmt+0x41/0x50 Jan 26 11:36:26 serveerstertje kernel: [ 89.249336] [81471c5a] ? active_pfn_read_overlap+0x3a/0x70 Jan 26 11:36:26 serveerstertje kernel: [ 89.259904] [814729e3] add_dma_entry+0x103/0x130 Jan 26 11:36:26 serveerstertje kernel: [ 89.270416] [81472de6] debug_dma_map_page+0x126/0x150 Jan 26 11:36:26 serveerstertje kernel: [ 89.280840] [81714686] rtl8169_start_xmit+0x216/0xa20 [r8169 and xen stuff] Dan, I miss the part of the debug code that tells where the mappings were previously set. -- Ueimor -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
