Kernel Crash Case-Studies (14) 썸네일형 리스트형 [KernelCrash] Abort at 0xecb29f00(defective device) Analysis Kernel log says that program counter indicates invalid address(0xecb29f00) as below.[ 257.879321 / 01-01 00:04:20.499][1] Unable to handle kernel paging request at virtual address ecb29f00[ 257.879343 / 01-01 00:04:20.499][1] pgd = c4ebc000[ 257.879355 / 01-01 00:04:20.499][0] [ecb29f00] *pgd=6ca1141e(bad)[ 257.879372 / 01-01 00:04:20.499][1] Internal error: Oops: 8000000d [#1] PREEMPT .. [KernelCrash] Abort at mmc_wait_data_done() due to race From callstack, "ndroid.systemui" process is executing inside arch_spin_lock() function. And then watchdog reset is triggered.-000|aee_wdt_atf_entry()-001|prefetchw(inline)-001|arch_spin_lock(inline)-001|do_raw_spin_lock_flags(inline)-001|__raw_spin_lock_irqsave(inline)-001|raw_spin_lock_irqsave(lock = 0xDD82725C)-002|__wake_up(q = 0xDD82725C, mode = 1, nr_exclusive = 1, key = 0x0)-003|mmc_wait_.. [KernelCrash] Abort at __stack_chk_fail() due to defective memory Very interesting kernel panic occurs with the following callstacks.crash> bt -I C0ED8B64 -S E853FD20 e5752c00PID: 1787 TASK: e5752c00 CPU: 4 COMMAND: "python"bt: WARNING: stack address:0xe853fa38, program counter:0xc0ee5b60 #0 [] (panic) from [] #1 [] (__stack_chk_fail) from [] #2 [] (sock_has_perm) from [] #3 [] (security_socket_recvmsg) from [] #4 [] (sock_recvmsg) from [] #5 [] (___sys_recvms.. [KernelCrash] Abort at rmqueue_bulk() due to page.lru->next corruption Kernel panic occurs with defective device under the following call trace.crash> bt -I C01002D8 -S E7AABC08 0xE1804200PID: 2285 TASK: e1804200 CPU: 5 COMMAND: "python"bt: WARNING: stack address:0xe7aabd80, program counter:0xc0ee5b60 #0 [] (do_DataAbort) from [] pc : [] lr : [] psr: 60020193 sp : e7aabcf8 ip : c193e69c fp : edf34bf4 r10: 00000000 r9 : 0000001f r8 : 00000002 r7 : c1938280 r6 : c193.. [리눅스커널][크래시분석] 뮤텍스 데드락(Mutex Deadlock) 락업(lockup) - "simpleperf" 디버깅 특정 시점부터 갑자기 디바이스가 락업되는 현상이 리포트가 되었거든요. 엄청 락업된 디바이스가 쏟아 졌었는데요. 이번 시간에는 그 때 어떻게 디버깅을 해서 문제를 해결했는지 업데이트하고자 해요. 락업이 된 상태에서 디바이스를 받아 강제로 코어 덤프를 뜬 다음에 콜 트레이스를 봤는데요.아래 콜 스택이 확인되었어요. 프로세스 이름은 "atd" 이에요. reboot 시스템콜을 trigger한 다음에 각 종 시스템 드라이버를 종료하는 과정에서 mutex lock을 계속 기다리는 현상이 확인되네요.-000|context_switch(inline)-000|__schedule()-001|schedule_preempt_disabled()-002|spin_lock(inline)-002|__mutex_lock_common(.. [리눅스커널][Trace32] T32로 wakelock 디버깅 - container_of 함수 분석 임베디드 개발에서 T32-Trace32 장비를 많이 써서 소스 코드 디버깅을 합니다. 이번 시간에는 리눅스 커널에서 웨이크락(wake lock)을 잡는 모듈이 누구인지 파악하는 디버깅(Debugging) 방법을 소개합니다. 리눅스 커널는 wakeup_sources이란 연결 리스트를 통해 wakelock 정보를 확인할 수 있습니다. 리눅스 커널 개발자 중에 crash-utility을 잘 쓰는 분이 있습니다.하지만 임베디드 개발에선 Trace32도 더 많이 활용하는 것 같습니다.개발자는 다양한 툴을 써야 한 가지 툴에 종속된 노예 개발자가 되는 것을 피할 수 있습니다.또한 각 툴의 장점을 잘 활용할 수도 있습니다. 먼저, 다음 T32 명령어를 입력해서 offsetof와 container_of 매크로를 생성합.. 이전 1 2 다음