Subject : 시스템장애분석(savecore,hangup,Panic,watchdog-reset)

Description :

1. Setup savecore ( 1.X and 2.X )
2. Hangup
3. Panic
4. Watchdog Reset


		< 1. Setup savecore >



1. Solaris 1.X : How to setup savecore

1) Customizing /etc/rc.local
....
# Default is to not do a savecore
#
# mkdir -p /var/crash/`hostname`
# echo -n 'checking for crash dump... '
# intr savecore /var/crash/`hostname`
# echo '

2) Default is to not do a savecore.

# Default is to not do a savecore
#
mkdir -p /var/crash/`hostname`
echo -n 'checking for crash dump... '
intr savecore /var/crash/`hostname`
echo '

3) -p option of mkdir says to create the parent directories if they
  don't already exist.

4) Configuring a special dump device

- 우리는 벌써 dump device  에 대해서 이야기했고 primary swap device 가 보통
  dump device 로 사용된다는것을 알고 있다.

cf) config vmunix swap on sd1b
    config vmunix swap on dumps on sd2f


2. Solaris 2.X : How to setup savecore

1) Customizing /etc/rc2.d/S20sysetup
......
##
## Default is to not do a savecore
##
if [ ! -d /home/lsh/crash/`uname -n` ]
then mkdir -p /home/lsh/crash/`uname -n`
fi
                echo 'checking for crash dump...\c '
savecore /home/lsh/crash/`uname -n`
                echo ''
....

2) Displaying the dumpfile kernel variable via adb

hyundai3# adb -k /dev/ksyms /dev/mem
physmem 3e1a
dumpfile/20X
dumpfile:
dumpfile:       0               0               0               0
                2f646576        2f64736b        2f633074        33643073
                31000000        0               0               0
                0               0               0               0
                0               0               0               0
dumpfile+10/X
dumpfile+0x10:  2f646576
dumpfile+10/s
dumpfile+0x10:  /dev/dsk/c0t3d0s1
$q



		< 2. System Hangup>


1. What is a system hang ?

- System hangs 는 system admin 에게는 커다란 좌절이 될수가 있다.
  잠시동한 모든 sysetm admin 은 하나의 시스템을 보고 그것이 살아있고
  죽고, 상당히 속도가 늦어지는것을 보게되고 얼마후 "hung" system 을 
  보게된다. System hang 은 매우 다양한 종류의 원인을 가지고 있지만 그들은
  한가지 공통적인 징후를 드러낸다. 시스템은 더이상 완전하게 사용되지않는다.
  항상 시스템이 완전하게 사용될수가 없게되는 panics 과는 달리 system hang 은
  system resources 를 천천히 잡아먹어 마침내 완전하게 useless system 이 된다.

- kernel errors 를 볼때에 당신은 모든시스템이 core dump 로써 panic 을 유발하는
  문제를 일으키지는 않는다는것을 알게될것이다. 가끔은 시스템들은 hangup 이되고
  우리는 memeory 의 내용을 조사하기위하여 core dump 를 일으켜서 hang 을 만들게된
  원인을 알아보는것이 바랍직하다.

2. What conditions cause hangs ?

- system hang 의 일반적인 원인은 deadlock 또는 하나의 process 가 다른 process 
  에 의해 lock 되어있는 무엇인가를 waiting 하며 다른 process 는 처음 process
  가 lock 해놓은 resource 를 기다리는 상황이다.

- System hangs can also occur when resources dry up and the system has to sit
  around waiting for more resources before it can continue doing what was
  asked of it.

- 가끔, system 은 hardware problems 에 의해 hang  이 된다. 예를 들면,
  디스크 드라이버에 붙어있는 data transfer cable 의 문제는 system 과
  disk driver 사이의 communication problem 을 일으킨다.
  그 결과는 bus 를 hung 하게 만든다.

- application  이 loop 에 빠져 hangup 이 되었을때에 그 시스템의 다른 user 는
  영향을 받지않는다. 즉, 그 process 동안에 disk 를 먹거나 두개 또는 다른 
  kenel resource 를 먹지만 않는다면 hung program 이 그 system 의 나머지에게
  영향을 주지않는다.

