Chinaunix首页 | 论坛 | 博客
  • 博客访问: 322226
  • 博文数量: 25
  • 博客积分: 375
  • 博客等级: 一等列兵
  • 技术积分: 1260
  • 用 户 组: 普通用户
  • 注册时间: 2011-05-17 16:39
个人简介

喜欢IT的一个“武痴”! 喜欢追求新技术、探索技术!

文章分类
文章存档

2019年(1)

2014年(2)

2013年(11)

2012年(11)

分类: 系统运维

2012-12-13 09:09:22

 
 
 

Sun服务器在运行过程中经常出现Panic的现象,查看log会发现类似UECEWDCUCC等等错误事件,这些错误信息基本上都跟cpu/memory有关,软件或硬件引故障都会引该类型的错误发生。

该博客发布后,文档格式全变了,请参考我发布在豆丁的文档:

 
 

内存故障类型及处理

1CEcorrected error)类错误

该类错一般分为soft errorshard errors两种,soft errors错误指内存的某一个位(bit)通过ECC校验发现存在错误并加以纠正,该类错误是暂时性的,所谓暂时性就是指内存该字节的错误位纠错后就可以正确使用了。

Hard errors一般指硬件类的错误,该种错误发生时,内存某个存储单元里的一个位永远为01,该错误是因为内存的某个位硬件永久性损坏了导致的。

 

2UE(Uncorrectable Errors)类错误

UE类错一般会引起cpupanic,当CE类错被检测时内存存储单元某个位出现了错误,如果此时同一个存储单元另一个位出现错误的话,就会产生一个UE(Uncorrectable Errors)类的错误,或者内存一个字某位出错了,但是系统无法纠正时我们仍把它叫做UE类错,为了保证系统的可靠性和数据的准确性,OS极有可能reboot系统。

 

3.如何得到更为详尽的内存错误信息

kernal update 21(即1085280-21)的solaris 8可以将出错的cpu offline掉,还可以执行page Retirement的操作(特别是在出现CE类问题并同时出现ME,即UE mutil bit类错误的时候),该操作将禁止使用相关的故障内存,这需要在/etc/system文件加入以下的一行:

automatic_page_removal=1

我们UT现场很多系统版本比较低,所以这些参数设置在低版本的kernel不能起作用,建议有机会最好都能升级上来。

以下的参数可以帮助我们记录更详细内存出错log

Variables

Values

set ce_verbose_memory=[0/1/2]

set ce_verbose_other=[0/1/2]

A value of 0 indicates no logging. A value of 1 indicates that the messages are sent to the log file, but not the console. A value of 2 indicates that the messages are sent to the console and the log file. The default value is 1.

set automatic_page_removal=[0/1]

A value of 0 disables the page retirement feature. A value of 1 enables the page retirement feature. The default value depends upon the kernel patch release

set ecc_softerr_interval=1440

set ecc_softerr_limit=2

The interval measured in minutes and number of acceptable CEs within this interval. Used by the Leaky Bucket algorithm to determine when to begin page retirement. It is acceptable to have ecc_softerr_limit CEs within ecc_softerr_interval minutes. Beyond this threshold, begin page retirement. These values are the defaults.

set max_pages_retired_bps=10

Limits the number of physical memory pages which can be retired. This number is a percentage of physical memory stored as basis points, where 100 basis points is 1%. The default is 10, or.1% of physical memory.

 

4Scrubber

CE类错误纠正的实现是靠solaris的一个叫Scrubs的程序来完成的,Scrubs进程是通过重写内存字来实现纠错的。如果CPU在访问一个内存单元发现了错误,该程序就会将错误内存字擦除掉然后写入一个正确的字并记录下这个事件而报告相关信息到messages文件里面。

内存的错误有以下几种类型:

a.       "Intermittent" – 间歇性error

这种错误是个常见的传输错,是个软错误,这种错发生时候,一般内存硬件都没有问题,无需更换b.  "Persistent" – 持久性error这种错误是CPU在访问的时候检测到了错误,但是已经由scrubber纠正了。这种错误基本上都是一个暂时性的软故障,无需更换任何内存。c.  "Sticky"- 顽固性error

