Feature #1819
closedre-base + test om2000-fsm branch to get it submitted
Added by laforge over 7 years ago. Updated over 7 years ago.
100%
Description
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.
Updated by laforge over 7 years ago
laforge/om2000-fsm has received two fixes and renders good results, but is old
laforge/om2000-rebase is my attempt at a rebase, but it's completely untested. Please continue this work.
Updated by laforge over 7 years ago
- Target version set to RBS2000 with BSC-located PCU
Updated by dexter over 7 years ago
- % 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.
Updated by dexter over 7 years ago
- Status changed from In Progress to Resolved
- % Done changed from 50 to 100
Changes are pushed to gerrit for review
Updated by dexter over 7 years ago
I have catched up with neels and we resolved the conflict with his dyn-pdch patch.
Updated by laforge over 7 years ago
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 <laforge@gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
IMPORTANT NOTICE: This page contains information about a legacy version of the Osmocom software. This legacy version is no longer maintained. If you use it, don't be surprised if it doesn't work. It was your choice to ignore man-years worth of developments, improvements and fixes. Please migrate to the active/supported software (Osmocom CNI, consisting of OsmoBSC, OsmoMSC, OsmoHLR, OsmoSTP, OsmoMGW - a NITB style setup is described at Osmocom_Network_In_The_Box).