시스템 crash 분석 방법
시스템에 crash가 발생하여 crash dump가 만들어진 뒤에 SW 또는 HW 에 escalation을 하게 되는 경우에 대한 내용입니다.

[ System Crash의 종류 ]
  
- Panic     : Kernel의 여러 subsystem의 오류로 인한 crash .  예) spinlock, kalloc panic 등
- TOC       :  Application이나 시스템의 hang으로 판단되는 경우.   MC/SG에 의한 TOC
                 ==> TOC는 panic보다 분석이 훨씬 어려우므로 다음의 상황을 반드시 확인하셔서
                        RC로 알려주셔야 합니다.
                     1) console의 상태 : 단순한 console의 return이 느리거나 console이 먹통이 되는지..
                     2) remote access : 다른 시스템에서 ping이나 telnet등이 되는지 반드시 체크
                     3) 고객의 어떤 증상을 보고서 시스템이 hang되었다고 결정하였는지...
- HPMC    :  /var/tombstomes  디렉토리에 있는 ts99(PIM 정보) 파일을 보내셔야 합니다.


[ q4를 사용한 장애 분석 ]

모든 고객의 시스템에는 /usr/contrib/bin/q4 명령어가 설치되어 있습니다. 최신 버전의 q4와 q4 script를
사용해야지만 정확한 분석이 가능하지만, site에서 고객의 시스템에 설치되어 있는 q4를 사용하여
HPMC인지 panic인지를 충분하게 구별할 수 있습니다.

   # cd /var/adm/crash       : crash dump가 있는 디렉토리로 이동
   # ls
   crash.0      crash.1        : crash.x  의 숫자는 증가되고 가장 큰 것이 이번에 발생된 crash입니다.
   # cd crash.1
   # ls
   INDEX        image.1.0    image.1.1   image.1.2
   image.1.2   image.1.3    image.1.4   vmunix
   #
    # /usr/contrib/bin/q4  .        : 현재의 directory에 대하여 q4를 실행
   .....
   ....
   q4>  
    q4> trace event 0               : 이 명령을 실행하면 시스템의 crash의 원인이 panic인지 HPMC인지를 보                                             여 줍니다.
  
   q4> trace event 0
   stack trace for event 0
    crash event was  panic     : socket관련 panic의 sample입니다.
   panic+0x14                            
   report_trap_or_int_and_panic+0x80
   trap+0xdb8            
   nokgdb+0x8
   soo_select+0x10
   pollscan+0xa8
   poll+0x104
   syscall+0x480
   $syscallrtn+0x0  
  
  
   q4> trace event 0
   stack trace for event 0
    crash event was an HPMC      : HPMC인 경우입니다.
   skip_int_restore_crs2_0+0x8
   idle+0x3f4
   swidle_exit+0x0

이와 같이 HPMC인 경우에는 ts99 파일이나 logtool을 사용하여 장애가 발생한 부분을 체크하셔야 하고
HW CC에 call을 접수하여 확인하시기 바랍니다.