[Solaris]  메모리 진단



Soft error 는 메모리에서 일시적으로 발생하는 에러이다. ECC(error correction code) 가 OS 에서 구현되었을 때 영향을 받은 메모리 셀을 다시 쓰므로서 에러를 수정한다.

Hard error 는 한 셀이 영구적으로 손상되거나 올바른 정보를 갖을 수 없을 때 발생한다. 하드 에러를 가진 셀 값은 rewrite 할 수 없는 0 또는 1 값으로 고정이 된다. 이것은 sticky 에러로 알려져 있다.

ECC 는 데이터 손실에 직면했을 때 시스템 생존을 용이하게 하기 위해 고안되었다. 그 개념은 메모리에 저장 되어진 데이터 조각들은 데이터와 함께 Check 정보도 갖는다. 이 Check 정보는 두 가지 용도를 제공한다.
· 첫 번째는 데이터 조각이 메모리에서 읽어질 때 Check 정보는 데이터 조각의 어떤 비트가 변화되었는지, 싱글 비트가 변화했는지, 다수의 비트가 변화하였는지 검출하는데 이용 할 수 있다.
· 두 번째는 싱글 비트가 바뀌었을 때, Check 정보는 데이터 조각의 어떤 비트가 바뀌 었는지 확인하고 바뀐 비트를 올바른 값으로 되돌려서 데이터 조각을 수정한다.

ECC check 알고리즘이 데이터 비트가 변화 되었다는 걸 감지 했을 때 이것은 ECC Error 로서 분류한다. 이 에러들은 에러 발생시 비트의 개수와 상관관계가 있다.
SUN의 ECC 체계는 싱글 비트는 보정할 수 있기 때문에 싱글 비트 에러는 CEs( Correctable Errors)이고 멀티 비트 에러는 UEs(Uncorrectable Errors)라 일컬어 진다.

솔라리스 작용
하 나의 CE 가 발견되었을 때 데이터 조각(word)를 읽고 이벤트를 검출한 디바이스는 데이터를 올바로 수정 할 수 있고 어떠한 인터럽트 없이 지속 가능하다. 그러나 참조된 데이터 조각이 수정되어지지 않은 채로 메모리에 계속 거주할 때 이 데이터에 대해 이어서 일어나는 read는 또 다른 CE event 의 결과를 초래한다.
시간이 흘러서 메모리에 있는 데이터 조각(word)이 결코 고쳐지지 않으면 같은 word에서 또 다른 비트에 에러를 발생할 수 있는 가능성이 있다. 이것을 UE event 이라 일컫는다. 이 가능성을 피하기 위해 하나의 CE 검출은 솔라시스에 한 개의 trap 를 일으킨다.

Note : 24시간 내에 같은 디바이스에 의하여 초래되는 3개 이상의 CE event는 용인할 수 없다. 즉 다시 말해 그 디바이스를 교체해야 한다.

ECC error count 는 /var/adm/messages 파일에 메시지를 뿌리기 전 256개의 error를 하나로 보면 /var/adm/messages 파일에 log를 기록한다.
Solaris 9 update-1 와 Solaris 8 update-16는 효율적으로 각각의 에러들이 messages 파일에 잠재적으로 기록된다. 또한 과도한 CE events를 관리자들에게 알려주고 최초의 새로운 특정 정보 메시지는 log 에 쓰여진다.

Solaris 9 KU1, Solaris8 8 KU16 은 messaging 과 count threshold 제어 하기 위해서 두 개의 새로운 파라미터( ecc_softerr_limit, ecc_softerr_interval)를 제시했다.
The count 가 ecc_softerr_limit 를 넘게 되면 정보 메시지가 /var/adm/messages 에 프린트 되어 진다.

예시] ecc_softerr_interval 기본값은 1440분(24시간)이고 ecc_softerr_limit 는 2 이다. 이 값은 /etc/system 파일에 엔트리를 추가함으로써 값은 바뀔 수 있다.

Set ecc_softerr_interval=2880
Set ecc_softerr_limit=3

Uncorrectable Errors

하 나의 UE 가 검출되었다면 데이터 조각(word)과 검출되어진 error를 읽은 디바이스는 data를 수정할 수 없다. 한 개의 UE는 그 UE가 커널 메모리에 존재한다면 솔라리스에 패닉을 야기시킬 것이다. 또는 에러 시에 메모리에 존재하는 특정 사용자 프로세스를 kill 를 야기 시킬 수 있고 그 다음 그 도메인에 있는 다른 프로세스들을 보호하기 위해 시스템을 shutdown 또는 리부팅 한다.

Memory scrubber
솔라리스는 또한 정상동작의 한부분으로서 메모리 “scrubber” 루틴를 구동한다. “scrubber”는 매 12시간마다 모든 메모리 위치가 액세스 되어지도록 하는 것 이외에는 특별한 어떤 일을 하는 것은 아니다. 그 액세스가 한 개의 CE를 발견했다면 어떤 CE에 대해 발생하는 normal trap 은 메모리에 올바른 정보를 다시 기입하여 잘못된 메모리 데이터 조각(word)를 올바르게 수정하고 event 를 messages 에 기입한다.

“intermittent” 는 영향을 받은 메모리 word를 재독시에 error 가 검출되지 않았다는 걸 의미한다. 이 CE 는 공통적으로 transient soft error 로서 알려져 있다. 이 같은 종류의 에러를 가진 DIMM(메모리)는 먼저 SER(soft error rate)를 검사하는 것 없이 교체를 고려해서는 안된다.

