[LEDE-DEV] MMAP memory out of sync on AR71xx Rambutan (8devices) board.

[Rosen Penev]

On Tue, May 8, 2018 at 1:11 PM, Rosen Penev <rosenp at gmail.com> wrote:
> On Tue, May 8, 2018 at 1:08 PM, Kevin Darbyshire-Bryant via Lede-dev
> <lede-dev at 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 <kevin at darbyshire-bryant.me.uk>
>> To: Daniel Danzberger <daniel at dd-wrt.com>
>> Cc: Rosen Penev <rosenp at gmail.com>, "lede-dev at lists.infradead.org" <lede-dev at 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 <daniel at 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 at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/lede-dev
>>