Project

General

Profile

Feature #1819

re-base + test om2000-fsm branch to get it submitted

Added by laforge 7 months ago. Updated 6 months ago.

Status:
Closed
Priority:
High
Assignee:
Category:
libbsc
Start date:
10/15/2016
Due date:
% Done:

100%

Resolution:
Spec Reference:

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.

History

#1 Updated by laforge 7 months 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.

#2 Updated by laforge 7 months ago

  • Target version set to RBS2000 with BSC-located PCU

#3 Updated by dexter 6 months 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.

#4 Updated by dexter 6 months ago

  • Status changed from New to In Progress

#5 Updated by dexter 6 months ago

  • Status changed from In Progress to Resolved
  • % Done changed from 50 to 100

Changes are pushed to gerrit for review

#6 Updated by dexter 6 months ago

I have catched up with neels and we resolved the conflict with his dyn-pdch patch.

#7 Updated by laforge 6 months 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 <> http://laforge.gnumonks.org/ ============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)

#8 Updated by laforge 6 months ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF