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:
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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:
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
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
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
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
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
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
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
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
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
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
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
>
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
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
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
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
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
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 /
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
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
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
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
>
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
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
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
40 matches
Mail list logo
