Weird signal issues using yocto's warrior busybox (aarch64) when memory is cached

Sergio Paracuellos sergio.paracuellos at gmail.com
Fri Jan 31 08:47:50 UTC 2020


Hi Stefan,

On Fri, Jan 31, 2020 at 8:41 AM Stefan Seyfried
<stefan.seyfried at googlemail.com> wrote:
>
> Am 30.01.20 um 19:23 schrieb Sergio Paracuellos:
>
> >> First things first, do you trust the hardware?  If the system swapped
> >> out some pages and then read them back in and the controller or storage
> >> device gave back bad data, this could cause all sorts of crashes.  Maybe
> >> run a memtest, too, unless you can reproduce the issue on multiple
> >> different machines.
> >
> > I am able to reproduce the issue using different SOMs with its own RAM
> > chip on it, and its own mmc storage device where the system is
> > installed so I
> > am pretty sure the hardware is not the problem here.
>
> Then look at the kernel.
> Use an older / newer one.
> Use a different compiler to build everything.

I am using stable branch 4.9 since its beginning and merging it with
its updates. I did not have any notable regression in more than one
year, so I think the kernel is not the problem also. If the kernel
were the problem I think I'll see an oops or something weird in its
side... But, who knows :-)

>
> Even nowadays, arm64 is still an exotic architecture (outside of some embedded niches and phones, but they all use their
> own, often old and patched-to-hell toolchain).

That's true. I am using a Xilinx's architecture ultrascale MPSoC
running linux in its A53 cores and some acquisition data in its arm R5
real time cores. I need some boot binaries to be compiled with
Xilinx's toolchain but I did not notice this kind of problems when I
was using other yocto's version (sumo branch, for example). That was a
gcc based 7.x compiler and the one we are using now is gcc 8.3.0 based
one.

>
> Try building busybox with another toolchain / distribution (use the crap that came with the board from the vendor
> instead of yocto, chances are the vendor has patched the hell out and into the old crap they give you to make it run on
> their broken hardware ;-))

After looking to different core files it seems I am able to reproduce
issues and seems to be related with a fork() -> execl pattern when
running different programs. That seems the way the shell exec
processes. I think I should also try to reproduce this behaviour with
a more accurate C program doing the same :-). I don't want to make
busybox the real guilty here, but until now all my problems are
related with it, and that's why I am asking here :)). I'll try it and
report here afterwards.
>
> BTDT.
>

Thanks for your help. Very appreciated.

Best regards,
     Sergio Paracuellos

> >> I just had a USB thumb drive corrupt a file with no warning, so it was
> >> fresh on my mind.
>
> --
> Stefan Seyfried
>
> "For a successful technology, reality must take precedence over
>  public relations, for nature cannot be fooled." -- Richard Feynman
> _______________________________________________
> busybox mailing list
> busybox at busybox.net
> http://lists.busybox.net/mailman/listinfo/busybox


More information about the busybox mailing list