- Hangs 은 다양한 조건에의해서 발생하며 서로다른 특성을 가지고 있다.

   * 우선 시스템은 hangup 되어있는 시스템으로부터 하나의 low-level ICMP request
   를 보내게하는 명령어인 ping 에도  응답을 하지않는 시스템이 있을수 있다.
   만약에 응답을 한다면 kernel 은 그 순간에도 network interrupts 에 대해 충분히
   인식하고 응답을 할수가 있다는것이다. 

   * 시스템은 keyboard 의 characters 에 echo 소리만 내거나 mouse movements 는
    있지만 입력되는 command 나 abort sequence 에 조차도 응답을 하지 않는경우가 
    있다. 이것은 process 가 계속수행전에 resources 에새해 availabel하게되기를
    기다리는 상황 , 즉 deadlocks 에 의한 hang up 일수 있다. 이경우에는 그 
    process 들은 결코 ready 상태가 되지않는다. ps 의 output 은 아마 D wait
    state 에 많은 process 를 볼수가 있을것이다.

   * 만약에 keyboard 의 echo 조차도 전혀없는 완벽한 hangup 인경우는 아마
    STREAMS problems 일수가 있다. 가끔 L1-A 조차도 이 경우에는 소용이 없다.

   *  Server systems 에서는  CPU B/D 상의 LEDs 가 그 시스템의 상태를 나타낸다. 
   정상적인 경우는 bounce 또는 regular moving light 이다. 만약에
   동작은 하지만 매우 속도가 늦을때에는 그 시스템은 매우 busy 상태이다.
   이것은 kernel 이 loop 이거나 하나 또는 그 이상의 modem lines 과 같은
   external device 로부터의 대량의 interrupt 때문이다.
   Frozon lights 는 H/W problem 을 나타낸다.

3. Capturing system hang information

