Re: BUG - "scheduling while atomic" on a irq handler (s3c-mci)

["Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>]

Hi Christophe,

On Wed, May 09, 2012 at 04:07:13PM +0200, Christophe Huriaux wrote:
>    I am facing a problem while trying to run a rt-patched 3.2.y kernel
> with PREEMPT_RT_FULL on a mini2440 board (ARM based s3c2440 SoC) :
> whilst a vanilla kernel (with PREEMPT_LL) works like a charm,
> PREEMPT_RTB and PREEMPT_RT_FULL makes the MMC/SD driver  (s3cmci)
> hang, which result in the kernel waiting indefinitely for the root fs
> to mount.
> 
>   I think that the IRQ handling of the driver is somehow disturbed by
> the changes made by the RT patch. When using PREEMPT_RTB I can see the
> following message in the console :
> 
> BUG: scheduling while atomic: irq/37-s3c-mci/253/0x00000102
> Modules linked in:
> Function entered at [<c000e90c>] from [<c029f478>]
> Function entered at [<c029f478>] from [<c029fc3c>]
> Function entered at [<c029fc3c>] from [<c00559c0>]
> Function entered at [<c00559c0>] from [<c01dd4c8>]
> Function entered at [<c01dd4c8>] from [<c0024a0c>]
> Function entered at [<c0024a0c>] from [<c0024d9c>]
> Function entered at [<c0024d9c>] from [<c0024fe8>]
> Function entered at [<c0024fe8>] from [<c0025140>]
> Function entered at [<c0025140>] from [<c00549f0>]
> Function entered at [<c00549f0>] from [<c00547c4>]
> Function entered at [<c00547c4>] from [<c0039954>]
> Function entered at [<c0039954>] from [<c000a120>]

If you enable CONFIG_KALLSYMS you get a more usable backtrace.
Alternatively you can use

	$CROSS_COMPILE-addr2line -e vmlinux 0xc000e90c

to get the file and line that resulted in the code at that address.

>   When I run the kernel under Qemu, debug through gdb and put a
> breakpoint on unwind_backtace the details of the previous backtrace is
> :
> 
> #0  unwind_backtrace (regs=0x0, tsk=0x0) at arch/arm/kernel/unwind.c:409
> #1  0xc029f478 in schedule_debug (prev=<optimized out>) at kernel/sched.c:4357
> #2  __schedule () at kernel/sched.c:4537
> #3  0xc029fc3c in schedule () at kernel/sched.c:4625
> #4  0xc00559c0 in synchronize_irq (irq=<optimized out>) at
> kernel/irq/manage.c:73
> Backtrace stopped: previous frame inner to this frame (corrupt stack?)
> 
>   I don't see the "bug" message with PREEMPT_RT_FULL, the kernel just
> hang waiting for the rootfs. The problem did not occur in the 2.6.y
> tree AFAIK.
My guess is that for PREEMPT_RT_FULL the printk just doesn't make it to
your console driver because the data would only be given to it when the
atomic block is done.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html