ISR 에서 msleep 를 써봤습니다. 다음 에러를 어떻게 봐야 할까요?
책 보다 보니, isr 에서는 sleep 등을 쓰지 마라고 하네요.
그래서, 쓰면 어떻게 죽을까 하는 호기심에 테스트 했더니 아래와 같이 나옵니다.
아래의 메시지를 어떻게 해석해야 할까요? isr 에서 sleep 이 실행되는 순간 커널이 아래 메시지를 내고 죽는건데..
커널은 이를 무슨 에러로 보고 있는걸까요? 커널이 뭘 근거로 그런 판단을 내렸는지 찾아봐도 관련 문서가 없네요..
고수님들의 도움 부탁 드립니다. arm 칩을 사용한 보드에서 테스트 했습니다.
혹시 다음과 같은 에러따라 가는 관련 글이라도 아시는 분들의 도움 부탁합니다..
-------------------------------
root@iWUC:~# insmod penbot.ko bottom_half_method=0
Loading robot control driver... (bottom_half_method: 0)
root@iWUC:~#
root@iWUC:~#
root@iWUC:~# BUG: scheduling while atomic: swapper/0x00010000/0
bad: scheduling from the idle thread!
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = c0004000
[00000000] *pgd=00000000
Internal error: Oops: 17 [#1]
Modules linked in: penbot
CPU: 0
PC is at dequeue_task+0xc/0xa8
LR is at deactivate_task+0x34/0x40
pc : [] lr : [] Not tainted
sp : c020be14 ip : c020be24 fp : c020be20
r10: 004c4b13 r9 : 58b923c0 r8 : c020e508
r7 : c02131d8 r6 : c020be74 r5 : c01ce974 r4 : c020e508
r3 : 00000000 r2 : 00000080 r1 : 00000000 r0 : c020e508
Flags: nZCv IRQs off FIQs on Mode SVC_32 Segment kernel
Control: 717F Table: 33870000 DAC: 00000017
Process swapper (pid: 0, stack limit = 0xc020a250)
Stack: (0xc020be14 to 0xc020c000)
be00: c020be34 c020be24 c0031c34
be20: c0031a94 00000000 c020be70 c020be38 c01cd9fc c0031c10 00000001 07735940
be40: c020e618 c020a000 ffff6a90 00000065 c020be74 c02131d8 000000fd 41129200
be60: 3001dc20 c020bea8 c020be74 c01ce974 c01cd850 c0280ae0 c0280ae0 ffff6a90
be80: c003f7ac c020e508 c0280658 bf0016fc bf00170c bf0008ac 40000013 c020beb8
bea0: c020beac c01ce9cc c01ce8e8 c020bec8 c020bebc c0040290 c01ce9b8 c020bed8
bec0: c020becc bf0001c0 c0040274 c020befc c020bedc bf000354 bf0000a8 c0ea2900
bee0: 00000000 00000000 00000011 c020bf58 c020bf20 c020bf00 c005329c bf0002a4
bf00: c020c440 00000011 c0ea2900 c020bf58 3001dc54 c020bf40 c020bf24 c00544fc
bf20: c0053260 c020c440 f0000000 00000002 c02930d4 c020bf54 c020bf44 c00226f8
bf40: c00543f8 ffffffff c020bfac c020bf58 c0021984 c00226c8 c0020c60 00000032
bf60: f0400000 60000013 c0022f88 c020a000 c020f184 c02930d4 3001dc54 41129200
bf80: 3001dc20 c020bfac c020bfa0 c020bfa0 c0022fe8 c0022ff4 60000013 ffffffff
bfa0: c020bfc4 c020bfb0 c0022d5c c0022f98 c0282bcc c027a47c c020bfd4 c020bfc8
bfc0: c00212b4 c0022d30 c020bff4 c020bfd8 c0008a10 c00212a0 c0008514 c027a9c8
bfe0: 00007175 c027a944 00000000 c020bff8 30008038 c0008838 00000000 00000000
Backtrace:
[] (dequeue_task+0x0/0xa8) from [] (deactivate_task+0x34/0x40)
[] (deactivate_task+0x0/0x40) from [] (schedule+0x1bc/0x75c)
r4 = 00000000
[] (schedule+0x0/0x75c) from [] (schedule_timeout+0x9c/0xd0)
[] (schedule_timeout+0x0/0xd0) from [] (schedule_timeout_uninterruptible+0x24/0x28)
r7 = 40000013 r6 = BF0008AC r5 = BF00170C r4 = BF0016FC
[] (schedule_timeout_uninterruptible+0x0/0x28) from [] (msleep+0x2c/0x3c)
[] (msleep+0x0/0x3c) from [] (bisr_bottom+0x128/0x170 [penbot])
[] (bisr_bottom+0x0/0x170 [penbot]) from [] (button_isr+0xc0/0x148 [penbot])
[] (button_isr+0x0/0x148 [penbot]) from [] (handle_IRQ_event+0x4c/0x88)
r8 = C020BF58 r7 = 00000011 r6 = 00000000 r5 = 00000000
r4 = C0EA2900
[] (handle_IRQ_event+0x0/0x88) from [] (handle_edge_irq+0x114/0x158)
r8 = 3001DC54 r7 = C020BF58 r6 = C0EA2900 r5 = 00000011
r4 = C020C440
[] (handle_edge_irq+0x0/0x158) from [] (asm_do_IRQ+0x40/0x50)
r7 = C02930D4 r6 = 00000002 r5 = F0000000 r4 = C020C440
[] (asm_do_IRQ+0x0/0x50) from [] (__irq_svc+0x24/0xa0)
r4 = FFFFFFFF
[] (default_idle+0x0/0x78) from [] (cpu_idle+0x3c/0x58)
[] (cpu_idle+0x0/0x58) from [] (rest_init+0x24/0x2c)
r5 = C027A47C r4 = C0282BCC
[] (rest_init+0x0/0x2c) from [] (start_kernel+0x1e8/0x244)
[] (start_kernel+0x0/0x244) from [<30008038>] (0x30008038)
Code: e89da800 e1a0c00d e92dd800 e24cb004 (e5913000)
<0>Kernel panic - not syncing: Aiee, killing interrupt handler!
schedule() 함수내 확인 코드에서...
아래 함수내에서 났네요
(일부 코드 조각들 중략)
asmlinkage void __sched schedule(void)
{
/*
* Test if we are atomic. Since do_exit() needs to call into
* schedule() atomically, we ignore that path for now.
* Otherwise, whine if we are scheduling when we should not be.
*/
if (likely(!current->exit_state)) {
if (unlikely(in_atomic())) {
printk(KERN_ERR "scheduling while atomic: "
"%s/0x%08x/%d\n",
current->comm, preempt_count(), current->pid);
dump_stack();
}
}
/*
* The idle thread is not allowed to schedule!
* Remove this check after it has been exercised a bit.
*/
if (unlikely(prev == rq->idle) && prev->state != TASK_RUNNING) {
printk(KERN_ERR "bad: scheduling from the idle thread!\n");
dump_stack();
}
/***************************************
Being the one is just like being in love.
***************************************/
네. 그 부분이
네. 그 부분이 문제입니다.
그 부분만으로 판단을 해 보면.. ISR 에서 sleep 을 하게 되면 좀비 상태가 된다는 말인데..
이건 좀 아닌듯 합니다..
다른 원인이 있을듯 한데.. 왜 널포인트를 참조 했다는 에러가 나는지.. 그게 근본적인 원인이 될듯 합니다.
idle thread 의 process descriptor의 멤버 prio_array_t *array가 NULL인데
schedule() -> deactivate_task() -> dequeue_task()
에서 죽었네요.
struct task_struct 타입의 idle thread 의 process descriptor
의 멤버 prio_array_t *array가 NULL인데
그 멤버인 array->queue 를 dereference하려다가 죽은듯...
/***************************************
Being the one is just like being in love.
***************************************/
흠
전에도 말씀드렸지만... ISR이 실행되는 것은
TASK 단위에서 있는 것이 아닙니다...
단순히 커널이 잠깐 Process가 못하는 단계의 일을..
하고 있는 순간이죠...
msleep이 ISR에서 정확히 어떻게 실행되는지..
모르겠지만...
scheduler에 직접 접근이 되는 routine 이라면...
현재 current ( scheduler 에서 현재 cpu에서 진행 중인 프로세스.. )
process가 무엇이 될까라고 생각을 잠깐 해보면 이런 결론이..
납니다..
엉????? kernel 이 task descriptor를 가지고 있을리가 없자나..!
그럼.. run_list는 정보는 어디에 있지?
그럼.. enqueue 나 dequeue는 run_list 정보가 없는데..
어디다 하는거야??? 헉....
이렇습니다....
보통 bug reporting 후 시스템이 멈춘다고 생각하시는 분들이..
있으신 것 같은데.. dump만 하고...
그냥 계속 진행합니다...
그러나.. queue 에 접근하는 행위를 하면서
문제가 발생해 멈춘게 아닌가 합니다..
re
isr 중 current 는 isr이 불리기 이전에 돌던 process 입니다.
따라서 이전 process 의 task_struct 구조체를 액세스 하게 되고요.
각 아키텍쳐 구현마다 다르지만 커널 버그라고 판단 되는 경우 bug reporting 후 디버깅을 위해 더이상 진행을 하지 않고 무한 루프(nop 반복수행)를 돌게 하는경우가 많습니다. 계속 진행할 경우 문제가 발생한 시점으로 부터 멀어져 디버깅이 더욱 어렵기 때문입니다.
댓글 달기