Re: BUG - "scheduling while atomic" on a irq handler (s3c-mci)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: Christophe Huriaux <c.huriaux@xxxxxxxxx>
- Subject: Re: BUG - "scheduling while atomic" on a irq handler (s3c-mci)
- From: Uwe Kleine-König <u.kleine-koenig@xxxxxxxxxxxxxx>
- Date: Wed, 9 May 2012 19:49:31 +0200
- Cc: linux-rt-users@xxxxxxxxxxxxxxx
- In-reply-to: <CAEOomG9NEoQKqp=pMx0NpzGaFpHBimALwhemnZL4F-8g7XURkA@mail.gmail.com>
- References: <CAEOomG9NEoQKqp=pMx0NpzGaFpHBimALwhemnZL4F-8g7XURkA@mail.gmail.com>
- User-agent: Mutt/1.5.21 (2010-09-15)
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
[RT Stable]
[Kernel Newbies]
[Share Photos]
[IDE]
[Security]
[Git]
[Netfilter]
[Bugtraq]
[Photo]
[Yosemite]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Linux ATA RAID]
[Samba]
[Video 4 Linux]
[Device Mapper]
[Linux Resources]