Hello list!
I have a couple of "tiny machines" based on the ARM architecture and
wanted to see how the Assimilation code would build and run on these
devices. One is a Raspberry Pi and the other is a Via APC (original
model). Since I had Debian "Wheezey" loaded on the APC, that's where I
have done testing so far.
Following the "Getting Started" guide on the web site was straight
forward. All of the prerequisite packages were available and easily
installed with apt or pip... neo4j was installed from its tar ball and
run with the IcedTea v7 JVM.
The Assimilation source code was checked out with mercurial and built as
specified with no problems (including creating .deb packages).
Below is a list of issues I have encountered so far:
Issue 1: at present, there is a conflict with the
/usr/share/assimilation/copyright file between the cma and nanoprobe deb
packages, so one must be installed with the --force-overwrite flag
passed to the dpkg command.
Issue 2: having IPv6 support in the kernel is mandatory. I had to
rebuild mine and enable support. I'm not sure how common it is to have
this disabled by default, but I suspect it's "not uncommon" on these
small systems with limited resources.
Issue 3: the valgrind test fails miserably, but I believe this may be
due to platform issues and not the assimilation code. I have pasted
output at the end of this post (so it doesn't clutter this section).
Note that the testify and pinger tests run successfully.
Issue 4: the Getting Started document states "These tests require that
the CMA and nanoprobe are not stopped on the current machine while they
run.", but the pinger test fails if they are running.
Issue 5: the cpu discovery agent only understands the format of
/proc/cpuinfo on x86 hardware. The format for ARM is quite different. I
looked at the format on both the APC and the RPi and it is at least
consistent between these two. Hopefully it's consistent for all ARM
based platforms.
* Output from /proc/cpuinfo on the APC device:
Processor : ARMv6-compatible processor rev 7 (v6l)
BogoMIPS : 532.24
Features : swp half thumb fastmult vfp edsp java
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xb76
CPU revision : 7
Hardware : WMT
Revision : 0000
Serial : 0000000000000000
* Output from grind.sh:
==21711== Invalid write of size 4
==21711== at 0x4B15314: __pthread_initialize_minimal (nptl-init.c:291)
==21711== by 0x4B13B1F: ??? (in
/lib/arm-linux-gnueabihf/libpthread-2.13.so)
==21711== Address 0x4001ecfc is not stack'd, malloc'd or (recently) free'd
==21711==
{
<insert_a_suppression_name_here>
Memcheck:Addr4
fun:__pthread_initialize_minimal
obj:/lib/arm-linux-gnueabihf/libpthread-2.13.so
}
==21711==
==21711== Process terminating with default action of signal 11 (SIGSEGV)
==21711== Access not within mapped region at address 0x4001ECFC
==21711== at 0x4B15314: __pthread_initialize_minimal (nptl-init.c:291)
==21711== by 0x4B13B1F: ??? (in
/lib/arm-linux-gnueabihf/libpthread-2.13.so)
==21711== If you believe this happened as a result of a stack
==21711== overflow in your program's main thread (unlikely but
==21711== possible), you can try to increase the size of the
==21711== main thread stack using the --main-stacksize= flag.
==21711== The main thread stack size used in this run was 8388608.
==21711== Invalid read of size 4
==21711== at 0x400E5EC: _dl_fixup (dl-runtime.c:109)
==21711== by 0x4014BFF: _dl_runtime_resolve (dl-trampoline.S:62)
==21711== by 0x48274F7: _vgnU_freeres (vg_preloaded.c:61)
==21711== by 0x4B152EB: __pthread_initialize_minimal (nptl-init.c:288)
==21711== by 0xFFFFFFFF: ???
==21711== Address 0x4001eb70 is not stack'd, malloc'd or (recently) free'd
==21711==
{
<insert_a_suppression_name_here>
Memcheck:Addr4
fun:_dl_fixup
fun:_dl_runtime_resolve
fun:_vgnU_freeres
fun:__pthread_initialize_minimal
obj:*
}
==21711==
==21711== Process terminating with default action of signal 11 (SIGSEGV)
==21711== Access not within mapped region at address 0x4001EB70
==21711== at 0x400E5EC: _dl_fixup (dl-runtime.c:109)
==21711== by 0x4014BFF: _dl_runtime_resolve (dl-trampoline.S:62)
==21711== by 0x48274F7: _vgnU_freeres (vg_preloaded.c:61)
==21711== by 0x4B152EB: __pthread_initialize_minimal (nptl-init.c:288)
==21711== by 0xFFFFFFFF: ???
==21711== If you believe this happened as a result of a stack
==21711== overflow in your program's main thread (unlikely but
==21711== possible), you can try to increase the size of the
==21711== main thread stack using the --main-stacksize= flag.
==21711== The main thread stack size used in this run was 8388608.
~/assimilation/testcode/grind.sh: line 30: 21711 Segmentation fault
valgrind -q --sim-hints=lax-ioctls --leak-check=full
--show-reachable=yes --suppressions=$HERE/valgrind-msgs.supp $GEN
--error-exitcode=100 --trace-children=no --child-silent-after-fork=yes
./mainlooptest $REPCOUNT
_______________________________________________
Assimilation mailing list - Discovery-Driven Monitoring
[email protected]
http://lists.community.tummy.com/cgi-bin/mailman/listinfo/assimilation
http://assimmon.org/
