re-base + test om2000-fsm branch to get it submitted
There's a laforge/om2000-fsm branch that needs to be re-based, tested and submitted.
I have started a re-base, but it is quite complex due to the many PDCH related changes. Will do some testing today and then hand over to dexter.
- % Done changed from 0 to 50
The rebased branch seems to work fine. However, there is a very reproduceable segfault that does not occur in the (non rebased) branch located in /root/git. The problem occurs when osmo-nitb is restarted immediately after it was stopped. Presumably this has something to do with the internal states inside the BTS. It probably behaves differently because some of its objects are already initalized.
<0020> e1_input.c:642 RX: 80 80 00 28 00 8a 0a 00 ff 00 2c 01 48 00 40 45 52 41 47 30 35 52 32 31 56 30 31 43 03 fe ff 04 44 01 ff 45 04 ff fb ff 0f 46 01 ff sapi=62 tei=62 <0005> abis_om2000.c:2533 Rx MO=CF/00/ff/00 Start Result (80 80 00 28 00 8a 0a 00 ff 00 2c 01 48 00 40 45 52 41 47 30 35 52 32 31 56 30 31 43 03 fe ff 04 44 01 ff 45 04 ff fb ff 0f 46 01 ff ) <0005> abis_om2000.c:2369 Rx MO=CF/00/ff/00 Start Result, MO State: STARTED <0005> abis_om2000.c:1016 Tx MO=CF/00/ff/00 Start Result ACK Program received signal SIGSEGV, Segmentation fault. 0x00007ffff777c945 in osmo_fsm_inst_dispatch (fi=0x7e0d20, event=4, data=0x8a) at fsm.c:367 367 OSMO_ASSERT(fi->state < fsm->num_states); (gdb) bt #0 0x00007ffff777c945 in osmo_fsm_inst_dispatch (fi=0x7e0d20, event=4, data=0x8a) at fsm.c:367 #1 0x000000000042fdbe in om2k_mo_fsm_recvmsg (bts=<optimized out>, mo=<optimized out>, odm=<optimized out>) at abis_om2000.c:1813 #2 0x000000000043067a in abis_om2k_rcvmsg (msg=0x7e1630) at abis_om2000.c:2614 #3 0x00007ffff713c4a2 in e1inp_rx_ts (ts=0x7ce500, msg=0x7e1630, tei=16 '\020', sapi=0 '\000') at e1_input.c:560 #4 0x00007ffff71447ef in send_dlsap (dp=0x7fffffffe6f0, lctx=<optimized out>) at input/lapd.c:636 #5 0x00007ffff79aa249 in send_dl_l3 (msg=<optimized out>, lctx=<optimized out>, op=<optimized out>, prim=<optimized out>) at lapd_core.c:362 #6 lapd_rx_i (lctx=<optimized out>, msg=<optimized out>) at lapd_core.c:1557 #7 lapd_ph_data_ind (msg=0x7e1630, lctx=0x7fffffffe760) at lapd_core.c:1653 #8 0x00007ffff7144e0f in lapd_receive (li=0x7cd3b0, msg=0x7e1630, error=0x7fffffffe7cc) at input/lapd.c:461 #9 0x00007ffff713c84d in e1inp_rx_ts_lapd (e1i_ts=0x7ce500, msg=0x7e1630) at e1_input.c:604 #10 0x00007ffff714048f in handle_ts1_read (bfd=<optimized out>) at input/dahdi.c:191 #11 dahdi_fd_cb (bfd=0x7ceaa0, what=1) at input/dahdi.c:495 #12 0x00007ffff7779b62 in osmo_fd_disp_fds (_eset=0x7fffffffe980, _wset=0x7fffffffe900, _rset=0x7fffffffe880) at select.c:149 #13 osmo_select_main (polling=polling@entry=0) at select.c:189 #14 0x0000000000406f7c in main (argc=1, argv=<optimized out>) at bsc_hack.c:385
I suspect that fi->state is invalid here.
Apart from this, everything looks good. I am able to boot the BTS and when I try a location update i get an entry in hlr.sqlite3.
On Mon, Nov 07, 2016 at 03:28:31PM +0000, dexter [REDMINE] wrote:
I have catched up with neels and we resolved the conflict with his dyn-pdch patch.
yes, but you still need to re-submit the patch series, as it cannot be
merged as it depends on a now-abandoned patch. pleas re-push asap so we
can get this merged.
- Harald Welte <firstname.lastname@example.org> http://laforge.gnumonks.org/ ============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)