Closed vineetgarc closed 3 years ago
This is happening even on latest ARCv2 Buildroot builds with latest paddlefish bitfile. Tried an old ARCv2 kernel binary (with initramfs) and that seems to work fine - so this is not specific to hardware but something to do with specific build.
Interestingly this happens with LMbench built from within buildroot. It doesn't happen when it is built off of github, even when built with same toolchain. So this turned out to be pretty mundane. Apparently almost 10 years ago I ran into this exact issue, when running on our beloved AA4 boards and needed a fix to lmbench memsize for slow fpgas. See TOO_LONG 100 usec to prevent memsize from timingout in lmbench repo which is missing from buildroot.
With that patch the problem goes away.
@vineetgarc could you please send this patch to Buildroot or we'll just keep using our GitHub fork for everything ARC?
Patch posted to BR: http://lists.infradead.org/pipermail/linux-snps-arc/2021-May/005066.html Merged upsream BR: 2f6d7b6333367582eef14073af0a490bc87d79f3
This came up during initial profiling of arc64 software stack on FPGA (@ 50 MHz).
LMBench needs to be configured before running to establish execution environment (subset, tmp dir, cpu clock etc). This is done via scripts/config-run which in turn invokes various small utility programs to do so. This includes memsize which verifies the amount of memory specified for use by actual benchmarks such lat_mem, mem_bw etc. It does so by touching the requested amount of memory (triggering Linux page faults) and making sure Linux can do that in under 10 usecs.
However at runtime memsize was bailing out early, deducing that there wasn't enough memory (1MB), whereas there's 100's of MBs of memory as configured in Device Tree.
standalone run NOK
Expected