概要设计
sent echo reply, src B, dst A, len 40”的报文，如果有则说明被ping设备的icmp层面发出了ping应答报文，这时候需要继续检查ip以及以下层面是否将报文发出，具体方法与步骤1“检查ping出设备是否将ping请求报文发出”类似。
4、如果上述调试信息说明被ping端发出了ping应答报文，需要检查ping出设备是否收到了ping应答报文，这与步骤2“检查被ping设备软件层面是否收到ping请求报文”类似，但具体操作分为两部分，其中分布式系统中从步骤a开始调试，非分布式系统从步骤b开始调试：
a) 分布式系统中：ping应答报文被线卡收到后，线卡会将报文递交给主控处理，这时在
线卡上debug ip packet时应该看到类似“IP: 0,src=B (VLAN32), dst=A (VLAN32), len=78, rcvd”和“IP: 0,src=B (VLAN32), dst=A, len=78, pass to msu”的调试信息，这表示线卡收到了报文并把报文送到了主控板。如果没有看到“rcvd”日志，则说明ping出设备的线卡没有收到被ping设备发出的ping应答报文，这时需要参考步骤2中的方法检查l2、vlan、生成树、交换芯片等有关信息；如果有“rcvd”日志但没有“pass to msu”日志，则说明ip处理出现了故障。
b) 分布式系统中看到了“pass to msu”日志，或者非分布式系统中，需要在被ping设备
主控板上查看报文接收情况，这时与步骤2的调试方法完全相同。如果收到正确的ping应答报文仍然ping不通，有可能是因为收到icmp应答时ping已经超时，这种情况建议增加主ping端的超时时间（-w选项）重新尝试，看看能否ping通。
4.5 Arp老化过快
在设备使用中有时会出现arp学到后立即消失的情况，例如debug arp时看到了收到arp应答的调试信息，但马上有看到了arp被删除的信息，或者show arp看不到相应的arp信息。出现这种情况，最有可能的原因就是mac地址老化，三层交换机中arp会定期检查mac地址的情况，如果对应的mac地址老化，arp将被删除，而mac地址再次学到时arp却未必能够立即学到，因为mac地址学习直接由交换芯片完成，而arp学习必须通过软件层面收发arp报文完成。这也导致了arp学到后立即被删除，但show mac addr时看到mac地址仍然存在。
这种故障通常使用全局命令arp retry-allarp通常可以规避，该命令的原理是，arp发现mac地址老化时并不立即删除arp条目，而是发送一个arp请求，如果一定时间（默认是45秒）内未能收到应答才会删除arp；因为arp对应的主机仍然在网络中存在，因而它会应答arp，从而避免arp被删除。
上述规避方法的弊端是会导致网络中出现大量的arp报文，因此我们还是需要彻底解决问题。mac地址频繁被老化的根本原因一般是网络中生成树震荡，例如经常从其他交换机收到topo change报文，这时应该从生成树方面查找原因。
273935858.doc Version1.4T (错误！未指定书签。) Page 21 of 27
概要设计
5. PPC异常处理
5.1 PPC函数调用原理
为了更好的分析异常现场信息，我们有必要先介绍一下PowerPC处理器在函数调用等方面的工作原理。PPC使用bl（blrl、bctrl等）类指令实现函数调用，它的作用是跳转至目的（bl：操作数/blrl：lr寄存器/bctrl：ctr寄存器）指令，并将返回地址（一般是主调函数中跳转指令的下一条指令地址）装入寄存器lr。这时根据被调函数可以分为两种情况： 1、 被调函数扇出非零，则在被调函数入口处会将lr寄存器的值保存在主调函数堆栈中LR的位
置，此时根据该值即可找到对应的函数
2、 被调函数扇出为零，这种情况只能发生在栈顶函数，此时堆栈frame中LR值是无效的 无论上述何种情况，show break显示的异常调用栈中顶级堆栈frame中LR的值都没有参考意义。 结合本节中描述的两种情况和3.2节中描述的两种情况，异常共分为下面三种情况： 1、 当前函数（即出现异常的函数）扇出为零
2、 当前函数扇出非零，但本次执行至异常时尚未调用过其它函数 3、 当前函数扇出非零，且本次执行至异常时已经调用过其它函数
我们假设函数main调用了函数sub，那么在sub的本次执行过程中尚未调用其它函数时LR保存了main中调用sub的指令地址，此时LR与PC不属于同一个函数；在sub调用其它函数后LR则保存了sub内上次调用点的地址，此时LR与PC属于同一个函数。
根据PC与LR是否属于同一个函数，我们可以忽略函数的扇出而将异常简化为两种情况： 1、 当前函数本次执行至出现异常时，尚未调用其它函数 2、 当前函数本次执行至出现异常时，已经调用了其它函数
5.2 异常信息分析
5.2.1
异常信息组成
系统出现异常后，会有如下信息打印出来：
System Exception 0x300 Offset fffe000 Num 3 Task PIMD suspend
Exception 0x300 at program counter 00220118 , r1:04dbbd10 Link address is 002203f0
Machine status word is 00029230 Data address register is 00921f28
exception syndrome register is 00000000
instruction address resume register is 00000000
这表示系统出现了0x300异常，指令00220118执行了非法操作：它表示系统访问数据时试图执
行非法寻址操作（试图操作无法映射的地址、试图写只读地址，如指令段），dar表示试图非法操作的地址，本例中试图对00921f28地址进行操作。最后一行显示了任务名：PIMD。
当系统重新启动后，可以使用show break命令显示更详细的信息（为了说明，红色字体是新增的）：
S8510#sho break
=========================================================
273935858.doc Version1.4T (错误！未指定书签。) Page 22 of 27
概要设计
Exception Type:300-Data Access Interrupt BreakNum: 3
date: 2007-5-11 time: 17:6:7
R0 = 00220c4c R1 = 04dbbd10 R2 = 00000000 R3 = a6486190 R4 = 00000000 R5 = 00000000 R6 = 00000005 R7 = 00000000 R8 = 00000000 R9 = 00000064 R10 = 02000000 R11 = 00000000 R12 = 00000000 R13 = 00000000 R14 = 00000000 R15 = 00000000 R16 = 00000000 R17 = 00000000 R18 = 00000000 R19 = 00000000 R20 = 00000000 R21 = 00000000 R22 = 00000000 R23 = 00cf80b4 R24 = 09564fc0 R25 = 0a768888 R26 = 00000005 R27 = 00000000 R28 = 09564d68 R29 = 00764a68 R30 = a6486190 R31 = a6486190 MSR = 00029230 LR = 002203f0 CTR = 00697258 IP = 00220118 LR = ipacl_find IP = hash_char
dear = 00921f28 esr = 00000000 iarr = 00000000 call procedure--
0x00764a68--NOT FOUND 0x00220c4c--ipacl_check
0x001e8d54--kmrt_find_boundary 0x00230ce4--mbr_find_boundary
0x002a7f78--pimdm_state_refresh_timeout 0x002ac73c--pimdm_main
0x0032db3c--_sys_task_entrypt_wrapper 0x00690ba0--vxTaskEntry 0x00000000--NOT FOUND
Stack:
04dbbd10: 04dbbd20*00764a68 04dbbd48 a6486190 04dbbd20: 04dbbd40*00220c4c 00000000 00000000 04dbbd30: 00000000 e1000049 ffffffff 00000000 04dbbd40: 04dbbd70*001e8d54 e1000049 00000000 04dbbd50: 00000000 00000000 00000000 00000000 04dbbd60: 00000000 04dbc1b0 00000000 e1000049 04dbbd70: 04dbbd80*00230ce4 40000040 00cf8038 04dbbd80: 04dbbde0*002a7f78 00000000 00000000 04dbbd90: 00000000 00000000 00000000 00000000 04dbbda0: 00000000 00000000 00000000 00000000 04dbbdb0: ffffffff 04dbc1b0 04dbbdc0 00000000 04dbbdc0: 00000000 00000000 00000000 00000000 04dbbdd0: 00000000 002ac538 00cf8040 00cf8038 04dbbde0: 04dbbe00*002ac73c 1010000a 00000000 04dbbdf0: 00000000 00000000 04dbbf90 00badd08 04dbbe00: 04dbbf30*0032db3c 00000000 00000000
show break信息由三部分组成：前面部分是寄存器信息；中间call procedure部分是由调用栈分析得出的函数调用序列，下文中我们从上到下依次将call procedure中的地址记做CP[0]、CP[1]等，它们的调用关系是CP[i]调用CP[i-1]；后面stack部分是任务调用堆栈（格式同3.2节）。
273935858.doc Version1.4T (错误！未指定书签。) Page 23 of 27
概要设计
5.2.2 异常调用栈分析
开发人员对出现异常的模块非常熟悉时，完全可以通过经验和PC值推断出异常时函数调用序列。其它情况下可以通过本节介绍的方法推断出现异常时函数调用序列，进而分析异常的原因。
5.2.2.1 当前函数未调用其它函数
当break信息中LR和PC属于不同的函数时，该异常就属于这种情况，例如5.2.1中的例子。 此时寄存器信息中LR和PC两值含义为：IP表示产生异常的指令；当前函数未调用过其它函数，LR由当前函数的主调函数执行bl指令时保存，因此LR表示调用当前函数的那条指令。通过查找map可以得知IP属于函数hash_char，LR属于函数ipacl_find。
CP[0]由当前函数堆栈记录，由于当前函数未调用其它函数，故CP[0]无效。
若当前函数压栈，CP[1]由LR所在函数堆栈记录，它与LR相同。因此CP[0]、CP[1]是无效的。此时调用序列为CP[i]->CP[i-1]->??->CP[2]->LR->PC。
若当前函数不压栈，CP[0]由LR所在函数堆栈记录，它是无效的；但CP[1]有效。此时调用序列为（前面不变）CP[2]->CP[1]->LR->PC。
本例属于当前函数没有压栈的情况（见3.2，hash_char第一条指令为li而非stwu），这种情况下异常调用序列为??->ipacl_check->ipacl_find->hash_char
5.2.2.2 当前函数已经调用其它函数
当break信息中LR和PC属于相同函数时，该异常就属于这种情况。以下面的异常信息为例 Exception Type:300-Data Access Interrupt BreakNum: 2
date: 1970-1-1 time: 0:0:38
R0 = 00102cac R1 = 04fd11e0 R2 = 00000000 R3 = 00000003 R4 = 04fd16c2 R5 = 00000010 R6 = 00000000 R7 = 0fffffff R8 = 00000080 R9 = 00000000 R10 = fffffff0 R11 = 00102cd8 R12 = 00000010 R13 = 00000000 R14 = 00000000 R15 = 00000000 R16 = 00000000 R17 = 00000004 R18 = 00000000 R19 = 00000000 R20 = 00000000 R21 = 0098ef60 R22 = 00000002 R23 = 00711e58 R24 = 00102b64 R25 = 04fd14bc R26 = 00000000 R27 = 00000000 R28 = 00000000 R29 = 04fd1ac8 R30 = 04fd14bc R31 = 00000002 MSR = 00029230 LR = 00102cb8 CTR = 00102cd8 IP = 00102cdc LR = do_chram_mem_sys_addr IP = do_chram_mem_sys_addr dear = 0094b148 esr = 00000000 iarr = 04f04ec0 call procedure--
0x00102cac--do_chram_mem_sys_addr 0x001645d4--subcmd
0x00102d6c--do_chram_mem_sys 0x00165544--lookupcmd 0x00166150--cmdparse
0x00356978--vty_main_loop 0x00356d8c--vty
0x003333d0--_sys_task_entrypt_wrapper 0x0069dd20--vxTaskEntry
0x00000000--analyse fail: not found Stack:
273935858.doc Version1.4T (错误！未指定书签。) Page 24 of 27
概要设计
04fd11e0: 04fd1200 00102cac 00000010 00000000 04fd11f0: 04fd1ac8 00000000 00000000 00711e58 04fd1200: 04fd1250 001645d4 00000000 04fd1ac8 04fd1210: 04fd1cf0 00000000 00102d2c 00000003 04fd1220: 00000003 04fd14b8 00000000 0098ef60 04fd1230: 00000001 00000000 00000000 04fd1ac8 04fd1240: 00000001 04fd1ac8 04fd14b8 00000003 04fd1250: 04fd1270 00102d6c 00000000 04fd14b8 04fd1260: 00000003 00000000 04fd1ac8 00711ec0 04fd1270: 04fd12c0 00165544 00000023 00000073 04fd1280: 00000000 00000002 00000000 00000000 04fd1290: 00000000 00000000 00bd6e5c ffffffdf 04fd12a0: 0fa48b18 00000000 04fd198c 04fd1ac8 04fd12b0: 00000003 00000030 04fd16c4 00000000 04fd12c0: 04fd1970 00166150 63687200 00000000 04fd12d0: 00000000 00000000 00000000 0094b148
LR由当前函数执行bl指令调用其它函数时保存，故LR不属于调用序列。
若当前函数压栈，CP[0]属于当前函数堆栈frame，故它也是无效的，此时调用序列为??CP[1]->PC；若当前函数不压栈，则CP[0]属于当前函数的主调函数，此时它是有效的，调用序列为??->CP[1]->CP[0]->PC。
5.2.3 PPC背景资料
5.2.3.1 常见异常
0x300:DSI。最常见的情况是：启用了MMU的系统，当CPU进行数据存取操作寻址时，该地址只读而试图执行写操作、该地址不可访问而试图执行读写操作等情况会触发异常。一般指令端、readonly段等为只读。
0x200:machine check。最常见的情况是：未启用MMU的系统，当试图存取映射不到的内存地址时，CPU会触发MC异常。
0x400:ISI。最常见的情况是：启用了MMU的系统，当CPU取指令时，发现指令地址不可访问或不可执行。一般出现在blrl、bctrl等指令执行时lr、ctr寄存器中值错误。 0x600:对齐异常。某些指令要求操作数具有某些对齐要求（如4字节对齐等），当不满足该要求时产生。一般出现于这种情况：Gcc编译的代码进行64位数赋值时会借用双精度浮点寄存器中转，此时使用指令lfd、stfd等就要求操作数是4字节对齐的。为了避免这种情况，我们已经要求使用64位数时一定要使用
0x700:指令异常。CPU取到一条指令解码分析后，发现它不是一条合法指令。常见情况有：blrl、bctrl指令时寄存器中值错误、指令段被改写、常态试图执行管态指令等。
0x800:浮点不可用异常。在MSR[FP]为零的情况下试图执行浮点指令。这种异常极少见。 5.2.3.2 常见汇编代码样式
函数入参传递：r3~r11，寄存器不够则用堆栈 函数返回值传递：r3或r3+r4 取全局变量： lis rx,base lwz ry,offset(rx)
273935858.doc Version1.4T (错误！未指定书签。) Page 25 of 27