[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150122210951.GC26493@n2100.arm.linux.org.uk>
Date: Thu, 22 Jan 2015 21:09:51 +0000
From: Russell King - ARM Linux <linux@....linux.org.uk>
To: Dean Gehnert <deang@....com>
Cc: Ezequiel Garcia <ezequiel.garcia@...e-electrons.com>,
netdev@...r.kernel.org, David Miller <davem@...emloft.net>,
B38611@...escale.com, fabio.estevam@...escale.com
Subject: Re: [PATCH net 0/2] net: marvell: Fix highmem support on non-TSO path
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.
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.
--
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists