KERNEL
Posts
183 posts[Linux][Kernel] 인터럽트(Interrupt) - request_threaded_irq overview(1)
리눅스 커널 인터럽트 개념 중에 top/bottom half란 용어를 많이 들어봤죠? 하드웨어적으로 인터럽트가 처리될 때는 되도록 실시간으로 처리할 데이터만 빨리 처리하고,빨리 처리해도 안되는 동작은 쓰레드 레벨로 수행한다는 거죠. 수 없이 이런 글을 읽어봤는데, 사실 인터럽트 서비스 루틴에서 발생하는 수 많은 이슈를 대응하기 전까지는 개념이머리 속에 잘 들어오지 않더라구요. 그래서 이번 시간에 좀 좀 정리를 해보려고 해요. 리눅스 커널에서 bottom half로 처리되는 루틴은 크게 세 가지가 있어요.1> softirq2> workqueue3> irq_thread 이번 시간에는 irq_thread에 대해서 touch 드라이버를 예를 들어서 분석을 해보려구요.touch의 IRQ 관련
[Linux][Kernel] panic@___might_sleep
리눅스 커널 synchronization의 꽃 중의 하나인 Mutex Lock에 대해서 조금 짚어 볼께요. Mutex Lock은 보통 스핀락(Spinlock)과 많이 비교하죠. 사실 소스 코드를 보면 Mutex Lock이 스핀락보다 훨씬 소프트웨어적으로 복잡해요. 그 이유는?1> Mutex Lock을 잠근 프로세스만 해제할 수 있어요2> 이미 다른 프로세스가 Mutex Lock을 획득한 상태면 struct mutex.wait_list에 대기하고 Wait Queue에 넣고 잠들어야 해요.음, 이 소리는. Mutex Lock을 잡고 있는 프로세스가 Mutex Lock을 해제하면 누군가가 다시 대기 중이던 프로세스를 WaitQueue에서 끄집어 내서 런큐에 큐잉을 해줘야겠죠. 마지막으로 Mutex
[Linux][Kernel][Stability] Kernel panic @0x0 from xfrm_local_error+0x4c
커널 패닉이 났어요.네트워크 드라이버 리눅스 커널 코드에서 발생한 것 같은데요. 음.일단 당황하지 마시구요. 차근 차근 커널 로그와 코어 덤프를 살펴보면, 정답이 나와요. 일단 커널 로그를 보면, 프로그램 카운터가 0x0을 가르키고 있네요.음... 그리고링크 레지스터(R14)가 0xc0adc274(LR is at xfrm_local_error+0x4c/0x58) 을 가르키고 있습니다.[ 262.401303] Unable to handle kernel NULL pointer dereference at virtual address 00000000[ 262.401365] pgd = dbdc4000[ 262.401389] [00000000] *pgd=00000000[ 262.401433] Internal
tombstone 시(시스템 크래시) - 커널 패닉 유발
userspace에서 tombstone(무덤)이 떨어지면서 크래시가 종종 발생합니다.에러 시그니처는 아래와 같아요. 흠...Revision: '0'ABI: 'arm'pid: 1558, tid: 1891, name: RenderThread >>> com.google.launcher2
