This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Sipos Csaba dchardware at gmail.comHey Holger, Thanks for the help. I am a little new in debugging so it might take a while, till I find out why the LAPD connection got reopened after OpenBSC receives the ack for the Nokia reset_req. Until we can figure it out what is the problem, there is a temporary solution. With "nokia_site skip-reset 1" in the config file and with the following modification in bts_nokia_site.c: static int shutdown_om(struct gsm_bts *bts) { /* TODO !? */ LOGP(DNM, LOGL_NOTICE, "Sending Nokia RESET_REQ before shutdown\n"); abis_nm_reset(bts, 1); return 0; } now the reset takes place not during the initialization, but during the shutdown. The result is the same: on the next OpenBSC run all Nokia BTS will be in a "clean restarted" state already, so despite the "skip-reset 1" both the OML and the RSL can be bootstrapped properly. This is not a final solution for sure, there is no exception handling, it doesn't wait for ACK or anything, but at least it seems it is working for now, and there is no LAPD errors and segfault failures neither, even with the "problematic" patch applied. Will test this in 1-2 days, and report back with the results. BR, Csaba > On Sun, Jul 28, 2013 at 05:34:57PM +0200, Sipos Csaba wrote: >> Hi Holger >> >> I've made some progress with the segfault problem regarding Nokia and >> patch: f5a079f739c57d8be7c59149fd45475c402a45fc > Hi, > I can only provide you with debug aid. >> It seems if I use "nokia_site skip-reset 1" in the config file, the >> problem is gone. I am pretty sure after these months, that the problem >> about the LAPD errors, this segfault problem and the multi-BTS problem >> is somewhere around the code that is responsible for this reset >> sequence, because if I turn it off, all problems are gone. > * the reset will lead to LDAP release.. > * some one is using the released link.. > debug: > * Set a breakpoint in the code that is relreasing the hist buff > * Once it is hit set a watchpoint on the memory regions... > * Figure out who is accessing it first.. > * Then try to figure out if that is correct or not > ** E.g. do we need to flush a queue>