From: nicolas.ferre@atmel.com (Nicolas Ferre)
To: linux-arm-kernel@lists.infradead.org
Subject: at91sam9260 MACB problem with IP fragmentation
Date: Thu, 20 Dec 2012 18:51:15 +0100 [thread overview]
Message-ID: <50D35013.9020106@atmel.com> (raw)
In-Reply-To: <50D2D7BD.3030801@erwinrol.com>
On 12/20/2012 10:17 AM, Erwin Rol :
> Hallo Nicolas,
>
> On 6-12-2012 14:27, Nicolas Ferre wrote:
>> Erwin,
>>
>> On 12/06/2012 12:32 PM, Erwin Rol :
>>> Hello Nicolas, Havard, all,
>>>
>>> I have a very obscure problem with a at91sam9260 board (almost 1 to 1
>>> copy of the Atmel EK).
>>>
>>> The MACB seems to stall when I use large (>2 * MTU) UDP datagrams. The
>>> test case is that a udp echo client (PC) sends datagrams with increasing
>>> length to the AT91 until the max length of the UDP datagram is reached.
>>> When there is no IP fragmentation everything is fine, but when the
>>> datagrams are starting to get fragmented the AT91 will not reply
>>> anymore. But as soon as some network traffic happens it goes on again,
>>> and non of the data is lost.
>
> <snip>
>
>>> I tried several kernels including the test version from Nicolas that he
>>> posted on LKML in October. They all show the same effect.
>>
>> [..]
>>
>> It seems that Matteo has the same behavior: check here:
>> http://www.spinics.net/lists/netdev/msg218951.html
>
> I tried Matteo's patch and it seems to work. But I don't know if the
> patch is really the right solution. I checked again with wireshark and
> it really seems the sending that stalls not the receiving. But as soon
> as a ethernet frame is received the sending "un-stalls". So maybe the
> patch just causes an MACB IRQ at certain moments that causes the sending
> to continue?
Any digging is interesting for me.
>> I am working on the macb driver right now, so I will try to reproduce
>> and track this issue on my side.
>
> Any luck reproducing it ?
Yes, I see unexpected things happening but as I am connected to a whole
company network so maybe some broadcast packets are unlocking the
interface...
Anyway, I am continuing to investigate.
Best regards,--
Nicolas Ferre
WARNING: multiple messages have this Message-ID (diff)
From: Nicolas Ferre <nicolas.ferre@atmel.com>
To: Erwin Rol <mailinglists@erwinrol.com>
Cc: <linux-kernel@vger.kernel.org>,
Havard Skinnemoen <havard@skinnemoen.net>,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
<matteo.fortini@sadel.it>, netdev <netdev@vger.kernel.org>
Subject: Re: at91sam9260 MACB problem with IP fragmentation
Date: Thu, 20 Dec 2012 18:51:15 +0100 [thread overview]
Message-ID: <50D35013.9020106@atmel.com> (raw)
In-Reply-To: <50D2D7BD.3030801@erwinrol.com>
On 12/20/2012 10:17 AM, Erwin Rol :
> Hallo Nicolas,
>
> On 6-12-2012 14:27, Nicolas Ferre wrote:
>> Erwin,
>>
>> On 12/06/2012 12:32 PM, Erwin Rol :
>>> Hello Nicolas, Havard, all,
>>>
>>> I have a very obscure problem with a at91sam9260 board (almost 1 to 1
>>> copy of the Atmel EK).
>>>
>>> The MACB seems to stall when I use large (>2 * MTU) UDP datagrams. The
>>> test case is that a udp echo client (PC) sends datagrams with increasing
>>> length to the AT91 until the max length of the UDP datagram is reached.
>>> When there is no IP fragmentation everything is fine, but when the
>>> datagrams are starting to get fragmented the AT91 will not reply
>>> anymore. But as soon as some network traffic happens it goes on again,
>>> and non of the data is lost.
>
> <snip>
>
>>> I tried several kernels including the test version from Nicolas that he
>>> posted on LKML in October. They all show the same effect.
>>
>> [..]
>>
>> It seems that Matteo has the same behavior: check here:
>> http://www.spinics.net/lists/netdev/msg218951.html
>
> I tried Matteo's patch and it seems to work. But I don't know if the
> patch is really the right solution. I checked again with wireshark and
> it really seems the sending that stalls not the receiving. But as soon
> as a ethernet frame is received the sending "un-stalls". So maybe the
> patch just causes an MACB IRQ at certain moments that causes the sending
> to continue?
Any digging is interesting for me.
>> I am working on the macb driver right now, so I will try to reproduce
>> and track this issue on my side.
>
> Any luck reproducing it ?
Yes, I see unexpected things happening but as I am connected to a whole
company network so maybe some broadcast packets are unlocking the
interface...
Anyway, I am continuing to investigate.
Best regards,--
Nicolas Ferre
next prev parent reply other threads:[~2012-12-20 17:51 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-06 11:32 at91sam9260 MACB problem with IP fragmentation Erwin Rol
2012-12-06 13:27 ` Nicolas Ferre
2012-12-06 13:27 ` Nicolas Ferre
2012-12-06 15:15 ` Erwin Rol
2012-12-06 15:15 ` Erwin Rol
2012-12-20 9:17 ` Erwin Rol
2012-12-20 9:17 ` Erwin Rol
2012-12-20 17:51 ` Nicolas Ferre [this message]
2012-12-20 17:51 ` Nicolas Ferre
2013-02-12 10:08 ` [PATCH] net/macb: fix race with RX interrupt while doing NAPI Nicolas Ferre
2013-02-12 10:08 ` Nicolas Ferre
2013-02-13 18:36 ` David Miller
2013-02-13 18:36 ` David Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=50D35013.9020106@atmel.com \
--to=nicolas.ferre@atmel.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.