커널크래시

이번에는 비트 플립으로 발생한 커널 패닉 코어 덤프 분석 과정을 소개합니다. 다음은 T32로 커널 패닉이 발생했을 때 잡은 콜스택입니다.01 -000|machine_restart(?)02 -001|arch_local_irq_enable(inline)03 -001|panic(fmt = 0xC0EF195A)04 -002|oops_end(inline)05 -002|die(str = 0xC017409E, ?, err = -590234666)06 -003|do_undefinstr(regs = 0xDCD1BCA8)07 -004|__und_svc_fault(asm)08 -->|exception09 -005|profile_tick(type = -590234136)10 -006|tick_sched_timer(tim

우선 콜스택부터 점검을 해보면, "kswapd0" 프로세스에서 slab cache를 scanning 하는 도중 커널 크래시가 발생하였음을 알 수 있습니다. 메모리가 부족한 상태로 보입니다. ("kswapd0" 프로세스는 page memory가 부족할 때 실행됩니다.)-000|do_DataAbort(addr = 3244789312, fsr = 3245415784, regs = 0xC1678E40)-001|__dabt_svc(asm) -->|exception-002|test_and_set_bit(asm) // <<**** kernel panic-003|bit_spin_lock(inline)-003|hlist_bl_lock(inline)-003|mb_cache_shrink_scan(?, ?)-0

커널 크래시란커널 크래시 분석은 왜 중요할까? 커널 크래시 분석을 잘하는 게 왜 중요할까요? 너무 당연한 질문인가요? 사실 세상에 너무 당연한 질문은 없습니다. 어쩌면 너무 당연한 질문에 답하려고 고민하다가 많은 걸 깨닫는 경우가 많은 것 같습니다. 여러분이 리눅스 드라이버를 개발하거나 새로운 리눅스 커널 버전을 포팅했다고 가정하겠습니다. 그런데 안타깝게도 부팅 도중 아래와 같은 로그를 출력하는 커널 크래시가 100% 발생하고 있습니다. 어떻게 분석해야 할지 몰라 하루 꼬박 밤을 새웠습니다. 참 이럴 때 난감하죠. [ 0.986578] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)[ 0.986589] CPU:

커널 패닉이란 말을 들어본 적이 있나요? 혹시 여러분이 임베디드 리눅스 개발자면 몇 번 쯤은 들어봤을 겁니다. 하지만, 리눅스를 자주 안 쓰거나 리눅스를 학습 용도로 쓰시는 분들에겐 단어가 낯설게 들릴수도 있죠. 여러분들은 대부분 컴퓨터나 노트북을 윈도 운영체제로 쓰실 겁니다. 그런데 혹시 컴퓨터를 오래 쓰다가 블루 스크린을 본 적이 있나요? 밝은 파란색 배경 화면에 흰색으로 이상한 경고 문구가 떠있죠. 이 때 컴퓨터는 아무런 동작을 안합니다. 이런 화면을 처음 봤을 때 어땠나요? 좀 짜증나지 않았나요? 전 예전 처음 이 블루 스크린을 봤을 때 엄청 당황했었어요. 왜냐면 “전원을 다시 키면 부팅은 할까?”, “혹시 컴퓨터에 저장된 자료가 날아가는 건 아닌가”? 이런 걱정을 했죠. 정말 뭔가 컴퓨터에 큰