[SR-Users] Kamailio stability/timing problem w.r.t. registrations?

Ovidiu Sas osas at voipembedded.com
Thu Jan 17 19:01:06 CET 2013


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 at 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 at 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



More information about the sr-users mailing list