From: Dean Gehnert <deang@tpi•com>
To: Russell King - ARM Linux <linux@arm•linux.org.uk>
Cc: Ezequiel Garcia <ezequiel.garcia@free-electrons•com>,
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 13:27:31 -0800 [thread overview]
Message-ID: <54C16B43.5040504@tpi.com> (raw)
In-Reply-To: <20150122210951.GC26493@n2100.arm.linux.org.uk>
On 01/22/2015 01:09 PM, Russell King - ARM Linux wrote:
> On Thu, Jan 22, 2015 at 10:41:00AM -0800, Dean Gehnert wrote:
>> 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.
> That's not quite what I'm seeing. What I'm seeing with NFS is that the
> machine is basically unusable. I have the etna_viv source in a NFS
> share (it's shared amongst not only the Dove box but also my collection
> of iMX6 based hardware.)
>
> I'm fairly fully IPv6 enabled here, which includes NFS.
>
> On the Dove, if I try to build this without any fixes, and then try to
> build the etna_viv sources, it will take the machine out to the extent
> that I have to reboot it - either the machine will freeze solidly, or
> the kernel will oops in the DMA API functions, in a path which was
> called from an interrupt handler. That takes out the entire machine
> because we miss acknowleding the interrupt.
I am wondering if there is a possibility of the root cause of this being
in the arch DMA layer... From my testing with SOCAT and different cache
line alignments, I am seeing Ethernet 4 byte transmit corruptions. My
fear is this may not be restricted to the Ethernet transmit and maybe
the root cause is a DMA / cache issue... I have no way to prove that
theory. Your DMA API oops is a bit concerning that maybe there is some
corruption going on during DMA operation.
>
> Either way, it's effectively a power cycle as there's no reset button on
> the machine.
>
> I have yet to see any sign of data corruption.
>
Can you can try the SOCAT test on your Dove platform and see if that
passes the non-cache line aligned test case? I think what the SOCAT test
does is take the NFS "variable" out of the equation. My theory is that
if there is a DMA corruption, then hard telling what kinds of problems
will occur. It might be the payload of a file is corrupted, or if the
NFS structures are corrupted, it could manifest itself as a problem in
the NFS code.
next prev parent reply other threads:[~2015-01-22 21:27 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
2015-01-22 19:01 ` Dean Gehnert
2015-01-22 21:09 ` Russell King - ARM Linux
2015-01-22 21:27 ` Dean Gehnert [this message]
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=54C16B43.5040504@tpi.com \
--to=deang@tpi$(echo .)com \
--cc=B38611@freescale$(echo .)com \
--cc=davem@davemloft$(echo .)net \
--cc=ezequiel.garcia@free-electrons$(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