Scheduling in interrupt and call trace

Scheduling in interrupt and call trace

[railroad seeker]

Hi all:

I am tracking a driver bug in arm linux when I got a scheduling in
interrupt context
panic.

I traced into kernel schedule() function, and found that "schedulingin
interrupt" is a
check point when the process scheduler is invoked, and the callstack
reveals that
the scheduler is invoked due to semaphore down().

After that, the program counter must located in BUG(), that is something like
"(void *)0 = 0" if we really do scheduling in interrupt contxt, and
should cause
the kernel to panic. However, what i got is that the latest program
counter is located within the do_IRQ() context when the kernel was
crashed . But it
seems that the stack trace is a kernel stack of process context since
the bottom of the stack is ret_from_syscall. (I have not enabled the
frame pointer when compiling the kernel, instead, I back traced by
manually inspect each 32 bit value
from the output of objdump) , and I think that the latest PC should
point to the next instruction of "(void *) 0 = 0".

Is there any possibility with which we got this incorrect information,
 or I have
misunderstanding about "kernel system to interrupt context switch?

Thanks.

Re: Scheduling in interrupt and call trace

[Russell King]

On Mon, Mar 19, 2007 at 08:37:57PM +0800, railroad seeker wrote:
> After that, the program counter must located in BUG(), that is something 
> like
> "(void *)0 = 0" if we really do scheduling in interrupt contxt, and
> should cause
> the kernel to panic. However, what i got is that the latest program
> counter is located within the do_IRQ() context when the kernel was
> crashed . But it
> seems that the stack trace is a kernel stack of process context since
> the bottom of the stack is ret_from_syscall. (I have not enabled the
> frame pointer when compiling the kernel, instead, I back traced by
> manually inspect each 32 bit value
> from the output of objdump) , and I think that the latest PC should
> point to the next instruction of "(void *) 0 = 0".
> 
> Is there any possibility with which we got this incorrect information,
> or I have
> misunderstanding about "kernel system to interrupt context switch?

Please enable frame pointers and show the resulting backtrace; it is
possible that trying to manually decode the stack without frame
pointers enabled will result in a confused backtrace.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of: