From: Ezequiel Garcia <ezequiel.garcia@free-electrons•com>
To: deang@tpi•com, Russell King - ARM Linux <linux@arm•linux.org.uk>
Cc: netdev@vger•kernel.org, David Miller <davem@davemloft•net>,
B38611@freescale•com, fabio.estevam@freescale•com
Subject: Re: [PATCH net 0/2] net: marvell: Fix highmem support on non-TSO path
Date: Thu, 22 Jan 2015 15:45:56 -0300 [thread overview]
Message-ID: <54C14564.7060408@free-electrons.com> (raw)
In-Reply-To: <54C1443C.80909@tpi.com>
On 01/22/2015 03:41 PM, Dean Gehnert wrote:
> On 01/21/2015 07:01 AM, Russell King - ARM Linux wrote:
>> On Wed, Jan 21, 2015 at 09:54:08AM -0300, Ezequiel Garcia wrote:
>>> These two commits are fixes to the issue reported by Russell King on
>>> mv643xx_eth. Namely, the introduction of a regression by commit
>>> 69ad0dd7af22
>>> which removed the support for highmem skb fragments. The guilty commit
>>> introduced the assumption of fragment's payload being located in
>>> lowmem pages.
>> I do wonder whether 69ad0dd7af22 is the real culpret, or whether there is
>> some other change in the netdev layer that we're missing. That commit is
>> in 3.16, but from what I remember, 3.17 works fine, it's 3.18 which
>> fails.
>>
>>> A similar pattern can be found in the original mvneta driver (in
>>> fact, the
>>> regression was introduced by copy-pasting the mvneta code).
>>>
>>> These fixes are for the non-TSO egress path in mvneta and mv643xx_eth
>>> drivers.
>>> The TSO path needs a more intrusive change, as the TSO API needs to
>>> be fixed
>>> (e.g. to make it work in skb fragments, instead of pointers to data).
>>>
>>> Russell, as I'm still unable to reproduce this, do you think you can
>>> give it a spin over there?
>> Sure - I think the only one I can test is mv643xx_eth, I don't think I
>> have any device which supports mv_neta.
>>
>> The test scenario is for a NFS mount (the Marvell device as the NFS
>> client) over IPv6.
>>
>> Initial testing looks good, I'll let it run for a while with various
>> builds on the NFS share (which iirc was one of the triggering
>> workloads).
>>
>> Thanks.
>>
> FYI, I found a way to reproduce the mv643xx_eth transmit corruption
> without using a network filesystem by using SOCAT (should also be able
> to use NETCAT or NC) and I have a bit more information about the
> corruption that looks like it is somehow related to the cache line size.
>
> 1) Create a "large" input file with known data on the target (saved to
> RAM disk or other storage):
> % php -r 'for ($x = 0; $x < 0x2000000; $x++) { printf("%08X\n", $x);
> }' > ExpectData.in
> or
> % perl -e 'for ($x = 0; $x < 0x2000000; $x++) { printf("%08X\n",
> $x); }' > ExpectData.in
> % md5sum ExpectData.in
> 4a4727232209b85badc1ca25ed4df222 ExpectData.in
> 2) Start SOCAT on the host system to perform Ethernet receive MD5
> checksum of the data:
> % socat -s -u TCP4-LISTEN:4000,fork,reuseaddr EXEC:md5sum
> 3) Enable TSO on the target:
> % ethtool -K eth0 tso on
> 4) Send the data file from the target to the host using SOCAT with a
> non-cache aligned block size:
> % socat -b$(((1024*10)+1)) -u ExpectData.in TCP:192.168.1.212:4000
> 5) The SOCAT running on the host system will report the MD5 checksum. If
> the MD5 is correct, it should be 4a4727232209b85badc1ca25ed4df222.
>
> What I am seeing is every now and then, there are 32-bits (4 bytes) of
> data in the transmit Ethernet stream that are corrupted. If I change the
> SOCAT block size to something that is Armada 300 (Kirkwood) cache line
> aligned (ie. -b$(((1024*10)+0)) or -b$(((1024*10)+8))), it works just
> fine... If you want to capture the actual file and look at it, you can
> use SOCAT:
> % socat -u TCP4-LISTEN:4000,fork,reuseaddr OPEN:ActualData.in,creat
> and since the data file is text, it is really easy to see the corruption
> (diff ExpectData.in ActualData.in | less).
>
> I can disable TSO (ethtool -K eth0 tso off) and re-run the tests and the
> corruption does not occur.
>
> I will give Ezequiel's latest patches a test a today and let you know if
> they change the behavior.
>
Sigh, this smells like a completely different bug. Which kernel version
are you testing?
--
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
next prev parent reply other threads:[~2015-01-22 18:48 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-21 12:54 [PATCH net 0/2] net: marvell: Fix highmem support on non-TSO path Ezequiel Garcia
2015-01-21 12:54 ` [PATCH 1/2] net: mvneta: Fix highmem support in the non-TSO egress path Ezequiel Garcia
2015-01-26 22:40 ` David Miller
2015-01-21 12:54 ` [PATCH 2/2] net: mv643xx_eth: Fix highmem support in " Ezequiel Garcia
2015-01-21 17:40 ` Russell King - ARM Linux
2015-01-21 23:34 ` Ezequiel Garcia
2015-01-22 0:11 ` Russell King - ARM Linux
2015-01-22 12:17 ` Ezequiel Garcia
2015-01-26 22:40 ` David Miller
2015-01-21 15:01 ` [PATCH net 0/2] net: marvell: Fix highmem support on non-TSO path Russell King - ARM Linux
2015-01-22 18:41 ` Dean Gehnert
2015-01-22 18:45 ` Ezequiel Garcia [this message]
2015-01-22 19:01 ` Dean Gehnert
2015-01-22 21:09 ` Russell King - ARM Linux
2015-01-22 21:27 ` Dean Gehnert
2015-01-22 21:49 ` Russell King - ARM Linux
2015-01-22 23:06 ` Russell King - ARM Linux
2015-01-22 23:09 ` Dean Gehnert
2015-01-22 23:08 ` Dean Gehnert
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=54C14564.7060408@free-electrons.com \
--to=ezequiel.garcia@free-electrons$(echo .)com \
--cc=B38611@freescale$(echo .)com \
--cc=davem@davemloft$(echo .)net \
--cc=deang@tpi$(echo .)com \
--cc=fabio.estevam@freescale$(echo .)com \
--cc=linux@arm$(echo .)linux.org.uk \
--cc=netdev@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox