On Tue, Sep 16, 2014 at 01:20 AM, Holger Hans Peter Freyther wrote:On Mon, Sep 15, 2014 at 04:13:28PM +0000, admin(a)manateeshome.com (mailto:admin@manateeshome.com) wrote: Hi! osmo-sgsn: sgsn_libgtp.c:432 GTP DATA IND from GGSN, length=52 sgsn_libgtp.c:432 GTP DATA IND from GGSN, length=52 sgsn_libgtp.c:432 GTP DATA IND from GGSN, length=1171 sgsn_libgtp.c:432 GTP DATA IND from GGSN, length=1171 gprs_ns.c:545 NSEI=101 Tns-alive expired more then 10 times, blocking NS-VC sgsn_libgtp.c:432 GTP DATA IND from GGSN, length=1171 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