常见可能性

1.  刚做完系统出现此类现象，有可能是版本不支持；
2.  运行一段时间出现，有可能是smbus busy ，led 指令冲突无法管控；
3.  运行一段时间出现，LED 驱动丢失；
4.  运行一段时间出现，磁盘响应异常；
5.  运行很久设备，LED老化，无法管控。
6.  atrust系统通过纪云平台巡检自动打补丁后出现。
7.  设备断电，监控状态不对，需要重新加载驱动。

备注：atrust  不在这个范围内

步骤一：获取设备平台信息，dmi中family值和型号信息。

注：各产品线指令不一样，新老架构指令不一样

老架构设备 dmidecode -t 1 和dmidecode -t 2

C3000设备 AD：dmidecode_ex   aturst/AC/VPN:read_ hwinfo    

AF:c3000_hw_info    cat /var/run/hal_hw.info  sangfor_hw_info

 

对应型号在表格中找是否支持当前版本：https://www.kdocs.cn/l/cqBSCZ6AI7at，如family信息不对，需要重刷family信息，如版本不支持，则需要降低版本重刷，或者忽略告警，如版本支持，执行步骤二。

步骤二：检查led驱动程序在 lsmod |grep led ，如果不在需要重新加载对应管理程序（联系软件），或者重启系统自动加载；如果在，则尝试通过管理指令主动关闭指示灯，找软件支持。如果能正常关闭，观察使用。如果不能正常关闭，执行步骤三。

 

如果筛选led 没有回显信息，可以lsmod看看有没相关进程。

 

步骤三：检查dmesg 日志是否有smbus busy提示，进黑盒目录过滤，cat dmesg |grep -i smbus，如有smbus打印，C3000和C246 平台有相关脚本重置，见附件，可以考虑脚本重启。其他平台暂时没有，可以考虑临时重启设备。如无打印，执行步骤四。

 

步骤四：通过串口或者VGA ，或者dmesg 持续打印系统盘I/O错误信息，也会导致alarm灯常亮。如果有I/O 错误，初步怀疑磁盘离线或者响应异常， 需要断电重启恢复。如果没有io报错，执行步骤五。

 

 

步骤五：尝试卸载和重新加载led驱动，还是不成功，断电5分钟上电看能否恢复，恢复不了一年以上设备返修设备，一年内设备找硬件支持协助。

 

 

详细处理案例：

场景一 ，新做系统alarm灯常亮

检查版本：708FT

检查dmi：

 

检查版本支持情况：

 

发现正常family 值是 AD-1000-GA110 和AD-1000-GA120

当前设备值是 LM5500A

最终导致系统无法正常识别对应平台信息，提供对应led管控。

AD 乐研FT机型 可以通过修改dmidecode工具解决，

执行指令：cp  /usr/sbin/dmidecode_real  /usr/sbin/dmidecode 

或者将升级708R7FT也可以解决问题。

 

处理建议：重刷dmi中的family 值。

 

案例二：

设备使用一段时间后突然发现alarm灯常亮， 后台能访问

检查一：Sdsec-1000-I444M  对接版本，CSSP5.8.5_R1_Xsec5.0.2

系统支持 。

检查二：lsmod |grep led 无回显，同时客户还有另外一台设备，检查有对应LED进程。

 

判断为led 管理程序掉了，需要重新加载。

检查三：查找对应led管理程序路径

find / -name  *led*

 

检查四，重新加载对应程序，执行对应led管理程序驱动insmod /sf/modules/hwbypass/led_lihua-E5-2650V2_M7000.ko

重新检查led信息

 

处理方案：重新加载led相关驱动

 

案例三：

设备使用一段时间后突然发现alarm灯常亮， 后台能访问

检查一：设备型号支持对应版本

检查二：LED灯管理驱动在位

检查三：dmesg 日志有smbus busy

 

该现象可以通过复现脚本跑出来

恢复脚本reset_i2c_c3000 ，可以找硬件FAE 获取 或者见文档附件（使用有平台限制）

执行 chmod +x reset_i2c_c3000   和./reset_i2c_c3000即可

reset i2c.zip ( 0.01M  )

 

案例四：

设备使用一段时间后突然发现alarm灯常亮， 后台能访问

检查一：设备型号支持对应版本

检查二：LED灯管理驱动在位

检查三：message日志提示链接数上限

处理方案：关闭一些日志功能