TRACE32
Posts
30 posts[Linux][Kernel] data abort@cpuacct_charge - 리눅스 커널
CPU3에서 실행 중인 "Binder:15701_2" 프로세스가 데이터 어보트로 커널 크래시가 발생했습니다.커널 로그가 데이터 어보트 발생 시 어떤 동작을 했는지 레지스터 정보와 함께 알려주네요. [69350.929482] <26>Unable to handle kernel paging request at virtual address 11ad4e80[69350.929511] <26>pgd = d57f0000[69350.929527] <22>[11ad4e80] *pgd=00000000[69350.929548] <6>Internal error: Oops: 5 [#1] PREEMPT SMP ARM[69350.929563] Modules linked in:
watchdog reset - race in ipv6_ifa_notify() - 리눅스 커널
예전 MTK SoC에서 일어났던 Watchdog Reset 이슈인데요. 디버깅 정보를 조금 공유하고자 해요. CPU1에서 수행 중인 "migration/1" process에서 watchdog reset이 발생하여 시스템이 리셋된 흔적을 확인할 수 있어요.-000|do_undefinstr()-001|__und_svc_fault(asm) -->|exception-002|aee_wdt_atf_info()-003|aee_wdt_atf_entry()-004|debug_smp_processor_id()-005|cpu_stopper_thread()-006|smpboot_thread_fn()-007|kthread()-008|ret_from_fork(asm)-009|ret_fast_syscall(asm) MTK S
ARM64- Stack Push Userspace -> Kernel Space 코드리뷰
유저 공간에서 실행된 레지스터가 커널 Bottom Stack에 Push 되는 디버깅 정보를 예전 페이지에 업데이트했잖아요.아래와 같은 메모리 덤프를 확인했었죠.(출처:http://rousalome.egloos.com/9966225)NUD:FFFFFFE4DE6A7EB8| 3C 6B 77 2B 46 76 A8 C2 0xC2A876462B776B3CNUD:FFFFFFE4DE6A7EC0| 45 00 00 00 00 00 00 00 0x45 // x0 NUD:FFFFFFE4DE6A7EC8| 80 37 81 AF 7B 00 00 00 0x7BAF813780 // x1NUD:FFFFFFE4DE6A7ED0| 16 00 00 00 00 00 00 00 0x16 // x2NUD:FFFFFF
IRQ Stack(ARM64) - Debugging(디버깅)
아래 블로그에서 IRQ Stack(ARM64)에 대해 소개를 했는데요. 이번에는 직접 코어 덤프에서 IRQ Stack 덤프를 살펴볼께요. IRQ Stack Feature를 지원하는 프로세스의 콜스택을 Trace32로 잡아서 확인해 보았어요. 참고로, 아래는 CPU0에서 idle process가 돌아가 갑자기 IRQ가 Trigger되었을 시의 동작이에요. -000|gic_handle_irq(?) -001|el1_irq(asm) -->|exception -002|lpm_cpuidle_enter(dev = 0x0, ?, idx = 0) -003|cpuidle_enter_state(dev = 0xFFFFFFE57E2A33D8, drv = 0xFFFFFFE4F2E14C00, index = 0) -004|c
