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

[Kevin Darbyshire-Bryant]

> On 9 May 2018, at 11:27, Daniel Danzberger <daniel at dd-wrt.com> wrote:
> 
> On 05/
>> 
>> 
>> So that smells more of a race condition between the writer filling with 0xFF and the reader catching up.
> The open() syscall does the memset(0xff) and blocks. This ensures the memory is
> initialized before the open() returns. I don't think there is a race.
>> 
>> Again, assume that I am an idiot and am missing something fundamental.

I did say assume I’m an idiot.  OK so I did a bit more playing because this has piqued my interest as a ‘fun’ thing to play with :-)

First off, I further modded the user code to report the byte value seen when non 0xFF.  I further modified it to carry on, to see if there were discontinuous errors.

I only ever see values of 0 or 0xFF.  What is more curious is that I do see discontiguous segments of 0’s.  Occasionally for 2 or 3 bytes only:

mmap addr: 0x779ae000
check memory ...FAIL 00 (at byte 96)
FAIL 00 (at byte 97)
FAIL 00 (at byte 416)
FAIL 00 (at byte 417)
FAIL 00 (at byte 418)
FAIL 00 (at byte 419)
FAIL 00 (at byte 420)
FAIL 00 (at byte 421)
FAIL 00 (at byte 422)
FAIL 00 (at byte 423)
FAIL 00 (at byte 424)
FAIL 00 (at byte 425)
FAIL 00 (at byte 426)
FAIL 00 (at byte 427)
FAIL 00 (at byte 428)
FAIL 00 (at byte 429)
FAIL 00 (at byte 430)
FAIL 00 (at byte 431)
FAIL 00 (at byte 432)
FAIL 00 (at byte 433)
FAIL 00 (at byte 434)
FAIL 00 (at byte 435)
FAIL 00 (at byte 436)
FAIL 00 (at byte 437)
FAIL 00 (at byte 438)
FAIL 00 (at byte 439)
FAIL 00 (at byte 440)
FAIL 00 (at byte 441)
FAIL 00 (at byte 442)
FAIL 00 (at byte 443)
FAIL 00 (at byte 444)
FAIL 00 (at byte 445)
FAIL 00 (at byte 446)
FAIL 00 (at byte 447)

I further modified the kernel code to set 2 intermediate values (0 allocated, 55, AA, FF) to see if there was some sort ‘race’.  Again, the only values I saw were 0 or FF.  No idea what this means, or whether it’s helpful or not. :-/


Cheers,

Kevin D-B

012C ACB2 28C6 C53E 9775  9123 B3A2 389B 9DE2 334A

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.infradead.org/pipermail/lede-dev/attachments/20180510/3fa320f6/attachment.sig>