锐捷N18010 FE卡心跳超时导致重启
一、故障现象描述
设备型号版本:N18010 RGOS 11.0(4)B3
设备运行过程中FE3突然提示硬件心跳超时:并对该FE卡进行了复位重启,由于现场为VSU组网并存在多张FE卡冗余,暂未影响到业务。
*May 31 2024 08:52:26.128: %KEEPALIVE-3-MODULE_TIMEOUT: (*2/M1) Module in slot FE3 keepalive timeout.
*May 31 2024 08:52:26.130: %DP-3-RESET_MODULE: (*2/M1) Reset module 2/FE3 due to hardware heartbeat timeout.
二、故障排查分析
-
5月31日,设备运行过程中FE3突然心跳超时线卡重启。

-
收集信息发现FE3存在coredump,时间和FE3重启时间一致,基本确认是coredunp 导致FE3线卡重启。

-
研发侧收集故障FE卡的coredump文件并解析,发现coredump死在系统链表108行。

-
对比故障现象及内部处理记录,发现该coredump与2018年1月6号出现的18K FE1线卡KA超时的coredump死机节点一致。确认是同一个问题故障复发。

三、故障根因说明
该已知问题定位的原因是编译工具链版本较老。
分析工具链glibc的修订, 发现sdk2.3 build128有一处修订在sem_post()里面释放锁的原子量前后都加了syncw, 从代码修订来看,是临时修订.通过Cavium相关手册, 确定了write-buffer, sync, syncw等相关原理: CPU内每个核有2KB的Write Buffer, 通过sync*进行CPU核间数据的同步.其中syncw只同步写操作, sync读写操作都会同步。
继续分析sem_post()代码, 发现里面使用atomic_compare_and_exchange_bool_acq (&isem->value, cur + 1, cur)来操作原子量, 这个原子量函数宏里在原子量操作完后再执行syncw(相当于内存屏障), 这样无法保证原子量和前面的链表操作哪个先同步完成. 如果原子量先同步到其它核, 链表操作还未同步, 就会造成其它核获取信号量成功, 然后操作链表, 相当于信号量保护失效。
分析Cavium在SDK2.3代码,发现已修复该问题, 在SDK2.3 build 128和SDK2.3 build 137里sem_post()在操作原子量前先执行syncw操作, 保证链表写操作同步给其它核后, 再操作原子量释放信号量。
分析Cavium在SDK3.x里把sem_post()代码回退了, 只把sem_post()里atomic_compare_and_exchange_bool_acq()函数宏替换为atomic_compare_and_exchange_bool_rel(), 后者会先执行syncw, 保证临界资源的操作同步到其它核, 然后再做原子量操作, 效果也是一样。
结论:
当前版本glibc的sem_wait()/sem_post()用作互斥锁使用时, sem_post()存在多核内存屏障问题, 导致锁保护失效, 多线程并发访问临界资源。
四、故障解决方案
通用维护版本已解决改问题,建议升级到最新版本11.0(4)B19P2。
阅读剩余
版权声明:
作者:SE_You
链接:https://www.cnesa.cn/2607.html
文章版权归作者所有,未经允许请勿转载。
THE END