Soft error 는 메모리에서 일시적으로 발생하는 에러이다. ECC(error correction code) 가 OS 에서 구현되었을 때 영향을 받은 메모리 셀을 다시 쓰므로서 에러를 수정한다.
Hard error 는 한 셀이 영구적으로 손상되거나 올바른 정보를 갖을 수 없을 때 발생한다. 하드 에러를 가진 셀 값은 rewrite 할 수 없는 0 또는 1 값으로 고정이 된다. 이것은 sticky 에러로 알려져 있다.
ECC 는 데이터 손실에 직면했을 때 시스템 생존을 용이하게 하기 위해 고안되었다. 그 개념은 메모리에 저장 되어진 데이터 조각들은 데이터와 함께 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 이다.
BADWRITER and other outlaws
1. 때때로 한 시스템에 있는 여러 개의 메모리에서 soft errors를 보고 할 수 있다. 메시지가 같은 비트를 가리킨다면 각각의 메모리에서 에러이다. 이것은 어떤 다른 component가 실제적으로 bad 데이터를 RAM에 쓰며 물리적 메모리와 상관없이 같은 비트 어드레스에서 에러를 지속적으로 생성한다. 이 같은 패턴을 인식하면 troubleshooting 시에 다운 타임과 good DIMM을 교체하는 비용을 절감할 수 있다.
2. 하나의 DIMM 를 교체하고 같은 데이터 비트를 가진 에러가 지속될 때 시스템에 있는 다른 component가 메모리 에러를 야기 시키는 것이다.
3. Bad software code 또한 메모를 에러를 야기시킬 수 있다는 것도 명심해라.
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 를 야기시키는 실제적인 주체로 가정할 수 있다.
이올린에 북마크하기'Unix Solution > HP-UX Management' 카테고리의 다른 글
| Memory 관련 에러 (0) | 2007/12/14 |
|---|---|
| DNS Server Setting 방법 (0) | 2007/12/14 |
| Default Router 설정 (0) | 2007/12/14 |
| APA구성 시 주의점 (0) | 2007/12/14 |
| HP-UX Internal Disk Mirroring 방법 (0) | 2007/11/01 |
| Unix서버 시간 동기화 방법 (0) | 2007/10/26 |