- 대부분의 경우 hung system 의 crash dump 는 강제적일수가 있다. 그러나 이것은
  모든 system hang conditions 에 대해 not guaranteed.
  강제적으로 dump 를 하려면, 당신은 boot PROM monitor 로 내려야 한다.
  Suspending all current program execution. It`s L1-A.
  On systems using ASCII terminals for the console, usually the Break key can 
  be used to get to the boot PROM monitor.

- 모든 hang situations 이 interrupted 되지는 않는다. 만약, L1-A 가 작동을 하지
  않는다면 가끔 console keyboard 를 뽑거나 몇분동안 terminal 을 뽑는다.
  이 모든것이 실패로 돌아가면 시스템을 power down 하는수밖에 없다. 


4. Sun-4d

- psrinfo (print processor info) 와 psradm (processor admin)  command 는
  status display 와 multiprocessor system 의 control 에 유용함.

- sun4d system  ( SPARCserver 1000, SPARCcenter 2000) 은 시스템진단에 유용한
  특별한 H/W 특성외에 prtdiag 라는 새로운 command 가 있다.

- 두개의 서로다른 종류의 watchdog reset  이 있으나 보통 H/W problem 을 나타냄.
  시스템의 watch dog reset 은 보통 H/W error 에 의하므로 시스템을 reset 시킴.
  
- POST routines 은 watchdog reset 에 관한 information 을 저장하므로 
  prtdiag -v 라는 command 로써  확인 할수가 있다.

- A local CPU watchdog reset occurs when a single processor is reset due to
  a trap occuring when traps are disabled ( a  "standard" watchdog).
  The system drops into the OBP.




		< 3. Panic >


1.What happened ?

- Computers crash. It's just a fact of life.
  Depending on the H/W and S/W. 일부는 자주발생하고 일부는 전혀발생하지 않는다.

- UNIX 가 존재한이래로 UNIX system crash dump 를 분석하려는 사람이 많고
  이 사람들은 UNIX system 이 crash 후의 만들어진 files 으로부터 원인을 분석할
  수 있게 되었다.


2. What is a system crash ?

- UNIX  에 따르면 1970 1 월 1 일 자정으로부터 computer systems 은 crash 가 발생.
 
- System crash 는 종종 다음과 같은 조건에서 갑자기 system 이 사용할수 없게됨.
  ( System panics & bad traps, Watchdog resets, Dropping out to boot PROM)


3. What conditions cause panics ?

- 어떤이는 panics 을 혐오한다. 그들은 아마 시스템과 data integrity 를 
  안전장치(safeguards) 로 생각하는것 같다.

- 시스템 panic messages  는 두가지중의 한가지의 원인이다.
   software consistency check, hardware fault.

- 훌륭한 O/S programmer 는 system resources 의 integrity 의 checking 을 할때에
  그 code 내에 panic() routine 을 끼워넣어 referencing 과 manipulating 을 한다.
  예를들면,  시스템 프로그래머 의 program code 에서 지금현재 사용중이라고 
  알려진(marking) disk 의 한 block 을 이제 막 free up 시키려고 할때에 그는
  먼저 그 디스크가 아직도 사용중인것으로 mark 되어있는지를 검증할것이다.
  만약 그 block 이 갑자기 그가 free 하기전에 free 된것으로 mark 되어있고 그것을
  알았을때 그의 code 는 그것을 freeing 하면 안된다. 그러나 어떻게 그 block 이
  요술처럼 free 되었을까? 어떻게 , 어디에서, 무엇이 엄청나게 잘못되었는가?
  이때 panic() 을 call 하면서 system programmer 는 그 system 을 갑자기 중지시킬
  수 있으며 이렇게 함으로써 시스템을 보호하고 그 problem 이 발견될때까지
  추가적인 corruption 을 예방한다.

- panic() 은 오직 O/S 가 kernel mode 에 있을때만 call 된다.그러나 O/S 에 있어서
  bug 를 실험하는 어떠한 program 이라도 panic 을 일으킬수가 있다. 예를들면,
  debuggin 중인 새로운 device driver 를 사용하는 user program 에서 driver 가 
  사용될때마다 kernel mode 로 움직이게된다. 한번 kernel mode 에 있게되면, 
  panics 은 일어날수가 있다. 그의 program 이 panic 을 일으킨 것은 그 user 에게
  나타나게되지만 실제 그의 프로그램은 단지 panic 으로 유도하게 되는 events 의 
   trigger 가 된것이다. 즉 간단히 말하면, 만약 시스템이 panics 이 나면
  바로 시스템이 data 의 integrity or  data 의 corruption 이 의심되는 조건을
 감지했가 때문이다.

- data integrity concept 을 user level programming 의 관점에서 살펴보자.
  만약 당신이 하나의 화일을 open 하는 프로그램을 open() system call 을 사용하여
  프로그래밍한다면, 당신은 아마도 다음 단계를 넘어가기전에 실제로 open 이 성공
  했는가를 open() status 를 check 할것이다.만약 open() status 가 fail 이면
  당신의 program 은 아마 이 것을 report 하고 exit 하거나 새로운 file name 을
  위해 prompt 를 내거나 간단히 다음 course 의 action 을 취할것이다. 여기서
  만약 당신이 open() system call 로부터 넘어온 status 를  무시한다면 향후에 이
  line 에 와서는 어떠한 잠재적인 문제에 부딪힐것이다. 당신의 data integrity 는
  위험에 놓일것이다.

- 당신이 운전하는 자동차 는 panic() routine 과 비슷한 어떤것을 가지는가 ?
  만약 air bag 이 장착되어 있다면 답은 yes 이다. 당신의 차가  갑자기 앞 범퍼가
  high-speed collision 과 같은것을 감지했다면, air bag 이 부풀러져서 운전자를
  보호하게 될것이다.

-  Software(Kernel) 는 수많은 hardcoded validity tests 를 포함하고 있는데,
  이것은 invalid pointers 또는 impossible conditions before continuing 을
   checking 하게된다. panics 은 두가지 types  중에서 한가지가 될수있다.
   a regular panic messages, or an assertion 이다.
   - 이전부터의 panic messages 에 대해서는 당신이 보통 얻을수 있는것은
   messages 그 자체이다. 이것들은 unique 한 그 자체이며 정확히 그 문제를
   나타내 준다. 당신은 source code 내에서 그것을 한번 볼수가 있다.

- Assertion messages 는 "panic: assertion failed" 라는 messages 에 이어서
   erroneous condition을 나타내는 messages 를 console 에 prints 하는
   macro 로 부터 유래한다. 이 경우에, 관심있는 article 은 panic: 에 선행하는
   condition message 이며 이것은 test, file, 그리고 그 code 내에 line number
   를 나타낸다.

- 갑작스런 hardware traps  은 panics 을 일으킨다. 이것은 일반적으로
  kernel 로 부터의 invalid address 가 access 되는 경우이다.왜냐하면 OS 는
  page 되는것이 아니므로 kernel code 로 부터의 fault 는 즉각적인 죽음(immediate
  death) 의 원인이다. software panic messages 와 달리 hardware traps 은 정확한
  시스템의 상태를 나타내며 console 에 print 되는 traceback 으로 귀결된다.
  이것은 보통 또한 /var/adm/messages file 에 나타나게 된다.
 
- 보통 panics 는 hardware-related or detected fault 를 나타낸다.
   종류는.
    - trap : for any unexpected trap into or from kernel mode
    - bus error(Sun-3) : a kernle segmentation violation.
    - text fault : an attempt to fetch an instruction from a bad place.
    - data fault: generally an erroneous pointer
    - address alignment: also generally a bad pointer.
    - illegal instruction : possibly an attempt to execute "data"



4. A word about bad traps

- Computer system 은 H/W 에서 일어나지말아야 할 조건이 감지된다면 또한 crash 
  를 낸다. UNIX system에서 이러한 종류의 crash 를 "bad trap " 이라고하며
  system admin 의 관점에서 본다면 bad traps 과 S/W panics 는 동일한 방법으로
  다루어져야 한다. UNIX systems 은 하루에 수백만의 traps 을 수행한ㄷ.
  그래서 당신이 trap 을 듣게된다면 panic  이라고 하지말라. 그러나 드문경우에
  당신은 bad trap 을 만날수가 있다. 당신의 UNIX system 이 그렇다면 그것은
  panic() 을 invoke 할것이다.


- SPARC terms 에 있어서 trap 이라는것은 kernel code 로의 즉각적인 분기를
  일으킨다. 즉 정상적인 instructions  의 수행을 중단(interruption).
  이러한 interruption은 user request(a system call) 또는 일부external
  event ( a page fault, a disk interrupt, a keystroke) 가 원인이 될수있다.
  어떤 경우에도 interrupt 는 H/W 와 very low-level sofrware 에 의해
  processing  된다. 그래서 어떻게 traps 이 수행되고 어떻게 처리되는지에 대한
  것은  그 시스템의 architecure 를 이해해야한다. 
  CPU H/W 는 trap 의 type 을 인식하고 그것을  처리하기위해 정확한 위치를
  알려고 시도한다. kernel 은 적당한 trap handling code 가 미칠수 있도록
  확실히 하기위해 몇개의 control registers 를 setup 해야만 한다. 
  한번 시스템이 구동되고 user processes 가 running 되면, 하나의 trap 은
  kernel 이 하나의  user program 으로부터 control 을 갖게될 유일한 방법이된다.
  trap 이라는것은 하나의 user request 가 process되고 ( kernel 은 user program
  위에서 running) 하나의 device 가 control(kernel 은 몇개의 external request
  때문에 running) 되는 수단(means) 이다.

5. Kinds of traps

- 두개의 기본적인 trap 이 일어날수가 있는데 synchronous 와 asynchronous 이다.
  Synchronous trap 은 opeation  이거나 instruction 중에의해 발생할수있다.
  이것은 실제 trap instruction 이 될수도 있고 또는 bad address alignment,
  bad address(bus timeouts), illegal instructions, floating-point coprocessor 
  error 같은 H/W  error 일수도 있다. 이러한 traps 은 즉시 받아들여진다.
  즉, H/W 는 kernel space 을 위해 H/W 의 tracks 과 heads 내의  현재 instruction
  의 operation 을 중지시킨다.

- Asynchronous trap  은 processor 에서  어떤상태를 변경하기전에 발생한다.
  이리하여 그 trap 이 복구가능한 H/W fault 에 의해 일어났을때에는  그 
  instruction 은 한번 그  trap handling 이 끝났을때 그 문제로부터 recovery
  하기위해 restart  한다. page faults 는 좋은예이다.
  Asynchronous trap 은 언제나 request 될수가 있으며 하나의 instruction 이
  완전히 끝났을경우에만 processing 될수가 있다.
  이러한 traps 은 interrupts 와 같은 external events 에 의해 일어남.
  이 traps 은 instruction 의 operation 에는 영향을 미치지 않으며 단지 
  instruction stream 에서의 break(분기) 를 일으킨다. 이것은 마치
  kernel 에의 subroutine call 이  kernel 내에 눈에 보이지 않게 심어져 있는것
  과 같다.  

- 두가지traps 전부 user program  과 kernel 내부에서 수행될수가 있다.
  둘다  switch 를 kernle 또는 supervisor mode 로 분기시킬수가 있고 kernel trap
  code 로 controle 을 transfer 하며 여기서 software 가  그것에대해 할일을 결정.
  이리하여 user program 으로부터의 page fault 는 일반적으로 acceptable 하며
  kernel 은 적당한 page 를 load 할것이며 instruction 을 계속하게한다.
  kernel 로 부터의 page fault 는 그러나 bad news 이고 trap code 는 panic 으로서
  stop 하게 된다.

6. Trap sequence

- H/W 는 그 trap  이 synchronous fault 또는 asynchronous interrupt 이던간에
  operation 의 한 sequence 를 수행한다.
  interrupt requests, page faults, illegal instructions, or system calls 은
  모두 동일한 방법으로 handling 된다.
  trap recognition sequence 는 kernel 에게 control 을 전달하고 kernel 또는
  supervisor mode 로 trap 이 발생한 곳과 trap 의 종류에 관해서 save 된 
  information 을 가지고 들어간다.

- trap sequence as performed by the H/W looks like:
  1) Recognize the trap
  2) Get to a new window ( an implicit save instruction)
  3) Set TBR according to the trap type
  4) Force a branch to the trap instructions. - the address in the TBR

- Enable Traps bit 를 turning off 하는것은 interrupt recognition을
  delay  시키기 때문에  가능하면 최대한 짧게 해야하며 그 code 는 매우 주의
  하여 writing 되어야하며 만약 하나의 trap 이 disalble 되었을때에 요청되면
  watchdog 이 일어날것이다.

- current window pointer(CWP, in the Processor Status Register) 는 현재
  사용되고 있는 register 를 가리킨다.  registers 는 circular buffer 처럼
  행동하므로  완전한 register set 을 통하여 원형으로 돌게된다.
  곧 그것은 overlap 이되고 new register window 가 가리키는것은 실제로
  사용하기위한 free 가 아니다. 이러한 경우가 바로 window overflow trap(or
  a window underflow,when moving in the other direction) 의 source 이다.
  그리고 이순간의 trap 은 watchdog reset 을 일으키므로  CWP 는 실제 바뀌어
  져서 invaild window 를 가리키는 point 가 된다. 이러한 이유를 위하여
  H/W 와 S/W (trap handling process)  는 단지 local(%l0-%l7) registers 을
  사용할수가 있다. 다른 registers 는 touch 되어지지않는다.
  이것은 stack  상에서 nonstandard stack frame 을 만들며 예를들면 return 
  address (in %i7) 은 실제 valid pointer 가 아님.
  Trap Base Register 는 보통 시스템의 초기화 과정에서 한번 setup 이되며
  일부 page boundary 를 가리킨다.

          Trap Base Address           Trap Type   0000
             (20 bits)                 (8 bits) 

  - lower bits 는 항상 0 이며 다음 8 bits 는 trap type field 로서 H/W 에서
   정의된  trap 의 type 에 근거하여 자동적으로 채워진다.

7. Trap frames

- trap frame 은 구조적으로  stack frame 의 다른 type 과 다르지 않다.
  trap frame 은 local register %l1 에 있는 trap 을 일으킨 instruction의 
  주소를 가지며  local register %l2  에 next PC address 를 가진다.
  이것은 위에서도 말했지만  H/W 에 의해 행해진다.
  trap 을 handling 하는 S/W 의 기능은  registers 와 같이 다른일을 할지도
  모르며 그러나 보통, 최소한 PC address가  %l1 에 가능하다.
- Synchronous traps resulting from an instruction 은 보통 stack trace 
  바로뒤에 trap fram 이 나타나는 fault function 또는 trap function 으로부터
  하나의 frame 을 갖는다.
- 보통 external device interrups 에 의해 발생하는 Asynchronous faults 는   
  interrupt-handling code 에 의해 인식될수가 있다. 이것은 hardclock 인
  clock function 이 될수도 있고 또는 하나의 특별한 interrupt level(level 10)에    전용인 특정한 code 가 될수도 있다. interrupt 나 fault handler 같은 이런
  functions 에 참조하는 stack 상의 address 로  return 하는것은 보통
  바로 앞의 trap frame 를 가리킨다. code address in %l1 과 같은 frame 을
  주의깊게 보면 보통 그 address 는 in %l2 더하기 4 가 된다.
  Device interrupts 는 보통 interrupt service routine 의 이름에 의해 인식되며
  이것들은 보통 int 로 끝난다. 예를들면 zsint() 는  ZS(serial keyboadr/moust)
  device 를 위한 service routine 이다.

8. Trap types

- 각 trap type 은 unique 한 number 를 가지며 이것은 Trap Base Register 를
  수정하는데 사용되며 그리고 CPU 를 정확한 trap-handling routine 으로 지시하는데
  사용된다. SPARC chip Specs 에 의해 할당된 types 는 보통 그들의  Priority 에 
  대충 일치한다. trap priorities 는 단지 동시의 trap 또는 interrupt requests가
  나타날때에만 중요하다. 몇개의 Bad Trap panics 를 본후에는 이러한 것들이 당신
  에게는 익숙할것이다. (data fault 예를들면, trap tyep 9 )

- 가장 일반적인 trap types 과 의미
   1 : Illegal instruction access(text fault)
   2 : Illegal instruction
   3 : Privileged instruction
   4 : Floating-point disabled
   5 : Window overflow
   6 : window underfolw
   7 : Memory address alignment error
   8 : Floating-point exception
   9 : Data access exception ( data fault)
   17: Interrupt level 1
   18: Interrupt level 2 up to
   31: Interrupt level 15
   128: Software trap #0 up to
   255: Software trap #127

9. Retunring from traps

- 시스템은 interrupt 된 code 또는 trap 이 발생한 code 로  돌아갈수있어야만
  한다. 여기에 rett 라고하는 하나의 특별한 instruction 인 return from trap
  operation 을 수행하는 것이 있다. 이것은 H/W 가 trap 을 인식했을때 발생한
  events 의 sequence 를 원위치 시킨다.

10. panic() routine.

- panic() routine 은 갑자기 모든 정상적인 process scheduling 을 interrupt 함.
  user 의 관점에서 본다면 시스템은 죽은것이다. panic() 은 그 memory 의 내용을
  dump device 에 그대로 copy 하게된다. default 로, dump device 는 보통 primary
  swap device 이다. dumps 를 위해서 disk 의 분리된 chunk 를 사용하는것을 보기는
  힘들다. 그러나 그러한 방법으로 setup 도 가능하다. 대부분의 UNIX systems 에 
  있어서 dump device 는 반드시 하나의 disk partition 이 되어야한다. 일부시스템은
  tape drive 가 명시되기도 한다.

- panic() 은 현재의 CPU 상태에 대한  critical information 을 기록한다.
  이러한 information  은 CPU registers, stack pointer, 그리고 다양한 state 
  register 를 포함하고 있다.

- 한번 panic() 이 dumping memory 를 dump device 에 완성하게되면 
  시스템을 reboot 한다.


11. Panic messages

- system programmer 와 현재의 operation 에 따라서 일부 panic messages 은 꽤
  간단해질수가 있다. 반면에 다른것들은 상당히 자세하게 messages 를 제공한다.
  즉, 가끔 당신은 calling program 의 name 이나 사용되고 있는 variables 뿐만
  아니라 그 source 의 line number 까지 보게될수도 있고 단지 programmer 만이
  알아볼수있는  다소 cryptic word 도 볼수있다.


12. Kernel Tracebacks 

- panic 의 원인을 정확히 결정하기 위해서는 source code  가 필요하지만
  stack  을 봄으로써 가끔 문제의 본질로서의 실마리를 제공하는 흥미있는
  information 을 제공받을수가 있다. 
  Sun-3 systems 은 function call 을 위하여 parameters 를 stack 상에
  push 하지만 Sun-4/SPARC systems 은 registers 를 사용한다.
  이리하여 Sun-3 stack traceback 은 다양한 parameters  를 보여줄것이다.
  그러나 SPARC stack 은 항상 정확히 six parameters 만 보여준다.
  이것들중의 일부는 registers  를 scratch(erase) 할수도 있지만 다른일부는
  유효하다. 즉, 얼마나 많은 parameters 가 pass 되었는가를 알기위해 그 code
  를 check 하지않고서는 알 방법이 없다.

- stack traceback 은 보통 그 code 가 죽었을때에 call 한 마지막 routine 을
  보여준다. 즉, H/W fault 에 대해서는 actual location 에서의 PC value.
  adb 의 ?i 는 real function 을 나타내준다. 사용해보라.또한, 
  SPARC system 을 위해서 traps 은 erroneous traceback 과 같이 보이는 
  다른 registers 에 PC value 를 저장하게된다, Sun-4 systems  의 많은경우
  당신은 trap function 의 바로 앞 address 를 무시하게되는데 왜냐하면
  반드시 유효하지는 않기 때문이다.
  비록, 실제로 parameter 가 무엇인지를 결정하는것이 쉽지는 않지만,
  첫번째 몇개의 registers 에 있는 여러개의 zeros, small constants, or odd 
  numbers 는 chain 으로 내려오면서 전달된 bad parameters 를 나타낼수가 있다.

- Many times device drivers are involved.
  Check for these in the traceback.
  driver routines 은 일반적으로 2 or 3-letter abbreviation 으로 시작되며
  이것은 그 function 의  이름으로 수행되고 boot time 때 probe routine 에
  의해 device 의 이름으로 printed 된다.
  STREAMS-related 인 str 로서 xystrate,zsopen, stwrite 가 있다.
  또한 interrupt service routines 을 주목하라. 만약, xyintr 가 stack내에
  나타난다면, 그것은 일반적으로 traceback information 과 관련이 없다,
  panic or trap 은 interrupt code 내에서 발생하며 아마도 device 에 관련이 
  있으며 현재 process context 에 관련이 없다.



		< 4. Watchdog Reset >



1. What is a watchdog ?

- 가끔 시스템은 "watchdog reset" 이라는 message 를 console 에 내고 PROM 
  으로 내려간다. 이것은 panic 은 아니다. 그 시스템은 더이상 control 에
  있는것은 아니다.  그것은 memory 를 disk 로 dumping 하지않고
  CPU 가 reset 으로 된다.

- Watchdog resets 은 근본적인 원인은 H/W  에 연관될지도 모르지만 보통은
  S/W 문제이다. 직접적인 원인은 page fault 와 같은 trap 인데 다른 trap 을
  handling 하는중에 발생한다. Kernel 은 PSR(Processor Status Register) 내의 
  Enable Traps bit  을 reset(turned off) 시킴으로써 trap 을 운용하는데
  이것은 최초에 처리되던 첫번째 trap 이 끝날때까지 다른 trap 을 CPU 가 
  처리하는것을 방지한다. 이것은 즉 시스템이 첫번째 trap 을 완전히 처리할때
  까지 다른 trap 은 만들어지지 않는다는 의미이다. 만약에 이 기간 동안 에  
  어떤 이유때문에 하나의 trap 이 발생한다면 시스템은 trap 을 수행해야
  하는데 이것은 bit 가 off 되어서가 아니기 때문에 시스템은 그 즉시
  quit(중지)  한다. 이것이 바로 watchdog reset 이다. 즉, unrecoverable 
  situation ( 근본적으로 CPU의 reset 상태로 강제로 만드는 것) 이다.
  Watchdog reset 후에 당신이 할수있는 유일한 일은 바로 reboot 이다.

- Watchog reset 의 특성때문에  kadb 조차도 watchdog 이 일어났으때의
  watchdog resets 을 잡을수가 없다.그러나 당신은 간단히 몇개의
  OpenBoot PROM commands 로서  reboot  하기전에 일보의 status informatin
  을 얻을수가 있다.

2. Can you get a core file ?

- Not usually, 이 watchdog 의 파괴적인 속성상 당신 이 boot PROM ok prompt 를
  보게된다고 하더라도  CPU registers  는 벌써 깨져있고 sync command 수행이
  fail or  쓸데없는 core dump 를 얻게될것이다. 이것은  unreadabl 또는 살펴볼
  좋은 data  가 남아있지 않다. 항상 try 해볼펄요는 있지만 그러나 당신이
  먼저해야할 다른일이 있다.

3.  What do you do next ?

- 한번 boot PROM ok prompt 를 가진다면 당신은 몇개의 중요한 PROM command 
  를 사용할수가 있으며 시스템이 watchdog 을  받았을때  그 시스템의 상태에 
  관한 information  을 dump out 하기위해 다음과 같은 명령이 있다.
* .registers : Display many of the kernel internal CPU registers.
* .locals - Dumps out the registers in the current register "window."
            These are the registers that were in use at the time of the ctash.
* .psr - prints the Processor Status Register contents in a readable format.
* ctrace - Displays the return stack(like $c in adb)
* wd-dump (sun4d only)
- 불행하게도 이순간에 kernel 은 running 이 되지않는 상태이므로 당신은
  이 information 을 file 로 받을수가 없다. 당신은 아마도 paper 에 기록.

4. Watchdog analysis.

- Watchdog reset 은 시스템이 traps 을 processing  할때에 발생하므로 actual PC
  변수는 크게 소용이 없다. 당신은  kernel trap handling code 를 분석해야하고
  trace information 은 가장 중요하고 유용한 output 이다. 당신이 PROM 을 이용할
  때 kernel 은 running 되지않으며 sysmbol table 은 PROM code 에 유용하지않다.
  즉, PROM command 로 부터의 output 은 전적으로 hexdecimal 이며 raw numeric
  address 이다. 그 system  이 reboot 되고 살아있는 시스템상에서 adb 를 가지고
  kernel 내의 functions 으로서 try 해볼수가 있다. addredd/i 는 stack trace 로 
  로 부터 각 address 의 위치와 instruction  을 display 할수가 있다.

5. Summary

- Analyzing watchdog reset is not an easy task. 몇개의 PROM command 만이 사용
  할수가 있고  당신의 노력에 비애 유용한 information 을 항상 얻을수 있는것은
  아니다. 만약 다수의 watchdog resets 이 발생한다면 당신은 일관된 results 를
  얻을수가 있을것이고 관련된 functions 을 알게 될것이다. 
  비록 watchdog resets 이 software 의 problem 이라고 할지라고 그것들은 종종
  특정한 H/W 의 부분(CPU,Memory,M/B...) 에 관련이 될수고 있다. 이것은
  stack trace 로 부터 운이좋으면 알수가 있다. watchdog resets 으로부터
  피해를 보고 있는 시스템을 처리할때에 전체적인 system 을 보도록해야한다.
  H/W 와 S/W 둘다문제가 있는곳을 말이다.




Revision History

작성일자 : 96.06.13
작성자 : 이승훈

수정일자 : 
수정자