[prev in list] [next in list] [prev in thread] [next in thread] 

List:       busybox
Subject:    Re: Weird signal issues using yocto's warrior busybox (aarch64) when memory is cached
From:       Sergio Paracuellos <sergio.paracuellos () gmail ! com>
Date:       2020-01-31 8:47:50
Message-ID: CAMhs-H8JaB88W73VHAVcMPVfpAK_HCn6j4sWuAGd2yULfBqWXQ () mail ! gmail ! com
[Download RAW message or body]

Hi Stefan,

On Fri, Jan 31, 2020 at 8:41 AM Stefan Seyfried
<stefan.seyfried@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@busybox.net
> http://lists.busybox.net/mailman/listinfo/busybox
_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox


[prev in list] [next in list] [prev in thread] [next in thread]