Project

General

Profile

Actions

Feature #1819

closed

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

Added by laforge over 7 years ago. Updated over 7 years 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.

Actions #1

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.

Actions #2

Updated by laforge over 7 years ago

  • Target version set to RBS2000 with BSC-located PCU
Actions #3

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.

Actions #4

Updated by dexter over 7 years ago

  • Status changed from New to In Progress
Actions #5

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

Actions #6

Updated by dexter over 7 years ago

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

Actions #7

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

Actions #8

Updated by laforge over 7 years ago

  • Status changed from Resolved to Closed
Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)