Bruce Ashfield <bruce.ashfield-re5jqeeqqe8avxtiumw...@public.gmane.org>
writes:
>> Applying two upstream kernel commits
>> 455bd4c430b0c0a361f38e8658a0d6cb469942b5 (ARM: 7668/1: fix
>> memset-related crashes caused by recent GCC (4.7.2) optimizations) and
>> 418df63adac56841ef6b0f1fcf435bc64d4ed177 (ARM: 7670/1: fix the memset
>> fix) seem to fix the problem for me.
>
> Correct. Those are the same commits you'll see on linux-yocto-3.8,
> we've been soaking them for a while. I was waiting for LTSI and -stable
> to pick up the changes before updating linux-yocto-3.4, but that hasn't
> happened yet.
>
> If you are using linux-yocto-3.4 and can confirm that it boots for you
> with those patches,
Sorry, I am using a more or less vanilla 3.4 kernel. Patches fix
the problem there (device boots) and (after knowing about them) the
problematic code is easy to spot:
$ arm-linux-gnueabi-objdump -d mm/slub.o
000014c4 <init_object>:
...
14fc: e1a00001 mov r0, r1
1500: e3a0106b mov r1, #107 ; 0x6b
1504: ebfffffe bl 0 <memset>
1508: e1a03000 mov r3, r0 <<<<<<<
150c: e5942010 ldr r2, [r4, #16]
1510: e3e0105a mvn r1, #90 ; 0x5a
1514: e0832002 add r2, r3, r2
1518: e5421001 strb r1, [r2, #-1]
With unpatched memset, 'r0' points to end of buffer.
Enrico
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
