LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Embedded & Single-board computer (https://www.linuxquestions.org/questions/linux-embedded-and-single-board-computer-78/)
-   -   kernel BUG in preempt_schedule_irq at kernel/sched.c:3114! (https://www.linuxquestions.org/questions/linux-embedded-and-single-board-computer-78/kernel-bug-in-preempt_schedule_irq-at-kernel-sched-c-3114-a-708554/)

yigal_gold 03-02-2009 05:42 AM

kernel BUG in preempt_schedule_irq at kernel/sched.c:3114!
 
Hi all,
My system is a PPC running kernel 2.6.14.7 .
My application uses interrupts to collect bytes from the uart .
And I have to uarts running in parallel which signal to the same interrupt line . When I run only one uart at a time the system works fine . But when the 2 run symultaniously the system crashes as follows :

" kernel BUG in preempt_schedule_irq at kernel/sched.c:3114!
Oops: Exception in kernel mode, sig: 5 [#1]
PREEMPT
NIP: C02297A8 LR: C0004A40 SP: C0286170 REGS: c02860c0 TRAP: 0700 Tainted: P
MSR: 00029032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
TASK = c0265b00[0] 'swapper' THREAD: c0286000
Last syscall: 120
GPR00: 00000001 C0286170 C0265B00 00009032 00000000 00003032 00600084 C02B5594
GPR08: C0280000 C0286000 00000001 C026A200 512037AD 4377FFBF 0FFFD000 00000000
GPR16: 00000001 00000001 FFFFFFFF 007FFF00 0FFF7E68 00000000 00000002 0FBC62B0
GPR24: 00000000 00000000 40000000 007FFF7D 007FFF00 C02A0000 C0265B00 C02A28F0
Call trace: [c0004a40] [c0004c7c] [c0004c7c] [c0004c7c] [c0004c7c] [c0004c7c] [c0004c7c] [c0004c7c] [c0004c7c] [c0004c7c] [c0004c7c] [c0004c7c] [c0004c7c] [c0004c7c] [c0004c7c]
Kernel panic - not syncing: Attempted to kill the idle task!
<0>Rebooting in 1 seconds..þ "

Does anyone have an idea why this is happening and what am I doing wrong ?



Thanks,
Yigal Goldberger .

David1357 03-02-2009 07:39 AM

Quote:

Originally Posted by yigal_gold (Post 3462240)
Does anyone have an idea why this is happening and what am I doing wrong?

We could use more information. Can you build a version of your kernel with debugging symbols? Your other alternative is to match those addresses in the "Call trace" to the values in your "System.map" file and manually give us a back trace. That will help us tell you what your driver did wrong.

If I had to make a wild guess, I am assuming you are not using the correct locking mechanism around some shared resource. This line
Code:

kernel BUG in preempt_schedule_irq at kernel/sched.c:3114!
tells me you have a preemptive kernel. This means you have the possibility of two different instances of your driver accessing the same hardware, the same part of your driver data, or some other shared resource.

yigal_gold 03-03-2009 01:59 AM

Hi David,
I'll be happy to provide you all you need in order to diagnose the problem, including the source code of the interrupt handler .
I'm somewhat new to Linux and can't find the option for debug build ,
How is this done ?

Thanks !
Yigal Goldberger.

David1357 03-03-2009 11:48 AM

Quote:

Originally Posted by yigal_gold (Post 3463215)
How is this done?

It would probably be easier for you to match to addresses to the values in the "/lib/modules/$(uname -r)/System.map" file.

yigal_gold 03-12-2009 11:35 AM

kernel BUG in preempt_schedule_irq at kernel/sched.c:3114!
 
Hi David,
I've looked it up in the System.map file and the addresses correspond to the following :
c0004c7c - __ipipe_ret_from_except
c0004a40 - somewhere inside resume_kernel.

I'm still stuck with this problem.

Thanks in advance.

Yigal.

David1357 03-15-2009 04:46 AM

Quote:

Originally Posted by yigal_gold (Post 3473345)
I'm still stuck with this problem.

It looks like __ipipe_ret_from_except is recursively calling itself until the scheduler notices and issues the BUG. You should probably look at resume_kernel and see what it would be doing to cause an exception.


All times are GMT -5. The time now is 09:19 AM.