这种错误是在scrubber程序已经檫除重写后仍然存在错误位的一种情况。如果此种错误发生的话,一般建议立即更换相关内存条来防止系统出现异常。

以上的内存出错都能在messages文件里找到IntermittentPersistentSticky等关键字。

 

CPU出错类型

CPU的故障是最难辨别的,一般来说,系统messages文件都会报告某一个事件发生在某某cpu上,错误信息有点类似于内存错,但绝对不会出现具体的内存问题那样的信息。另外就是大多数机器直接crash掉,不报告任何错误信息,比如 Netra 1120,Netra 1400,甚至Netra 20也是这样,1400N20的基本上还能通过lom –a的输出中查找一下lom事件,如果有watchdog重置的事件发生的话,基本上可以判断为cpu的故障,在SMP的架构中一般系统都会有好几颗CPUUT的机器一般至少有两颗CPU,如何判断是哪个CPU呢,按我们的经验,一般都是cpu0出现故障才会导致系统的crash

     如果在messages文件里出现类似于CBB/CBI, DBB/DBI这样的信息的时候,基本上都跟cpuE-cache有关,该类型的错误无需用户关心,E-cache Scrubber程序在纠错后都会发送相关事件信息系统log文件里这几个事件的具体解释如下clean_bad_idle : CBI event clean_bad_busy : CBB event dirty_bad_idle : DBI event dirty_bad_busy : DBB event      CPU有很多事件信息经常在messages文件里出现,因为这些事件警告级别都是kernel.info级的,只是告诉用户在CPU上曾经发生过这样的事情,一般来说,只要系统没有crash掉,就无需进行处理,对系统来说应该没有任何影响。CPU故障最为典型的是,系统在启动的时候,出现banner以后,就一直报一下的错误:ERROR: CPU0 RED State Exception    System State (CPU0 reporting)    CPU0 Config/Control/Status registers:    CPUVersion:  003e.0014.5400.0507    SafConfig:   0caa.01bc.0000.8002    SafBaseAdr:  0000.0400.0000.0000    DCacheCtl:   0000.0000.0000.0000    ECacheCtl:   0000.0000.0009.4400    ECErrEnable: 0000.0000.0000.0000     AFAR:        0000.0040.ffc0.0d10    AFSR:        0030.0600.0000.00a0 Multiple PRIV UCC UCU                                                          DMMU SFAR:   0000.07ff.fff8.0100    DMMU SFSR:   0000.0000.0004.802c TM CT1 PR W    IMMU SFSR:   0000.0000.0080.8008 TM PR如果出现这种错的话,基本上可以判断为cpu故障,无需再考虑其他了,另外还有就是RED State Exception也经常出现在某根内存故障的时候,所以同样的错误,仍然需要进行区别。/etc/system文件里设置ecache_scrub_verbose=1能详细记录scrubber程序工作的信息,包括dirty,clean位的具体信息。 其他如果内存出错的话,有时候也导致系统能够无法引导,一般会报以下两种错:1.Fast Data Access MMU Miss该错误出现的时候,也有很多种情况,有的是正常的,比如V880,V480等一些SPARC III的机器,在banner出现后初始化内存按ctrl+braak 时候就会可能导致此错误的出现,此时的boot命令是被disable的。大多情况下该内存确实是存在问题了,系统boot的时候就会报此错误,河南新乡的V480就出现过该故障,系统无法完成引导,直接进ok 然后报告Fast Data Access MMU Miss,拔除故障内存后,系统可以完成引导!2. Corected Ecc error      这个信息如果出现在boot期间,并且根本无法引导系统,那么可以肯定是内存有问题。每个故障都会有自己的特点,一定要仔细阅读出错信息,有时候出错信息都比较类似,常常导致误判,所以一定要多加思考和大胆预测才能很好的解决问题。           
 参考文献:1. Sun公司的相关InfoDoc2. UT case 处理mail.
 
 
阅读(3629) | 评论(0) | 转发(1) |
给主人留下些什么吧!~~