Re: Regression: memory corruption on Atmel SAMA5D31

From: Peter Rosin <peda@axentia.se>
To: Tudor.Ambarus@microchip.com, saravanak@google.com
Cc: alexandre.belloni@bootlin.com, gregkh@linuxfoundation.org,
	linux-kernel@vger.kernel.org, du@axentia.se,
	Ludovic.Desroches@microchip.com,
	linux-arm-kernel@lists.infradead.org
Subject: Re: Regression: memory corruption on Atmel SAMA5D31
Date: Mon, 7 Mar 2022 21:32:24 +0100	[thread overview]
Message-ID: <7214ea3d-1445-c0fb-2620-cdc3d6167bcc@axentia.se> (raw)
In-Reply-To: <9e24034e-f586-a721-9031-179601a69abb@axentia.se>

On 2022-03-07 12:32, Peter Rosin wrote:
> On 2022-03-07 10:45, Tudor.Ambarus@microchip.com wrote:
>> Peter, would it worth to do on your board a similar test to what I did?
>> I'm thinking whether the source of interrupts matters or not. So can you
>> disable your USB and use a mtd NAND stress test as a source of interrupts?
>> mtd_stresstest together with scp or hexdump.
> 
> That's not a quick test for me, since I don't have modules enabled.
> I have located my SAMA5D31 evaluation kit, and I think I will try
> to get that running instead.

Hi again!

I got my SAMA5D31EK board running, using a freshly built at91bootstrap
and u-boot according to linux4sam.org and using the cross compiler I
have used from buildroot 2021.08, i.e. gcc 10.3.0, then using the
dtb for the ME20 from the original post and the same kernel and userspace
as I have used previously. Now, that dtb describes things that may not
actually be there etc etc, and I will try with a proper dtb as well
tomorrow, so this was just a quick-n-dirty test. I also added mem=64MB
to the kernel command line, to mimic our "Linea" CPU module and get a
bit quicker turnaround in the page cache.

Anyway, with that setup I can reproduce the problem on the EK board.

$ while :; do cat testfile | sha256sum; done
5a939c69dd60a1f991e43d278d2e824a0e7376600a6b20c8e8b347871c546f9b  -
7bf74cf37c8bf81ad4f8e86da8eb129a8ae0ee0f5a22ac584ad39233b97acb4d  -
7bf74cf37c8bf81ad4f8e86da8eb129a8ae0ee0f5a22ac584ad39233b97acb4d  -
250556db0a6ac3c3e101ae2845da48ebb39a0c12d4c9b9eec5ea229c426bcce9  -
874c694ed002b04b67bf354a95ee521effd07e198f363e02cd63069a94fd4df8  -
7bf74cf37c8bf81ad4f8e86da8eb129a8ae0ee0f5a22ac584ad39233b97acb4d  -
c3a918a923ff2d504a45ffa51289e69fb6d8aa1140cca3fd9f30703b18d9e509  -
1577ed72d2f296f9adc50707e0e56547ecb311fa21ad875a3d55ca908c440307  -
7bf74cf37c8bf81ad4f8e86da8eb129a8ae0ee0f5a22ac584ad39233b97acb4d  -
7bf74cf37c8bf81ad4f8e86da8eb129a8ae0ee0f5a22ac584ad39233b97acb4d  -

But apparently only if I have an FTDI usb-serial adapter attached
while I boot. I also start to get good hashes if I remove and
reinsert the FTDI adapter, which is interesting.

$ while :; do cat testfile | sha256sum; done
7bf74cf37c8bf81ad4f8e86da8eb129a8ae0ee0f5a22ac584ad39233b97acb4d  -
7bf74cf37c8bf81ad4f8e86da8eb129a8ae0ee0f5a22ac584ad39233b97acb4d  -
7bf74cf37c8bf81ad4f8e86da8eb129a8ae0ee0f5a22ac584ad39233b97acb4d  -
...
*snip many dozens of lines*
...
7bf74cf37c8bf81ad4f8e86da8eb129a8ae0ee0f5a22ac584ad39233b97acb4d  -

It's of course hard to prove the absence of trouble, but it feels
like it is working from both of those latter cases...

(for the "real" case the FTDI usb-serial adapter is soldered in,
 with no easy way to make it go away, so it is not as easy to do the
 same test there.)

I'll try to reduce the number of local parts of the setup further
tomorrow, such as the dtb mentioned above and the rootfs. I was
hoping for a binary download of prebuilt parts, but some links on

https://www.linux4sam.org/bin/view/Linux4SAM/Sama5d3xekMainPage

are bogus. E.g.

ftp://twiki.lnx4mchp_backend/pub/demo/linux4sam_4.7/linux4sam-poky-sama5d3xek-4.7.zip

What's up with that twiki.lnx4mchp_backend "host"?

Cheers,
Peter