Bug #4169
closed
transition to state MSC_A_ST_RELEASING not permitted!
Added by fixeria over 4 years ago.
Updated about 2 years ago.
Description
We're running Osmocom based network at the CCCamp 2019. I noticed the following errors happening quite often:
Thu Aug 22 16:02:17 2019 DMSC ERROR libmsc/msc_a.c:361 msc_a(TMSI-0x58732EC1:GERAN-A-78442:LU)[0x55639470b3e0]{MSC_A_ST_RELEASING}: transition to state MSC_A_ST_RELEASING not permitted!
Thu Aug 22 16:03:48 2019 DMSC ERROR libmsc/msc_a.c:361 msc_a(TMSI-0xB162C8F3:UTRAN-Iu-78530:LU)[0x5563946ea770]{MSC_A_ST_RELEASING}: transition to state MSC_A_ST_RELEASING not permitted!
Thu Aug 22 16:04:30 2019 DMSC ERROR libmsc/msc_a.c:361 msc_a(TMSI-0x09641873:GERAN-A-78583:LU)[0x5563947fc510]{MSC_A_ST_RELEASING}: transition to state MSC_A_ST_RELEASING not permitted!
...
- Status changed from New to In Progress
- % Done changed from 0 to 90
this is not actually a real problem: msc_a is already in state MSC_A_ST_RELEASING, and for brevity there are no numerous checks whether the state is already ST_RELEASING when releasing an msc_a.
fixed for msc_a in https://gerrit.osmocom.org/c/osmo-msc/+/15389
In general, I would like to have osmo_fsm API that allows silencing these errors without extra constructs:
- osmo_fsm_inst_dispatch_if_permitted() -- dispatch an event, but be fine with it if the current state does not allow that event, omitting error logging.
- osmo_fsm_inst_ensure_state() -- only change if not already in that state.
Been in my wishlist every now and then, never wrote a patch though.
- Status changed from In Progress to Resolved
- Assignee set to neels
- % Done changed from 90 to 100
The fix has been merged long time ago. No such messages seen anymore.
Also available in: Atom
PDF
