Commit 4e8ee7de227e3ab9a72040b448ad728c5428a042 (ARM: SMP: use
idmap_pgd for mapping MMU enable during secondary booting)
switched secondary boot to use idmap_pgd, which is initialized
during early_initcall, instead of a page table initialized during
__cpu_up. This causes idmap_pgd to contain the static mappings
but be missing all dynamic mappings.
If a console is registered that creates a dynamic mapping, the
printk in secondary_start_kernel will trigger a data abort on
the missing mapping before the exception handlers have been
initialized, leading to a hang. Initial boot is not affected
because no consoles have been registered, and resume is usually
not affected because the offending console is suspended.
Onlining a cpu with hotplug triggers the problem.
A workaround is to the printk in secondary_start_kernel until
after the page tables have been switched back to init_mm.
Signed-off-by: Colin Cross <[email protected]>
---
arch/arm/kernel/smp.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
index addbbe8..aa98928 100644
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c
@@ -251,8 +251,6 @@ asmlinkage void __cpuinit secondary_start_kernel(void)
struct mm_struct *mm = &init_mm;
unsigned int cpu = smp_processor_id();
- printk("CPU%u: Booted secondary processor\n", cpu);
-
/*
* All kernel threads share the same mm context; grab a
* reference and switch to it.
@@ -264,6 +262,8 @@ asmlinkage void __cpuinit secondary_start_kernel(void)
enter_lazy_tlb(mm, current);
local_flush_tlb_all();
+ printk("CPU%u: Booted secondary processor\n", cpu);
+
cpu_init();
preempt_disable();
trace_hardirqs_off();
--
1.7.7.3
On Fri, May 04, 2012 at 06:14:02PM -0700, Colin Cross wrote:
> Commit 4e8ee7de227e3ab9a72040b448ad728c5428a042 (ARM: SMP: use
> idmap_pgd for mapping MMU enable during secondary booting)
> switched secondary boot to use idmap_pgd, which is initialized
> during early_initcall, instead of a page table initialized during
> __cpu_up. This causes idmap_pgd to contain the static mappings
> but be missing all dynamic mappings.
>
> If a console is registered that creates a dynamic mapping, the
> printk in secondary_start_kernel will trigger a data abort on
> the missing mapping before the exception handlers have been
> initialized, leading to a hang. Initial boot is not affected
> because no consoles have been registered, and resume is usually
> not affected because the offending console is suspended.
> Onlining a cpu with hotplug triggers the problem.
>
> A workaround is to the printk in secondary_start_kernel until
> after the page tables have been switched back to init_mm.
I think this is fine. Please put it in the patch system, thanks.
On Sat, May 05, 2012 at 05:49:33PM +0100, Russell King - ARM Linux wrote:
> I think this is fine. Please put it in the patch system, thanks.
It looks like this bug affects v3.2 kernels as well - should it be marked
for the attention of the stable kernel team?
On Sun, May 6, 2012 at 3:11 AM, Russell King - ARM Linux
<[email protected]> wrote:
> On Sat, May 05, 2012 at 05:49:33PM +0100, Russell King - ARM Linux wrote:
>> I think this is fine. ?Please put it in the patch system, thanks.
>
> It looks like this bug affects v3.2 kernels as well - should it be marked
> for the attention of the stable kernel team?
I think it was introduced in v3.3, it should probably go to stable.
Hi Colin,
Sorry for the delayed response.
On Sat, May 05, 2012 at 02:14:02AM +0100, Colin Cross wrote:
> Commit 4e8ee7de227e3ab9a72040b448ad728c5428a042 (ARM: SMP: use
> idmap_pgd for mapping MMU enable during secondary booting)
> switched secondary boot to use idmap_pgd, which is initialized
> during early_initcall, instead of a page table initialized during
> __cpu_up. This causes idmap_pgd to contain the static mappings
> but be missing all dynamic mappings.
>
> If a console is registered that creates a dynamic mapping, the
> printk in secondary_start_kernel will trigger a data abort on
> the missing mapping before the exception handlers have been
> initialized, leading to a hang. Initial boot is not affected
> because no consoles have been registered, and resume is usually
> not affected because the offending console is suspended.
> Onlining a cpu with hotplug triggers the problem.
>
> A workaround is to the printk in secondary_start_kernel until
> after the page tables have been switched back to init_mm.
You missed a word out here (`delay'?) but it looks like Russell has taken
this now so I'm sure we'll cope.
Acked-by: Will Deacon <[email protected]>
Will