On Tue, May 8, 2018 at 1:11 PM, Rosen Penev <ros...@gmail.com> wrote: > On Tue, May 8, 2018 at 1:08 PM, Kevin Darbyshire-Bryant via Lede-dev > <lede-dev@lists.infradead.org> wrote: >> The sender domain has a DMARC Reject/Quarantine policy which disallows >> sending mailing list messages using the original "From" header. >> >> To mitigate this problem, the original message has been wrapped >> automatically by the mailing list software. >> >> ---------- Forwarded message ---------- >> From: Kevin Darbyshire-Bryant <ke...@darbyshire-bryant.me.uk> >> To: Daniel Danzberger <dan...@dd-wrt.com> >> Cc: Rosen Penev <ros...@gmail.com>, "lede-dev@lists.infradead.org" >> <lede-dev@lists.infradead.org> >> Bcc: >> Date: Tue, 8 May 2018 20:07:56 +0000 >> Subject: Re: [LEDE-DEV] MMAP memory out of sync on AR71xx Rambutan >> (8devices) board. >> >> >>> On 8 May 2018, at 11:16, Daniel Danzberger <dan...@dd-wrt.com> wrote: >>> >>>>> >> <snip> >>>>> Did you encounter this issue with kernel 4.9? For me, 4.4 caused no >>>>> data corruption on my external hard drive. >>>> I can't tell right now. I was trying to use an older version with kernel >>>> 4.4, >>>> but it fails to build. >>> I just tested with 4.4 and the problem is present there as well. Then 3.18. Something tells me the issue is present there as well. I remember the btrfs driver crashing within 10 seconds after mounting a hard drive on that kernel. >>>>> >> >> So out of curiosity I built this for my Archer C7 v2 ar71xx device. I also >> modified the code to not give up on ‘OK’, so it always iterated 10 times. I >> then ran this repeatedly using ‘watch’. Observations: >> >> 1) Failure only occurred on 1st check, it never appeared/re-appeared on >> subsequent passes. >> 2) Failure offsets are always at 32 byte intervals. That corresponds nicely >> with cache-line size. > Yeah the L1 cache is not being flushed. This plagued ramips for a while. That particular issue was that the L1 cache on the first CPU was being flushed but not the second (L1 cache is per core).
I tested this on mt7621 and found no errors. MIPS, the gift that keeps on giving... Now that I think about it, one of the work arounds for mt7621 was to limit the number of CPUs to 1 with the nr-cpus=1 kernel command line flag. This should be valid no matter what though. The issue is probably different. Yeah I also have the ramips issue backported to kernel 4.9 (generic kernel patch) in my tree and I still see this issue. Hmm I have an mr3020. Trunk has ath79 with support for it(from what I see). Will report on 4.14. >> >> Grabbing at straws to some extent. >> >> >> Cheers, >> >> Kevin D-B >> >> 012C ACB2 28C6 C53E 9775 9123 B3A2 389B 9DE2 334A >> >> >> _______________________________________________ >> Lede-dev mailing list >> Lede-dev@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/lede-dev >> _______________________________________________ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
