Cisco Bug: CSCus63874 - Assertion at Function: mme_app_send_s11_modify_brr_req()
Feb 15, 2017
- Cisco ASR 5000 Series
Known Affected Releases
Assertion failure at sess/mme/mme-app/app/mme_app_util.c:13704 Function: mme_app_send_s11_modify_brr_req() Expression: sn_status != SN_STATUS_FAILURE Symptom: Assertion failure at sess/mme/mme-app/app/mme_app_util.c:13704 Function: mme_app_send_s11_modify_brr_req() Expression: sn_status != SN_STATUS_FAILURE Proclet: sessmgr (f=87000,i=89) Process: card=8 cpu=1 arch=X pid=7874 cpu=~23% argv0=sessmgr Crash time: 2015-Jan-25+07:34:14 UTC Recent errno: 11 Resource temporarily unavailable Stack (60168@0xfffef000): [ffffe430/X] __kernel_vsyscall() sp=0xfffefef8 [0b06c5cf/X] sn_assert() sp=0xfffeff38 [08036da2/X] mme_app_send_s11_modify_brr_req() sp=0xffffcd08 [080dd87a/X] mme_s1ho_to4g_arca_handle_reloc_complete_ack() sp=0xffffcd98 [080ddde0/X] mme_s1ho_to4g_arca_handle_peer_path_failure() sp=0xffffcdb8 [0808a0a2/X] mme_fsm_event_handler() sp=0xffffd268 [080b90f3/X] mme_event_handler_s1ho_gen_to_4g_procedure() sp=0xffffd2a8 [07f853a0/X] mme_procedure_handle_event() sp=0xffffd328 [080bc921/X] mme_disp_handle_emm_evt() sp=0xffffd428 [080bcf06/X] mme_s1ho_to4g_peer_path_failure_tmr_expiry() sp=0xffffd4a8 [0536c414/X] tlib_serv() sp=0xffffd4f8 [0536c054/X] tlib_tmr_tick() sp=0xffffd548 [048d4262/X] snx_timer_service() sp=0xffffd558 [048d216f/X] snx_fast_service() sp=0xffffd588 [05fc153a/X] sessmgr_snx_tick_callback() sp=0xffffd5c8 [0b10e3ba/X] sn_loop_run() sp=0xffffda88 [0ae1236d/X] main() sp=0xffffdaf8 Registers: Conditions: MME received HO Notify as part of S1 Handover progress over S3 interface with same SGW (2 PDNS - 1 being emergency PDN). MME sent Forward Relocation complete awaiting Acknowledgement. Internal Peer (s3) path failure timeout fires. MME treats S3 path failure as Fwd Reloc Complete Ack and attempts to send Modify Bearer Request to SGW. However, the MME app SGW bearer state is MME_EGTPC_STATE_INACTIVE (21). This was not expected and thus, resulted in a failure. QA testing environment: After overnight run, chassis gets reloaded, and stargen and sitt instances does not stop. Also, after chassis comes up, sitt instances automatically start because it is running and call comes up (2G and 3G). No MME calls come up because lattice process loses association with chassis. Therefore, all lattice instances, which ran earlier stops and the call-models start again. This brings up 10k ENBs immediately, which results in a crash. This is a timing based crash, which is not easily reproducible.
Bug details contain sensitive information and therefore require a Cisco.com account to be viewed.
Bug Details Include
- Full Description (including symptoms, conditions and workarounds)
- Known Fixed Releases
- Related Community Discussions
- Number of Related Support Cases