On Tue, Sep 16, 2014 at 01:20 AM, Holger Hans Peter Freyther <holger@freyther.de> wrote:

On Mon, Sep 15, 2014 at 04:13:28PM +0000, admin@manateeshome.com wrote:

Hi!

osmo-sgsn:

<000f> sgsn_libgtp.c:432 GTP DATA IND from GGSN, length=52
<000f> sgsn_libgtp.c:432 GTP DATA IND from GGSN, length=52
<000f> sgsn_libgtp.c:432 GTP DATA IND from GGSN, length=1171
<000f> sgsn_libgtp.c:432 GTP DATA IND from GGSN, length=1171
<0010> gprs_ns.c:545 NSEI=101 Tns-alive expired more then 10 times, blocking NS-VC
<000f> sgsn_libgtp.c:432 GTP DATA IND from GGSN, length=1171
<0010> gprs_ns.c:624 All NS-VCs for NSEI 101 are either dead or blocked!

Program received signal SIGABRT, Aborted.
0x00007ffff69b3445 in raise () from /lib/x86_64-linux-gnu/libc.so.6

it is a known crash with a double free in the defragmentation code (not
freeing will most likely lead to a leak). Are you willing to sponsor
the necessary code-review to make that issue go away?

I wish I could, but I am not accustomed to debugging code in linux.
I looked over the surrounding code for a bit but it was difficult for me to get down to it without knowing how those are supposed to work...

Failure Event Report Type=processing failure Severity=warning level failure Probable cause= 03 00 01 Additional Text=31357:WARN:BH_TRX_ROUTER_TR:rm_s_data_queue_entry.c#195:Pool 2 nearly full
Failure Event Report Type=processing failure Severity=warning level failure Probable cause= 03 00 01 Additional Text=31663:WARN:BH_TRX_ROUTER_TR:igki_sig.c#741:Pool 2 nearly full

GPRS with the nanoBTS is not very stable. They have known memory
leaks in all versions of their firmware.

If thats the case, how are commercial operators coping with those crashes?
Worst I've ever seen is the BTS crashing in 10 minutes of operation with a single iPhone connected.
I don't think thats even close to production level?


Regards,
Pierre