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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
