目錄

問題

答案

相關思科支援社群討論

問題

崩潰清單中顯示的崩潰與已看到的崩潰相同的原因是什麼？

答案

分析以下兩個sessmgr進程崩潰時，您可能會認為它們是相同的，並想知道系統為什麼將它們分別列在崩潰清單中。在仔細觀察時，請注意show crash number X輸出最左側的列中的地址略有不同，這是代碼中的點，在該點上，同一行上的函式呼叫上面列出的函式(本例中為snx_hgwdrv_send_add_sub_session())。

******** show crash list *******

Friday October 03 18:25:28 UTC 2014

==         ====         =======  ========== =========== ================

#          Time         Process   Card/CPU/     SW         HW_SER_NUM

PID      VERSION   SMC / Crash Card

==         ====         =======  ========== =========== ================

1  2013-Nov-30+05:08:15 sessmgr  07/0/04317 14.1(50455) SAD160200KX/PLB31103947

2  2014-Jun-06+16:45:44 sessmgr  05/0/06002 15.0(53417) SAD160200KX/PLB37108248

3  2014-Oct-02+08:08:03 sessmgr  15/0/06059 16.1(55894) SAD160200KX/PLB42100206

4  2014-Oct-03+03:02:00 sessmgr  02/0/05979 16.1(55894) SAD160200KX/PLB38108892

Total Crashes : 12

********************* CRASH #03 ***********************

SW Version          : 16.1(55894)

Similar Crash Count : 1

Time of First Crash : 2014-Oct-02+08:08:03

Fatal Signal 11: Segmentation fault

PC: [0534bf6d/X] sessmgr_imsa_update_ip_addr()

Faulty address: (nil)

Signal from: kernel

Signal detail: address not mapped to object

Process: card=15 cpu=0 arch=X pid=6059 cpu=~0% argv0=sessmgr

Crash time: 2014-Oct-02+08:08:03 UTC

Recent errno: 11 Resource temporarily unavailable

Stack (64280@0xfffee000):

[0534bf6d/X] sessmgr_imsa_update_ip_addr() sp=0xfffee7d8

[0365f41d/X] sessmgr_mag_handle_add_sub_session() sp=0xfffee928

[036f3a66/X] smgr_fsm_state_connected() sp=0xffffaff8

[03681397/X] smgr_callline_fsm() sp=0xffffb098

[05d8089b/X] sessmgr_app_svr_event_control_dispatch() sp=0xffffb628

[0461986b/X] snx_hsgwdrv_send_add_sub_session() sp=0xffffbba8

[0461dfa6/X] snx_hsgwdrv_fsm() sp=0xffffbd68

[04621cba/X] snx_hsgwdrv_event_control_dispatch() sp=0xffffbdf8

[046032b6/X] snx_pppdrv_notify_vsncp_up() sp=0xffffbe28

[046036ac/X] snx_pppdrv_fsm_state_connected() sp=0xffffbe68

[0460446a/X] snx_pppdrv_fsm() sp=0xffffbfe8

[04608e0a/X] mlppp_event_indication() sp=0xffffc328

[0514d1ae/X] VSNCPNotify() sp=0xffffc388

[0515e88d/X] NCPRunStateActions() sp=0xffffc3e8

[0515ae53/X] ProcessConfigData() sp=0xffffc488

[0515b9ec/X] ProcessNCP() sp=0xffffc4b8

[05144931/X] MLPSwitch() sp=0xffffc558

[05167c5c/X] PPPSwitch() sp=0xffffc768

[05e47033/X] DoSomethingWithData.isra.149() sp=0xffffcc78

[05e5a1ea/X] sessmgr_med_rp_a10_data_receive() sp=0xffffd3f8

[0600880d/X] sessmgr_med_data_receive() sp=0xffffd598

[0ac565ac/X] sn_epoll_run_events() sp=0xffffd5e8

[0ac5aca8/X] sn_loop_run() sp=0xffffda98

[0a9fd96d/X] main() sp=0xffffdb08

********************* CRASH #04 ***********************

SW Version          : 16.1(55894)

Similar Crash Count : 9

Time of First Crash : 2014-Oct-02+07:31:35

Fatal Signal 11: Segmentation fault

PC: [0534bf6d/X] sessmgr_imsa_update_ip_addr()

Faulty address: (nil)

Signal from: kernel

Signal detail: address not mapped to object

Process: card=2 cpu=0 arch=X pid=5979 cpu=~4% argv0=sessmgr

Crash time: 2014-Oct-03+03:02:00 UTC

Recent errno: 11 Resource temporarily unavailable

Stack (64280@0xfffee000):

[0534bf6d/X] sessmgr_imsa_update_ip_addr() sp=0xfffee7d8

[0365f41d/X] sessmgr_mag_handle_add_sub_session() sp=0xfffee928

[036f3a66/X] smgr_fsm_state_connected() sp=0xffffaff8

[03681397/X] smgr_callline_fsm() sp=0xffffb098

[05d8089b/X] sessmgr_app_svr_event_control_dispatch() sp=0xffffb628

[0461986b/X] snx_hsgwdrv_send_add_sub_session() sp=0xffffbba8

[0461dd33/X] snx_hsgwdrv_fsm() sp=0xffffbd68

[04621cba/X] snx_hsgwdrv_event_control_dispatch() sp=0xffffbdf8

[046032b6/X] snx_pppdrv_notify_vsncp_up() sp=0xffffbe28

[046036ac/X] snx_pppdrv_fsm_state_connected() sp=0xffffbe68

[0460446a/X] snx_pppdrv_fsm() sp=0xffffbfe8

[04608e0a/X] mlppp_event_indication() sp=0xffffc328

[0514d1ae/X] VSNCPNotify() sp=0xffffc388

[0515e88d/X] NCPRunStateActions() sp=0xffffc3e8

[0515ae53/X] ProcessConfigData() sp=0xffffc488

[0515b9ec/X] ProcessNCP() sp=0xffffc4b8

[05144931/X] MLPSwitch() sp=0xffffc558

[05167c5c/X] PPPSwitch() sp=0xffffc768

[05e47033/X] DoSomethingWithData.isra.149() sp=0xffffcc78

[05e5a1ea/X] sessmgr_med_rp_a10_data_receive() sp=0xffffd3f8

[0600880d/X] sessmgr_med_data_receive() sp=0xffffd598

[0ac565ac/X] sn_epoll_run_events() sp=0xffffd5e8

[0ac5aca8/X] sn_loop_run() sp=0xffffda98

[0a9fd96d/X] main() sp=0xffffdb08

這裡的一點是，由於函式呼叫是從代碼的不同位置發出的，因此這些崩潰被列為單獨的崩潰。

在這些情況下，請與Cisco建立案例，以確認此類情形下崩潰的根本原因是否相同，這僅僅是因為不同的代碼流需要單獨的修復。