* Question on Schedule and Preemption
@ 2006-04-18 7:23 Liu haixiang
2006-04-18 9:17 ` Andreas Mohr
0 siblings, 1 reply; 10+ messages in thread
From: Liu haixiang @ 2006-04-18 7:23 UTC (permalink / raw)
To: linux-kernel
Hi All,
Now I am developing the driver on Linux kernel 2.6.11. And I met the
problem that kernel will dump my stack from time to time. And the
kernel log will give me messages like "scheduling while atomic: ...".
Then I found the code in sched.c:
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();
}
}
Anybody can explain above code for me?
Thanks
best regards
Haixiang Liu
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: Question on Schedule and Preemption
2006-04-18 7:23 Question on Schedule and Preemption Liu haixiang
@ 2006-04-18 9:17 ` Andreas Mohr
2006-04-18 9:23 ` Arjan van de Ven
2006-04-18 12:55 ` Liu haixiang
0 siblings, 2 replies; 10+ messages in thread
From: Andreas Mohr @ 2006-04-18 9:17 UTC (permalink / raw)
To: Liu haixiang; +Cc: linux-kernel
Hi,
On Tue, Apr 18, 2006 at 03:23:01PM +0800, Liu haixiang wrote:
> Hi All,
>
> Now I am developing the driver on Linux kernel 2.6.11. And I met the
> problem that kernel will dump my stack from time to time. And the
> kernel log will give me messages like "scheduling while atomic: ...".
>
> Then I found the code in sched.c:
>
> 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();
> }
> }
>
> Anybody can explain above code for me?
OK, I'll try, but there should be many references and explanations to it
on the internet already (did you look?).
If the current task is running and thus not yet exiting (!current->exit_state)
and is also in an atomic code section (i.e. under lock), it shouldn't call
any reschedule function (which also happens by just calling msleep(): use
mdelay() instead in that case!).
Generally spoken you should leave locked code sections ASAP (don't waste
too much time in there), and not call any functions that schedule to the
next task in there (msleep(), ...).
BTW, the code above is an old unoptimized version, fixed by me recently.
Andreas Mohr
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: Question on Schedule and Preemption
2006-04-18 9:17 ` Andreas Mohr
@ 2006-04-18 9:23 ` Arjan van de Ven
2006-04-18 9:28 ` Andreas Mohr
2006-04-18 12:55 ` Liu haixiang
1 sibling, 1 reply; 10+ messages in thread
From: Arjan van de Ven @ 2006-04-18 9:23 UTC (permalink / raw)
To: Andreas Mohr; +Cc: Liu haixiang, linux-kernel
> If the current task is running and thus not yet exiting (!current->exit_state)
> and is also in an atomic code section (i.e. under lock), it shouldn't call
> any reschedule function (which also happens by just calling msleep(): use
> mdelay() instead in that case!).
>
actually don't use mdelay, but change your code so that you CAN sleep :)
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Question on Schedule and Preemption
2006-04-18 9:23 ` Arjan van de Ven
@ 2006-04-18 9:28 ` Andreas Mohr
0 siblings, 0 replies; 10+ messages in thread
From: Andreas Mohr @ 2006-04-18 9:28 UTC (permalink / raw)
To: Arjan van de Ven; +Cc: Liu haixiang, linux-kernel
Hi,
On Tue, Apr 18, 2006 at 11:23:47AM +0200, Arjan van de Ven wrote:
>
> > If the current task is running and thus not yet exiting (!current->exit_state)
> > and is also in an atomic code section (i.e. under lock), it shouldn't call
> > any reschedule function (which also happens by just calling msleep(): use
> > mdelay() instead in that case!).
> >
>
> actually don't use mdelay, but change your code so that you CAN sleep :)
Ermm, I meant to say that, but forgot to do so clearly, sorry.
Basically long delays while holding locks are also a very baaad thing,
thus always avoid delays as much as possible there.
Andreas Mohr
--
No programming skills!? Why not help translate many Linux applications!
https://launchpad.ubuntu.com/rosetta
(or alternatively buy nicely packaged Linux distros/OSS software to help
support Linux developers creating shiny new things for you?)
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Question on Schedule and Preemption
2006-04-18 9:17 ` Andreas Mohr
2006-04-18 9:23 ` Arjan van de Ven
@ 2006-04-18 12:55 ` Liu haixiang
2006-04-18 14:56 ` Steven Rostedt
1 sibling, 1 reply; 10+ messages in thread
From: Liu haixiang @ 2006-04-18 12:55 UTC (permalink / raw)
To: Andreas Mohr; +Cc: linux-kernel
Hi Andreas Mohr,
Thanks for your explanation. And now I am clear on above code.
Please see my problem below. It seemed that there is one code to add
preempt count [<8440de20>], which means that the kernel can not be
preemptied. Then the code call switch_to (which contains the code
__switch_to_end).
And it's problem becuase the code already in the atomic status and can
not be scheduled.
My understanding is correct? And how to know which process or code
call add_preempt_count? Is there any good way to find the clue?
===================================
scheduling while atomic: TUNER0/0x04000001/611
Call trace:
[<846532b4>] __switch_to_end+0x2fe/0x38a
[<8440de20>] add_preempt_count+0x0/0xa0
[<84652c80>] schedule+0x0/0x300
[<8440dd80>] sub_preempt_count+0x0/0xa0
[<84653ef8>] cond_resched+0x38/0x80
[<84405096>] ret_from_irq+0x0/0x12
[<845145e0>] __delay+0x0/0x20
[<84653ef8>] cond_resched+0x38/0x80
[<8440de20>] add_preempt_count+0x0/0xa0
[<84652c80>] schedule+0x0/0x300
[<8440dd80>] sub_preempt_count+0x0/0xa0
[<845d9a16>] bit_xfer+0x256/0x8c0
[<845d6d36>] i2c_transfer+0x56/0xe0
[<c042382e>] STI2C_Read+0x2e/0x80 [sti2c_ioctl]
[<c046af32>] I2C_ReadWrite+0x72/0x1a0 [sttuner_core]
[<c0487d7c>] IOARCH_Handle+0x10/0xffff49a0 [sttuner_core]
[<84653ec0>] cond_resched+0x0/0x80
[<845d9cac>] bit_xfer+0x4ec/0x8c0
[<c046b398>] IOARCH_ReadWrite+0x118/0x180 [sttuner_core]
[<c05cb000>] 0xc05cb000
[<c046b456>] STTUNER_IOARCH_ReadWrite+0x16/0x40 [sttuner_core]
[<c05c300c>] 0xc05c300c
[<c0477482>] STTUNER_IOREG_GetContigousRegisters+0x142/0x1c0 [sttuner_core]
[<c046fd1a>] Drv0299_GetNoiseEstimator+0x1a/0x120 [sttuner_core]
[<c04835f0>] STTUNER_DrvInst+0x0/0xffff911c [sttuner_core]
[<c0483798>] STTUNER_DrvInst+0x1a8/0xffff911c [sttuner_core]
[<c048379c>] STTUNER_DrvInst+0x1ac/0xffff911c [sttuner_core]
[<c048379c>] STTUNER_DrvInst+0x1ac/0xffff911c [sttuner_core]
[<c05c300c>] 0xc05c300c
[<c05c3000>] 0xc05c3000
[<c0470960>] demod_d0299_GetSignalQuality+0x20/0x40 [sttuner_core]
[<c048379c>] STTUNER_DrvInst+0x1ac/0xffff911c [sttuner_core]
[<c0483798>] STTUNER_DrvInst+0x1a8/0xffff911c [sttuner_core]
[<c05c3000>] 0xc05c3000
[<c046c826>] SATTASK_GetTunerInfo+0x46/0xe0 [sttuner_core]
[<c04835f0>] STTUNER_DrvInst+0x0/0xffff911c [sttuner_core]
[<c04837ac>] STTUNER_DrvInst+0x1bc/0xffff911c [sttuner_core]
[<c046c9fa>] SATTASK_ProcessTracking+0x13a/0x1c0 [sttuner_core]
[<c04835f0>] STTUNER_DrvInst+0x0/0xffff911c [sttuner_core]
[<c04835f0>] STTUNER_DrvInst+0x0/0xffff911c [sttuner_core]
[<c046d388>] SATTASK_ScanTask+0x3e8/0x620 [sttuner_core]
[<c046ca80>] SATTASK_ProcessScanExact+0x0/0x340 [sttuner_core]
[<c0483800>] STTUNER_DrvInst+0x210/0xffff911c [sttuner_core]
[<c04835f0>] STTUNER_DrvInst+0x0/0xffff911c [sttuner_core]
[<c048482c>] STTUNER_DrvInst+0x123c/0xffff911c [sttuner_core]
[<c048492c>] STTUNER_DrvInst+0x133c/0xffff911c [sttuner_core]
[<c04835f0>] STTUNER_DrvInst+0x0/0xffff911c [sttuner_core]
[<c04836ec>] STTUNER_DrvInst+0xfc/0xffff911c [sttuner_core]
[<c04836ec>] STTUNER_DrvInst+0xfc/0xffff911c [sttuner_core]
[<c04848ec>] STTUNER_DrvInst+0x12fc/0xffff911c [sttuner_core]
[<c04848ec>] STTUNER_DrvInst+0x12fc/0xffff911c [sttuner_core]
[<c048492c>] STTUNER_DrvInst+0x133c/0xffff911c [sttuner_core]
[<8442b4e4>] kthread+0xe4/0x140
[<c046cfa0>] SATTASK_ScanTask+0x0/0x620 [sttuner_core]
[<c0483800>] STTUNER_DrvInst+0x210/0xffff911c [sttuner_core]
[<8440f4a0>] complete+0x0/0xc0
[<8442b3e0>] kthread_should_stop+0x0/0x20
[<84403004>] kernel_thread_helper+0x4/0x20
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Question on Schedule and Preemption
2006-04-18 12:55 ` Liu haixiang
@ 2006-04-18 14:56 ` Steven Rostedt
2006-04-18 17:21 ` Liu haixiang
0 siblings, 1 reply; 10+ messages in thread
From: Steven Rostedt @ 2006-04-18 14:56 UTC (permalink / raw)
To: Liu haixiang; +Cc: Andreas Mohr, linux-kernel
On Tue, 2006-04-18 at 20:55 +0800, Liu haixiang wrote:
> Hi Andreas Mohr,
>
> Thanks for your explanation. And now I am clear on above code.
>
> Please see my problem below. It seemed that there is one code to add
> preempt count [<8440de20>], which means that the kernel can not be
> preemptied. Then the code call switch_to (which contains the code
> __switch_to_end).
Your stack trace looks fishy, I recommend doing a "make menuconfig", go
to "Kernel Hacking" and turn on "Compile the kernel with frame pointers"
This will give you a better and cleaner stack dump.
>
> And it's problem becuase the code already in the atomic status and can
> not be scheduled.
>
> My understanding is correct? And how to know which process or code
> call add_preempt_count? Is there any good way to find the clue?
Well according to your output, it was the task "TURNER0" with the pid
611. After you recompile the kernel with CONFIG_FRAME_POINTERS you will
need to follow the stack trace and see what function turned off
preemption. This can happen calling a spin_lock and not unlocking it
before calling something that would schedule.
If you also turn on in "Kernel Hacking" -> "Compile the kernel with
debug info", you can then do a "gdb vmlinux" in the root directory of
the compile, and pass in the stack address with the command
"li *0xc042382e" to show where that function would return. (replace the
c042382e with the location you are looking for).
Also, what arch are you using to get a 0x04000000 in the preempt_count
(the 0x1 is the depth). Of course I'm looking at 2.6.17-rc1 and not the
one you are using. Hmm, your arch may not even support frame pointers.
-- Steve
>
> ===================================
> scheduling while atomic: TUNER0/0x04000001/611
>
> Call trace:
> [<846532b4>] __switch_to_end+0x2fe/0x38a
> [<8440de20>] add_preempt_count+0x0/0xa0
> [<84652c80>] schedule+0x0/0x300
> [<8440dd80>] sub_preempt_count+0x0/0xa0
> [<84653ef8>] cond_resched+0x38/0x80
> [<84405096>] ret_from_irq+0x0/0x12
> [<845145e0>] __delay+0x0/0x20
> [<84653ef8>] cond_resched+0x38/0x80
> [<8440de20>] add_preempt_count+0x0/0xa0
> [<84652c80>] schedule+0x0/0x300
> [<8440dd80>] sub_preempt_count+0x0/0xa0
> [<845d9a16>] bit_xfer+0x256/0x8c0
> [<845d6d36>] i2c_transfer+0x56/0xe0
> [<c042382e>] STI2C_Read+0x2e/0x80 [sti2c_ioctl]
> [<c046af32>] I2C_ReadWrite+0x72/0x1a0 [sttuner_core]
> [<c0487d7c>] IOARCH_Handle+0x10/0xffff49a0 [sttuner_core]
> [<84653ec0>] cond_resched+0x0/0x80
> [<845d9cac>] bit_xfer+0x4ec/0x8c0
> [<c046b398>] IOARCH_ReadWrite+0x118/0x180 [sttuner_core]
> [<c05cb000>] 0xc05cb000
> [<c046b456>] STTUNER_IOARCH_ReadWrite+0x16/0x40 [sttuner_core]
> [<c05c300c>] 0xc05c300c
> [<c0477482>] STTUNER_IOREG_GetContigousRegisters+0x142/0x1c0 [sttuner_core]
> [<c046fd1a>] Drv0299_GetNoiseEstimator+0x1a/0x120 [sttuner_core]
> [<c04835f0>] STTUNER_DrvInst+0x0/0xffff911c [sttuner_core]
> [<c0483798>] STTUNER_DrvInst+0x1a8/0xffff911c [sttuner_core]
> [<c048379c>] STTUNER_DrvInst+0x1ac/0xffff911c [sttuner_core]
> [<c048379c>] STTUNER_DrvInst+0x1ac/0xffff911c [sttuner_core]
> [<c05c300c>] 0xc05c300c
> [<c05c3000>] 0xc05c3000
> [<c0470960>] demod_d0299_GetSignalQuality+0x20/0x40 [sttuner_core]
> [<c048379c>] STTUNER_DrvInst+0x1ac/0xffff911c [sttuner_core]
> [<c0483798>] STTUNER_DrvInst+0x1a8/0xffff911c [sttuner_core]
> [<c05c3000>] 0xc05c3000
> [<c046c826>] SATTASK_GetTunerInfo+0x46/0xe0 [sttuner_core]
> [<c04835f0>] STTUNER_DrvInst+0x0/0xffff911c [sttuner_core]
> [<c04837ac>] STTUNER_DrvInst+0x1bc/0xffff911c [sttuner_core]
> [<c046c9fa>] SATTASK_ProcessTracking+0x13a/0x1c0 [sttuner_core]
> [<c04835f0>] STTUNER_DrvInst+0x0/0xffff911c [sttuner_core]
> [<c04835f0>] STTUNER_DrvInst+0x0/0xffff911c [sttuner_core]
> [<c046d388>] SATTASK_ScanTask+0x3e8/0x620 [sttuner_core]
> [<c046ca80>] SATTASK_ProcessScanExact+0x0/0x340 [sttuner_core]
> [<c0483800>] STTUNER_DrvInst+0x210/0xffff911c [sttuner_core]
> [<c04835f0>] STTUNER_DrvInst+0x0/0xffff911c [sttuner_core]
> [<c048482c>] STTUNER_DrvInst+0x123c/0xffff911c [sttuner_core]
> [<c048492c>] STTUNER_DrvInst+0x133c/0xffff911c [sttuner_core]
> [<c04835f0>] STTUNER_DrvInst+0x0/0xffff911c [sttuner_core]
> [<c04836ec>] STTUNER_DrvInst+0xfc/0xffff911c [sttuner_core]
> [<c04836ec>] STTUNER_DrvInst+0xfc/0xffff911c [sttuner_core]
> [<c04848ec>] STTUNER_DrvInst+0x12fc/0xffff911c [sttuner_core]
> [<c04848ec>] STTUNER_DrvInst+0x12fc/0xffff911c [sttuner_core]
> [<c048492c>] STTUNER_DrvInst+0x133c/0xffff911c [sttuner_core]
> [<8442b4e4>] kthread+0xe4/0x140
> [<c046cfa0>] SATTASK_ScanTask+0x0/0x620 [sttuner_core]
> [<c0483800>] STTUNER_DrvInst+0x210/0xffff911c [sttuner_core]
> [<8440f4a0>] complete+0x0/0xc0
> [<8442b3e0>] kthread_should_stop+0x0/0x20
> [<84403004>] kernel_thread_helper+0x4/0x20
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Steven Rostedt
Senior Programmer
Kihon Technologies
(607)786-4830
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Question on Schedule and Preemption
2006-04-18 14:56 ` Steven Rostedt
@ 2006-04-18 17:21 ` Liu haixiang
2006-04-18 17:32 ` Steven Rostedt
0 siblings, 1 reply; 10+ messages in thread
From: Liu haixiang @ 2006-04-18 17:21 UTC (permalink / raw)
To: Steven Rostedt; +Cc: Andreas Mohr, linux-kernel
2006/4/18, Steven Rostedt <rostedt@kihontech.com>:
> On Tue, 2006-04-18 at 20:55 +0800, Liu haixiang wrote:
> > Hi Andreas Mohr,
> >
> > Thanks for your explanation. And now I am clear on above code.
> >
> > Please see my problem below. It seemed that there is one code to add
> > preempt count [<8440de20>], which means that the kernel can not be
> > preemptied. Then the code call switch_to (which contains the code
> > __switch_to_end).
>
> Your stack trace looks fishy, I recommend doing a "make menuconfig", go
> to "Kernel Hacking" and turn on "Compile the kernel with frame pointers"
> This will give you a better and cleaner stack dump.
>
Thank you. And I will try it later.
> >
> > And it's problem becuase the code already in the atomic status and can
> > not be scheduled.
> >
> > My understanding is correct? And how to know which process or code
> > call add_preempt_count? Is there any good way to find the clue?
>
> Well according to your output, it was the task "TURNER0" with the pid
> 611. After you recompile the kernel with CONFIG_FRAME_POINTERS you will
> need to follow the stack trace and see what function turned off
> preemption. This can happen calling a spin_lock and not unlocking it
> before calling something that would schedule.
>
If it's true, it is a great help for me.
> If you also turn on in "Kernel Hacking" -> "Compile the kernel with
> debug info", you can then do a "gdb vmlinux" in the root directory of
> the compile, and pass in the stack address with the command
> "li *0xc042382e" to show where that function would return. (replace the
> c042382e with the location you are looking for).
>
> Also, what arch are you using to get a 0x04000000 in the preempt_count
> (the 0x1 is the depth). Of course I'm looking at 2.6.17-rc1 and not the
> one you are using. Hmm, your arch may not even support frame pointers.
>
> -- Steve
>
The arch is SH4.
> >
> > ===================================
> > scheduling while atomic: TUNER0/0x04000001/611
> >
> > Call trace:
> > [<846532b4>] __switch_to_end+0x2fe/0x38a
> > [<8440de20>] add_preempt_count+0x0/0xa0
> > [<84652c80>] schedule+0x0/0x300
> > [<8440dd80>] sub_preempt_count+0x0/0xa0
> > [<84653ef8>] cond_resched+0x38/0x80
> > [<84405096>] ret_from_irq+0x0/0x12
> > [<845145e0>] __delay+0x0/0x20
> > [<84653ef8>] cond_resched+0x38/0x80
> > [<8440de20>] add_preempt_count+0x0/0xa0
> > [<84652c80>] schedule+0x0/0x300
> > [<8440dd80>] sub_preempt_count+0x0/0xa0
> > [<845d9a16>] bit_xfer+0x256/0x8c0
> > [<845d6d36>] i2c_transfer+0x56/0xe0
> > [<c042382e>] STI2C_Read+0x2e/0x80 [sti2c_ioctl]
> > [<c046af32>] I2C_ReadWrite+0x72/0x1a0 [sttuner_core]
> > [<c0487d7c>] IOARCH_Handle+0x10/0xffff49a0 [sttuner_core]
> > [<84653ec0>] cond_resched+0x0/0x80
> > [<845d9cac>] bit_xfer+0x4ec/0x8c0
> > [<c046b398>] IOARCH_ReadWrite+0x118/0x180 [sttuner_core]
> > [<c05cb000>] 0xc05cb000
> > [<c046b456>] STTUNER_IOARCH_ReadWrite+0x16/0x40 [sttuner_core]
> > [<c05c300c>] 0xc05c300c
> > [<c0477482>] STTUNER_IOREG_GetContigousRegisters+0x142/0x1c0 [sttuner_core]
> > [<c046fd1a>] Drv0299_GetNoiseEstimator+0x1a/0x120 [sttuner_core]
> > [<c04835f0>] STTUNER_DrvInst+0x0/0xffff911c [sttuner_core]
> > [<c0483798>] STTUNER_DrvInst+0x1a8/0xffff911c [sttuner_core]
> > [<c048379c>] STTUNER_DrvInst+0x1ac/0xffff911c [sttuner_core]
> > [<c048379c>] STTUNER_DrvInst+0x1ac/0xffff911c [sttuner_core]
> > [<c05c300c>] 0xc05c300c
> > [<c05c3000>] 0xc05c3000
> > [<c0470960>] demod_d0299_GetSignalQuality+0x20/0x40 [sttuner_core]
> > [<c048379c>] STTUNER_DrvInst+0x1ac/0xffff911c [sttuner_core]
> > [<c0483798>] STTUNER_DrvInst+0x1a8/0xffff911c [sttuner_core]
> > [<c05c3000>] 0xc05c3000
> > [<c046c826>] SATTASK_GetTunerInfo+0x46/0xe0 [sttuner_core]
> > [<c04835f0>] STTUNER_DrvInst+0x0/0xffff911c [sttuner_core]
> > [<c04837ac>] STTUNER_DrvInst+0x1bc/0xffff911c [sttuner_core]
> > [<c046c9fa>] SATTASK_ProcessTracking+0x13a/0x1c0 [sttuner_core]
> > [<c04835f0>] STTUNER_DrvInst+0x0/0xffff911c [sttuner_core]
> > [<c04835f0>] STTUNER_DrvInst+0x0/0xffff911c [sttuner_core]
> > [<c046d388>] SATTASK_ScanTask+0x3e8/0x620 [sttuner_core]
> > [<c046ca80>] SATTASK_ProcessScanExact+0x0/0x340 [sttuner_core]
> > [<c0483800>] STTUNER_DrvInst+0x210/0xffff911c [sttuner_core]
> > [<c04835f0>] STTUNER_DrvInst+0x0/0xffff911c [sttuner_core]
> > [<c048482c>] STTUNER_DrvInst+0x123c/0xffff911c [sttuner_core]
> > [<c048492c>] STTUNER_DrvInst+0x133c/0xffff911c [sttuner_core]
> > [<c04835f0>] STTUNER_DrvInst+0x0/0xffff911c [sttuner_core]
> > [<c04836ec>] STTUNER_DrvInst+0xfc/0xffff911c [sttuner_core]
> > [<c04836ec>] STTUNER_DrvInst+0xfc/0xffff911c [sttuner_core]
> > [<c04848ec>] STTUNER_DrvInst+0x12fc/0xffff911c [sttuner_core]
> > [<c04848ec>] STTUNER_DrvInst+0x12fc/0xffff911c [sttuner_core]
> > [<c048492c>] STTUNER_DrvInst+0x133c/0xffff911c [sttuner_core]
> > [<8442b4e4>] kthread+0xe4/0x140
> > [<c046cfa0>] SATTASK_ScanTask+0x0/0x620 [sttuner_core]
> > [<c0483800>] STTUNER_DrvInst+0x210/0xffff911c [sttuner_core]
> > [<8440f4a0>] complete+0x0/0xc0
> > [<8442b3e0>] kthread_should_stop+0x0/0x20
> > [<84403004>] kernel_thread_helper+0x4/0x20
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
> --
> Steven Rostedt
> Senior Programmer
> Kihon Technologies
> (607)786-4830
>
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Question on Schedule and Preemption
2006-04-18 17:21 ` Liu haixiang
@ 2006-04-18 17:32 ` Steven Rostedt
0 siblings, 0 replies; 10+ messages in thread
From: Steven Rostedt @ 2006-04-18 17:32 UTC (permalink / raw)
To: Liu haixiang; +Cc: Andreas Mohr, linux-kernel
On Wed, 2006-04-19 at 01:21 +0800, Liu haixiang wrote:
> 2006/4/18, Steven Rostedt <rostedt@xxxxxx.com>:
Damn! I used my work email account to send that. I try to keep the spam
down on that account, so I don't publish it as much. Darn Evolution
keeps picking the wrong account.
> > On Tue, 2006-04-18 at 20:55 +0800, Liu haixiang wrote:
> >
> > Well according to your output, it was the task "TURNER0" with the pid
> > 611. After you recompile the kernel with CONFIG_FRAME_POINTERS you will
> > need to follow the stack trace and see what function turned off
> > preemption. This can happen calling a spin_lock and not unlocking it
> > before calling something that would schedule.
> >
>
> If it's true, it is a great help for me.
>
> > If you also turn on in "Kernel Hacking" -> "Compile the kernel with
> > debug info", you can then do a "gdb vmlinux" in the root directory of
> > the compile, and pass in the stack address with the command
> > "li *0xc042382e" to show where that function would return. (replace the
> > c042382e with the location you are looking for).
> >
> > Also, what arch are you using to get a 0x04000000 in the preempt_count
> > (the 0x1 is the depth). Of course I'm looking at 2.6.17-rc1 and not the
> > one you are using. Hmm, your arch may not even support frame pointers.
> >
> > -- Steve
> >
>
> The arch is SH4.
Well I just tried a "make ARCH=sh menuconfig" and the
CONFIG_FRAME_POINTERS option is there. Whether it makes a difference or
not, I haven't the foggiest clue.
-- Steve
^ permalink raw reply [flat|nested] 10+ messages in thread
* RE: Question on Schedule and Preemption
@ 2006-04-18 13:31 Michael Guo
0 siblings, 0 replies; 10+ messages in thread
From: Michael Guo @ 2006-04-18 13:31 UTC (permalink / raw)
To: Liu haixiang, linux-kernel
Hi,
The comments above the piece of code give some hints about the sane checking. When call "schedule" for process scheduling, make sure that context isn't atomic. That is, schedule should be called in a safe place such as spinlock free etc. And you can also read do_exit() code to get more detailed information.
-----Original Message-----
From: linux-kernel-owner@vger.kernel.org
[mailto:linux-kernel-owner@vger.kernel.org]On Behalf Of Liu haixiang
Sent: Tuesday, April 18, 2006 3:23 AM
To: linux-kernel@vger.kernel.org
Subject: Question on Schedule and Preemption
Hi All,
Now I am developing the driver on Linux kernel 2.6.11. And I met the
problem that kernel will dump my stack from time to time. And the
kernel log will give me messages like "scheduling while atomic: ...".
Then I found the code in sched.c:
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();
}
}
Anybody can explain above code for me?
Thanks
best regards
Haixiang Liu
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 10+ messages in thread* Question on Schedule and Preemption
@ 2006-04-18 7:12 Liu haixiang
0 siblings, 0 replies; 10+ messages in thread
From: Liu haixiang @ 2006-04-18 7:12 UTC (permalink / raw)
To: linux-kernel
Hi All,
Now I am developing drivers on Linux 2.6.
My problem is that from time to time, I will get log meesage from
kernel: "scheduling while atomic ..." and the stack will be dumped by
the kernel.
Then I investigate the code in sched.c but don't understand. Anybody
can clarify this piece of code for me?
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();
}
}
Thanks a lot
Haixiang
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2006-04-18 17:33 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-04-18 7:23 Question on Schedule and Preemption Liu haixiang
2006-04-18 9:17 ` Andreas Mohr
2006-04-18 9:23 ` Arjan van de Ven
2006-04-18 9:28 ` Andreas Mohr
2006-04-18 12:55 ` Liu haixiang
2006-04-18 14:56 ` Steven Rostedt
2006-04-18 17:21 ` Liu haixiang
2006-04-18 17:32 ` Steven Rostedt
-- strict thread matches above, loose matches on Subject: below --
2006-04-18 13:31 Michael Guo
2006-04-18 7:12 Liu haixiang
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®