Subject : 시스템장애분석(savecore,hangup,Panic,watchdog-reset)
Description :
1. Hangup
2. Panic
3. Watchdog Reset
< 1. 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 둘다문제가 있는곳을 말이다.