“persistent” 는 영향을 받은 메모리 word를 재독시에 error 가 검출되어 지지만 scrub 동작은 잘못 된 부분을 수정했다는 걸 의미한다. 이 CE는 일반적으로 tempory soft error로 알려져 있다. 이 같은 종류의 에러를 가진 DIMM(메모리)는 먼저 SER(soft error rate)를 검사하는 것 없이 교체를 고려해서는 안된다.

“sticky” 는 scrub 동작 후에도 메모리에 에러가 존재하는 걸 의미한다. 이 event는 하드웨어 에러 묘사가 있을 때 어떤 하드웨어 교체가 필요한지 확인하기 위하여 조사해야 한다. 이 CE 는 일반적으로 stuck-at hard error로 알려져 있다. “sticky error”를 가진 DIMM 는 첫번째 에러 후에 교체를 고려해야 한다.

Soft error는 자연적으로 발생하는 event이다. single bit soft CE는 멀티 비트 UE를 야기하는 현상도 가능하다. 그렇다고 해서 모든 UE를 가진 메모리를 교체하는 것은 최선 의 방법은 아니다. (나의 생각엔 교체하는 게 장래를 위해서도 더 낫다 고 생각한다.) 하나의 CE는 메모리 디바이스를 교체하기 위한 근거는 아니다. 실제로 SER(soft error rate), 시스템 특성과 시스템에서 메모리 양, 과 관련지어 시스템에 의하여 제기되는 soft CE 수를 예상해야 한다.

아래는 썬에서 CE/UE에 대한 DIMM 의 servicing 에 대한 Recommended 이다.  
· 24시간 내에 3개 이상의 soft CE가 같은 메모리의 같은 비트에서 발생했다면 soft CE(intermittent or persistent)를 가진 DIMM를 제거하라  
· 하나의 hard CE 가 DIMM 에서 발생했다면 hard CE (sticky)를 가진 DIMM 를 제거하라  
· 하나의 UE가 DIMM 에 의하여 야기 되었다면 UE를 가진 DIMM를 제거하라.

BADWRITER and other outlaws

1. 때때로 한 시스템에 있는 여러 개의 메모리에서 soft errors를 보고 할 수 있다. 메시지가 같은 비트를 가리킨다면 각각의 메모리에서 에러이다. 이것은 어떤 다른 component가 실제적으로 bad 데이터를 RAM에 쓰며 물리적 메모리와 상관없이 같은 비트 어드레스에서 에러를 지속적으로 생성한다. 이 같은 패턴을 인식하면 troubleshooting 시에 다운 타임과 good DIMM을 교체하는 비용을 절감할 수 있다.

2. 하나의 DIMM 를 교체하고 같은 데이터 비트를 가진 에러가 지속될 때 시스템에 있는 다른 component가 메모리 에러를 야기 시키는 것이다.

3. Bad software code 또한 메모를 에러를 야기시킬 수 있다는 것도 명심해라.  
· 어떤 CE 메모리 문제가 있을 때 가장 좋은 첫 단계는 같은 뱅크에 있는 또 다른 메모리를 의심되는 메모리와 바꾸는 것이다. 문제가 그 메모리에서 발생한다면 의심되는 메모리를 교체하고 문제가 같은 위치의 메모리에서 발생한다면 그것은 Bad DIMM 문제가 아니다.

E-cache Scrubber and CBI/CBB, DBB/DBI 메시지

솔 라리스의 모든 현재 버전들은 CPU ecache를 지우기 위한 커널 “scrubber” 를 포함한다. 그러나 이 코드는 UltraSPARC CPU’s 특정 타입에서만 가능하다. 예를 들면 UltraSPARC III+ 기반 시스템에서는 가능하지 않다. 커널 ecache scrubber 가 구동되는 지 확인하기 위해서 명령어 “kstat –n –ecache_kstat” 를 이용할 수 있다. 이 커널 scrubber 기능은 메모리 scrub 기능과 유사하다. SRAM 의 휘발성과 속도 때문에 scrub 동작은 매우 빈번 하게 발생한다. 모든 “stale(잘못된)” ecache 데이터는 scrubber 에 의하여 flush 되어진다. 싱글 비트 에러가 flush 되는 동안 e-cache에서 발견된다면 시스템 파일에 CBI/CBB/DBI /DBB 메시지가 업데이트 되어 진다. “bad” ecache의 네 가지 상태는 독립되어진 에러를 생성한다. “clean” cache는 수정되지 않는 캐쉬 값이고 “dirty” ecache는 정상동작 동안 원래의 값으로부터 수정되어진 값이다.

Clean_bad_idle : CBI event
Clean_bad_busy : CBB event
Dirty_bad_idle : DBI event
Dirty_bad_busy : DBB event

“ecache_scrub_verbose=1” 셋팅하는 것은 싱글 비트 패리티 에러가 발생할 때 모든 clean, dirty cache scrub 를 커널이 로그 기입하도록 한다.
CBI/CBB/DBI/DBB 로그 메시지들은 같은 ecache 위치에서 24시간 내에 3번의 카운트 가 발생하지 않는 다면 시스템 관리자의 부분으로써 어떤 행동도 취할 필요가 없다.
하나의 panic이 CBI/CBB/DBI/DBB 로그와 관련있다면 그 메시지에 있는 CPU 가 그 panic 를 야기시키는 실제적인 주체로 가정할 수 있다.