17 Jan
2013
17 Jan
'13
8:01 p.m.
If you are running the stable version, there's need for heavy Makefile
patching in order to properly cross compile (not to include and link
to host libs).
The trunk has everything fixed and it's cross-compiling properly for
most of the modules.
Make sure that your binaries are properly cross compiled.
Depending on your ARM CPU, atomic locks may or may not work.
I tested openser without atomic locks (using regular locks) and it worked fine.
Regards,
Ovidiu Sas
--
VoIP Embedded, Inc.
http://www.voipembedded.com
On Thu, Jan 17, 2013 at 12:43 PM, Sotas Development <sotasdev(a)gmail.com> wrote:
Hi Ovidiu,
Good points. We're not running out of memory, and all processes keep
running.
Top shows 0% or 1% CPU load for the Kamailio processes.
We cross-compile with the CodeSourcery toolchain. The default build options
drag in the file atomic_unknown.h, that produces the following compile
warning:
"no native memory barrier implementations, falling back to slow lock based
workarround"
Currently we're testing a version compiled with -DNOSMP (no
atomic_unknown.h)
that will run over the weekend.
Regards,
Michiel Veldkamp
On Thu, Jan 17, 2013 at 3:20 PM, Ovidiu Sas <osas(a)voipembedded.com> wrote:
>
> Hello Michiel ,
>
> You should check with top to see the status of all kamailio processes.
> If you see processes that are using 100% CPU, you may have a deadlock.
> Connect with gdb to the process to investigate what's going on.
>
> Also, you are running on arm. How did you compiled kamailio: native or
> cross.
> When you run kamailio on an embedded system, you need to check if you
> have enough memory. If you start running out of memory, the OS may
> start killing processes randomly (check your OS logs).
>
> You definitely need to look at this issue from a broader prospective
> as it's not a regular x86 deployment with plenty of CPU and memory.
> Also tuning the config (by removing everything that you don't need
> might help with memory utilization).
>
>
> Regards,
> Ovidiu Sas