[PATCH] ARM: Fix r7/r11 confusion when CONFIG_THUMB2_KERNEL=y

[PATCH] ARM: Fix r7/r11 confusion when CONFIG_THUMB2_KERNEL=y

[Jed Davis]

There is currently some inconsistency about the "frame pointer" on ARM.
r11 is the register with assemblers recognize and disassemblers often
print as "fp", and which is sufficient for stack unwinding when using
the APCS frame pointer option; but when unwinding with the Exception
Handling ABI, the register GCC uses when a constant offset won't suffice
(or when -fno-omit-frame-pointer is used; see kernel/sched/Makefile in
particular) is r11 on ARM and r7 on Thumb.

Correspondingly, arch/arm/include/uapi/arm/ptrace.h defines ARM_fp to
refer to r11, but arch/arm/kernel/unwind.c uses "FP" to mean either r11
or r7 depending on Thumbness, and it is unclear what other cases such as
the "fp" in struct stackframe should be doing.

Effects of this are probably limited to failure of EHABI unwinding when
starting from a function that uses r7 to restore its stack pointer, but
the possibility for further breakage (which would be invisible on
non-Thumb kernels) is worrying.

With this change, it is hoped, r7 is consistently referred to as "r7",
and "fp" always means r11; this costs a few extra ifdefs, but it should
help prevent future issues.

Signed-off-by: Jed Davis <jld@mozilla.com>
---
 arch/arm/include/asm/stacktrace.h  |    4 ++++
 arch/arm/include/asm/thread_info.h |    2 ++
 arch/arm/kernel/perf_event.c       |    4 ++++
 arch/arm/kernel/process.c          |    4 ++++
 arch/arm/kernel/time.c             |    4 ++++
 arch/arm/kernel/unwind.c           |   27 ++++++++++++++++++++++++++-
 arch/arm/oprofile/common.c         |    4 ++++
 7 files changed, 48 insertions(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/stacktrace.h b/arch/arm/include/asm/stacktrace.h
index 4d0a164..5e546bf 100644
--- a/arch/arm/include/asm/stacktrace.h
+++ b/arch/arm/include/asm/stacktrace.h
@@ -2,7 +2,11 @@
 #define __ASM_STACKTRACE_H
 
 struct stackframe {
+#ifdef CONFIG_THUMB2_KERNEL
+	unsigned long r7;
+#else
 	unsigned long fp;
+#endif
 	unsigned long sp;
 	unsigned long lr;
 	unsigned long pc;
diff --git a/arch/arm/include/asm/thread_info.h b/arch/arm/include/asm/thread_info.h
index 214d415..ae3cd81 100644
--- a/arch/arm/include/asm/thread_info.h
+++ b/arch/arm/include/asm/thread_info.h
@@ -105,6 +105,8 @@ static inline struct thread_info *current_thread_info(void)
 	((unsigned long)(task_thread_info(tsk)->cpu_context.sp))
 #define thread_saved_fp(tsk)	\
 	((unsigned long)(task_thread_info(tsk)->cpu_context.fp))
+#define thread_saved_r7(tsk)	\
+	((unsigned long)(task_thread_info(tsk)->cpu_context.r7))
 
 extern void crunch_task_disable(struct thread_info *);
 extern void crunch_task_copy(struct thread_info *, void *);
diff --git a/arch/arm/kernel/perf_event.c b/arch/arm/kernel/perf_event.c
index d9f5cd4..55776d6 100644
--- a/arch/arm/kernel/perf_event.c
+++ b/arch/arm/kernel/perf_event.c
@@ -601,7 +601,11 @@ perf_callchain_kernel(struct perf_callchain_entry *entry, struct pt_regs *regs)
 		return;
 	}
 
+#ifdef CONFIG_THUMB2_KERNEL
+	fr.r7 = regs->ARM_r7;
+#else
 	fr.fp = regs->ARM_fp;
+#endif
 	fr.sp = regs->ARM_sp;
 	fr.lr = regs->ARM_lr;
 	fr.pc = regs->ARM_pc;
diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c
index d3ca4f6..aeb4c28 100644
--- a/arch/arm/kernel/process.c
+++ b/arch/arm/kernel/process.c
@@ -405,7 +405,11 @@ unsigned long get_wchan(struct task_struct *p)
 	if (!p || p == current || p->state == TASK_RUNNING)
 		return 0;
 
+#ifdef CONFIG_THUMB2_KERNEL
+	frame.r7 = thread_saved_r7(p);
+#else
 	frame.fp = thread_saved_fp(p);
+#endif
 	frame.sp = thread_saved_sp(p);
 	frame.lr = 0;			/* recovered from the stack */
 	frame.pc = thread_saved_pc(p);
diff --git a/arch/arm/kernel/time.c b/arch/arm/kernel/time.c
index 98aee32..80410d3 100644
--- a/arch/arm/kernel/time.c
+++ b/arch/arm/kernel/time.c
@@ -49,7 +49,11 @@ unsigned long profile_pc(struct pt_regs *regs)
 	if (!in_lock_functions(regs->ARM_pc))
 		return regs->ARM_pc;
 
+#ifdef CONFIG_THUMB2_KERNEL
+	frame.r7 = regs->ARM_r7;
+#else
 	frame.fp = regs->ARM_fp;
+#endif
 	frame.sp = regs->ARM_sp;
 	frame.lr = regs->ARM_lr;
 	frame.pc = regs->ARM_pc;
diff --git a/arch/arm/kernel/unwind.c b/arch/arm/kernel/unwind.c
index 00df012..dec03ae 100644
--- a/arch/arm/kernel/unwind.c
+++ b/arch/arm/kernel/unwind.c
@@ -74,7 +74,7 @@ struct unwind_ctrl_block {
 
 enum regs {
 #ifdef CONFIG_THUMB2_KERNEL
-	FP = 7,
+	R7 = 7,
 #else
 	FP = 11,
 #endif
@@ -317,8 +317,13 @@ static int unwind_exec_insn(struct unwind_ctrl_block *ctrl)
 		return -URC_FAILURE;
 	}
 
+#ifdef CONFIG_THUMB2_KERNEL
+	pr_debug("%s: r7 = %08lx sp = %08lx lr = %08lx pc = %08lx\n", __func__,
+		 ctrl->vrs[R7], ctrl->vrs[SP], ctrl->vrs[LR], ctrl->vrs[PC]);
+#else
 	pr_debug("%s: fp = %08lx sp = %08lx lr = %08lx pc = %08lx\n", __func__,
 		 ctrl->vrs[FP], ctrl->vrs[SP], ctrl->vrs[LR], ctrl->vrs[PC]);
+#endif
 
 	return URC_OK;
 }
@@ -349,7 +354,11 @@ int unwind_frame(struct stackframe *frame)
 		return -URC_FAILURE;
 	}
 
+#ifdef CONFIG_THUMB2_KERNEL
+	ctrl.vrs[R7] = frame->r7;
+#else
 	ctrl.vrs[FP] = frame->fp;
+#endif
 	ctrl.vrs[SP] = frame->sp;
 	ctrl.vrs[LR] = frame->lr;
 	ctrl.vrs[PC] = 0;
@@ -397,7 +406,11 @@ int unwind_frame(struct stackframe *frame)
 	if (frame->pc == ctrl.vrs[PC])
 		return -URC_FAILURE;
 
+#ifdef CONFIG_THUMB2_KERNEL
+	frame->r7 = ctrl.vrs[R7];
+#else
 	frame->fp = ctrl.vrs[FP];
+#endif
 	frame->sp = ctrl.vrs[SP];
 	frame->lr = ctrl.vrs[LR];
 	frame->pc = ctrl.vrs[PC];
@@ -416,20 +429,32 @@ void unwind_backtrace(struct pt_regs *regs, struct task_struct *tsk)
 		tsk = current;
 
 	if (regs) {
+#ifdef CONFIG_THUMB2_KERNEL
+		frame.r7 = regs->ARM_r7;
+#else
 		frame.fp = regs->ARM_fp;
+#endif
 		frame.sp = regs->ARM_sp;
 		frame.lr = regs->ARM_lr;
 		/* PC might be corrupted, use LR in that case. */
 		frame.pc = kernel_text_address(regs->ARM_pc)
 			 ? regs->ARM_pc : regs->ARM_lr;
 	} else if (tsk == current) {
+#ifdef CONFIG_THUMB2_KERNEL
+		frame.r7 = (unsigned long)__builtin_frame_address(0);
+#else
 		frame.fp = (unsigned long)__builtin_frame_address(0);
+#endif
 		frame.sp = current_sp;
 		frame.lr = (unsigned long)__builtin_return_address(0);
 		frame.pc = (unsigned long)unwind_backtrace;
 	} else {
 		/* task blocked in __switch_to */
+#ifdef CONFIG_THUMB2_KERNEL
+		frame.r7 = thread_saved_r7(tsk);
+#else
 		frame.fp = thread_saved_fp(tsk);
+#endif
 		frame.sp = thread_saved_sp(tsk);
 		/*
 		 * The function calling __switch_to cannot be a leaf function
diff --git a/arch/arm/oprofile/common.c b/arch/arm/oprofile/common.c
index 99c63d4b..38cbfff 100644
--- a/arch/arm/oprofile/common.c
+++ b/arch/arm/oprofile/common.c
@@ -107,7 +107,11 @@ static void arm_backtrace(struct pt_regs * const regs, unsigned int depth)
 
 	if (!user_mode(regs)) {
 		struct stackframe frame;
+#ifdef CONFIG_THUMB2_KERNEL
+		frame.r7 = regs->ARM_r7;
+#else
 		frame.fp = regs->ARM_fp;
+#endif
 		frame.sp = regs->ARM_sp;
 		frame.lr = regs->ARM_lr;
 		frame.pc = regs->ARM_pc;
-- 
1.7.10.4

[PATCH] ARM: Fix r7/r11 confusion when CONFIG_THUMB2_KERNEL=y

[Jed Davis]

There is currently some inconsistency about the "frame pointer" on ARM.
r11 is the register with assemblers recognize and disassemblers often
print as "fp", and which is sufficient for stack unwinding when using
the APCS frame pointer option; but when unwinding with the Exception
Handling ABI, the register GCC uses when a constant offset won't suffice
(or when -fno-omit-frame-pointer is used; see kernel/sched/Makefile in
particular) is r11 on ARM and r7 on Thumb.

Correspondingly, arch/arm/include/uapi/arm/ptrace.h defines ARM_fp to
refer to r11, but arch/arm/kernel/unwind.c uses "FP" to mean either r11
or r7 depending on Thumbness, and it is unclear what other cases such as
the "fp" in struct stackframe should be doing.

Effects of this are probably limited to failure of EHABI unwinding when
starting from a function that uses r7 to restore its stack pointer, but
the possibility for further breakage (which would be invisible on
non-Thumb kernels) is worrying.

With this change, it is hoped, r7 is consistently referred to as "r7",
and "fp" always means r11; this costs a few extra ifdefs, but it should
help prevent future issues.

Signed-off-by: Jed Davis <jld@mozilla.com>
---
 arch/arm/include/asm/stacktrace.h  |    4 ++++
 arch/arm/include/asm/thread_info.h |    2 ++
 arch/arm/kernel/perf_event.c       |    4 ++++
 arch/arm/kernel/process.c          |    4 ++++
 arch/arm/kernel/time.c             |    4 ++++
 arch/arm/kernel/unwind.c           |   27 ++++++++++++++++++++++++++-
 arch/arm/oprofile/common.c         |    4 ++++
 7 files changed, 48 insertions(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/stacktrace.h b/arch/arm/include/asm/stacktrace.h
index 4d0a164..5e546bf 100644
--- a/arch/arm/include/asm/stacktrace.h
+++ b/arch/arm/include/asm/stacktrace.h
@@ -2,7 +2,11 @@
 #define __ASM_STACKTRACE_H
 
 struct stackframe {
+#ifdef CONFIG_THUMB2_KERNEL
+	unsigned long r7;
+#else
 	unsigned long fp;
+#endif
 	unsigned long sp;
 	unsigned long lr;
 	unsigned long pc;
diff --git a/arch/arm/include/asm/thread_info.h b/arch/arm/include/asm/thread_info.h
index 214d415..ae3cd81 100644
--- a/arch/arm/include/asm/thread_info.h
+++ b/arch/arm/include/asm/thread_info.h
@@ -105,6 +105,8 @@ static inline struct thread_info *current_thread_info(void)
 	((unsigned long)(task_thread_info(tsk)->cpu_context.sp))
 #define thread_saved_fp(tsk)	\
 	((unsigned long)(task_thread_info(tsk)->cpu_context.fp))
+#define thread_saved_r7(tsk)	\
+	((unsigned long)(task_thread_info(tsk)->cpu_context.r7))
 
 extern void crunch_task_disable(struct thread_info *);
 extern void crunch_task_copy(struct thread_info *, void *);
diff --git a/arch/arm/kernel/perf_event.c b/arch/arm/kernel/perf_event.c
index d9f5cd4..55776d6 100644
--- a/arch/arm/kernel/perf_event.c
+++ b/arch/arm/kernel/perf_event.c
@@ -601,7 +601,11 @@ perf_callchain_kernel(struct perf_callchain_entry *entry, struct pt_regs *regs)
 		return;
 	}
 
+#ifdef CONFIG_THUMB2_KERNEL
+	fr.r7 = regs->ARM_r7;
+#else
 	fr.fp = regs->ARM_fp;
+#endif
 	fr.sp = regs->ARM_sp;
 	fr.lr = regs->ARM_lr;
 	fr.pc = regs->ARM_pc;
diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c
index d3ca4f6..aeb4c28 100644
--- a/arch/arm/kernel/process.c
+++ b/arch/arm/kernel/process.c
@@ -405,7 +405,11 @@ unsigned long get_wchan(struct task_struct *p)
 	if (!p || p == current || p->state == TASK_RUNNING)
 		return 0;
 
+#ifdef CONFIG_THUMB2_KERNEL
+	frame.r7 = thread_saved_r7(p);
+#else
 	frame.fp = thread_saved_fp(p);
+#endif
 	frame.sp = thread_saved_sp(p);
 	frame.lr = 0;			/* recovered from the stack */
 	frame.pc = thread_saved_pc(p);
diff --git a/arch/arm/kernel/time.c b/arch/arm/kernel/time.c
index 98aee32..80410d3 100644
--- a/arch/arm/kernel/time.c
+++ b/arch/arm/kernel/time.c
@@ -49,7 +49,11 @@ unsigned long profile_pc(struct pt_regs *regs)
 	if (!in_lock_functions(regs->ARM_pc))
 		return regs->ARM_pc;
 
+#ifdef CONFIG_THUMB2_KERNEL
+	frame.r7 = regs->ARM_r7;
+#else
 	frame.fp = regs->ARM_fp;
+#endif
 	frame.sp = regs->ARM_sp;
 	frame.lr = regs->ARM_lr;
 	frame.pc = regs->ARM_pc;
diff --git a/arch/arm/kernel/unwind.c b/arch/arm/kernel/unwind.c
index 00df012..dec03ae 100644
--- a/arch/arm/kernel/unwind.c
+++ b/arch/arm/kernel/unwind.c
@@ -74,7 +74,7 @@ struct unwind_ctrl_block {
 
 enum regs {
 #ifdef CONFIG_THUMB2_KERNEL
-	FP = 7,
+	R7 = 7,
 #else
 	FP = 11,
 #endif
@@ -317,8 +317,13 @@ static int unwind_exec_insn(struct unwind_ctrl_block *ctrl)
 		return -URC_FAILURE;
 	}
 
+#ifdef CONFIG_THUMB2_KERNEL
+	pr_debug("%s: r7 = %08lx sp = %08lx lr = %08lx pc = %08lx\n", __func__,
+		 ctrl->vrs[R7], ctrl->vrs[SP], ctrl->vrs[LR], ctrl->vrs[PC]);
+#else
 	pr_debug("%s: fp = %08lx sp = %08lx lr = %08lx pc = %08lx\n", __func__,
 		 ctrl->vrs[FP], ctrl->vrs[SP], ctrl->vrs[LR], ctrl->vrs[PC]);
+#endif
 
 	return URC_OK;
 }
@@ -349,7 +354,11 @@ int unwind_frame(struct stackframe *frame)
 		return -URC_FAILURE;
 	}
 
+#ifdef CONFIG_THUMB2_KERNEL
+	ctrl.vrs[R7] = frame->r7;
+#else
 	ctrl.vrs[FP] = frame->fp;
+#endif
 	ctrl.vrs[SP] = frame->sp;
 	ctrl.vrs[LR] = frame->lr;
 	ctrl.vrs[PC] = 0;
@@ -397,7 +406,11 @@ int unwind_frame(struct stackframe *frame)
 	if (frame->pc == ctrl.vrs[PC])
 		return -URC_FAILURE;
 
+#ifdef CONFIG_THUMB2_KERNEL
+	frame->r7 = ctrl.vrs[R7];
+#else
 	frame->fp = ctrl.vrs[FP];
+#endif
 	frame->sp = ctrl.vrs[SP];
 	frame->lr = ctrl.vrs[LR];
 	frame->pc = ctrl.vrs[PC];
@@ -416,20 +429,32 @@ void unwind_backtrace(struct pt_regs *regs, struct task_struct *tsk)
 		tsk = current;
 
 	if (regs) {
+#ifdef CONFIG_THUMB2_KERNEL
+		frame.r7 = regs->ARM_r7;
+#else
 		frame.fp = regs->ARM_fp;
+#endif
 		frame.sp = regs->ARM_sp;
 		frame.lr = regs->ARM_lr;
 		/* PC might be corrupted, use LR in that case. */
 		frame.pc = kernel_text_address(regs->ARM_pc)
 			 ? regs->ARM_pc : regs->ARM_lr;
 	} else if (tsk == current) {
+#ifdef CONFIG_THUMB2_KERNEL
+		frame.r7 = (unsigned long)__builtin_frame_address(0);
+#else
 		frame.fp = (unsigned long)__builtin_frame_address(0);
+#endif
 		frame.sp = current_sp;
 		frame.lr = (unsigned long)__builtin_return_address(0);
 		frame.pc = (unsigned long)unwind_backtrace;
 	} else {
 		/* task blocked in __switch_to */
+#ifdef CONFIG_THUMB2_KERNEL
+		frame.r7 = thread_saved_r7(tsk);
+#else
 		frame.fp = thread_saved_fp(tsk);
+#endif
 		frame.sp = thread_saved_sp(tsk);
 		/*
 		 * The function calling __switch_to cannot be a leaf function
diff --git a/arch/arm/oprofile/common.c b/arch/arm/oprofile/common.c
index 99c63d4b..38cbfff 100644
--- a/arch/arm/oprofile/common.c
+++ b/arch/arm/oprofile/common.c
@@ -107,7 +107,11 @@ static void arm_backtrace(struct pt_regs * const regs, unsigned int depth)
 
 	if (!user_mode(regs)) {
 		struct stackframe frame;
+#ifdef CONFIG_THUMB2_KERNEL
+		frame.r7 = regs->ARM_r7;
+#else
 		frame.fp = regs->ARM_fp;
+#endif
 		frame.sp = regs->ARM_sp;
 		frame.lr = regs->ARM_lr;
 		frame.pc = regs->ARM_pc;
-- 
1.7.10.4

Re: [PATCH] ARM: Fix r7/r11 confusion when CONFIG_THUMB2_KERNEL=y

[Will Deacon]

Hi Jed,

On Sat, Jul 13, 2013 at 04:18:20AM +0100, Jed Davis wrote:
> There is currently some inconsistency about the "frame pointer" on ARM.
> r11 is the register with assemblers recognize and disassemblers often
> print as "fp", and which is sufficient for stack unwinding when using
> the APCS frame pointer option; but when unwinding with the Exception
> Handling ABI, the register GCC uses when a constant offset won't suffice
> (or when -fno-omit-frame-pointer is used; see kernel/sched/Makefile in
> particular) is r11 on ARM and r7 on Thumb.
> 
> Correspondingly, arch/arm/include/uapi/arm/ptrace.h defines ARM_fp to
> refer to r11, but arch/arm/kernel/unwind.c uses "FP" to mean either r11
> or r7 depending on Thumbness, and it is unclear what other cases such as
> the "fp" in struct stackframe should be doing.
> 
> Effects of this are probably limited to failure of EHABI unwinding when
> starting from a function that uses r7 to restore its stack pointer, but
> the possibility for further breakage (which would be invisible on
> non-Thumb kernels) is worrying.
> 
> With this change, it is hoped, r7 is consistently referred to as "r7",
> and "fp" always means r11; this costs a few extra ifdefs, but it should
> help prevent future issues.

I'm struggling to understand exactly the problem that this patch is trying
to address. If it's just a code consistency issue, I don't think it's worth
it (I actually find it less confusing the way we currently have things) but
if there is a real bug, perhaps you could provide a testcase?

Cheers,

Will

[PATCH] ARM: Fix r7/r11 confusion when CONFIG_THUMB2_KERNEL=y

[Will Deacon]

Hi Jed,

On Sat, Jul 13, 2013 at 04:18:20AM +0100, Jed Davis wrote:
> There is currently some inconsistency about the "frame pointer" on ARM.
> r11 is the register with assemblers recognize and disassemblers often
> print as "fp", and which is sufficient for stack unwinding when using
> the APCS frame pointer option; but when unwinding with the Exception
> Handling ABI, the register GCC uses when a constant offset won't suffice
> (or when -fno-omit-frame-pointer is used; see kernel/sched/Makefile in
> particular) is r11 on ARM and r7 on Thumb.
> 
> Correspondingly, arch/arm/include/uapi/arm/ptrace.h defines ARM_fp to
> refer to r11, but arch/arm/kernel/unwind.c uses "FP" to mean either r11
> or r7 depending on Thumbness, and it is unclear what other cases such as
> the "fp" in struct stackframe should be doing.
> 
> Effects of this are probably limited to failure of EHABI unwinding when
> starting from a function that uses r7 to restore its stack pointer, but
> the possibility for further breakage (which would be invisible on
> non-Thumb kernels) is worrying.
> 
> With this change, it is hoped, r7 is consistently referred to as "r7",
> and "fp" always means r11; this costs a few extra ifdefs, but it should
> help prevent future issues.

I'm struggling to understand exactly the problem that this patch is trying
to address. If it's just a code consistency issue, I don't think it's worth
it (I actually find it less confusing the way we currently have things) but
if there is a real bug, perhaps you could provide a testcase?

Cheers,

Will

Re: [PATCH] ARM: Fix r7/r11 confusion when CONFIG_THUMB2_KERNEL=y

[Jed Davis]

On Mon, Jul 15, 2013 at 02:54:20PM +0100, Will Deacon wrote:
> On Sat, Jul 13, 2013 at 04:18:20AM +0100, Jed Davis wrote:
[...]
> > Effects of this are probably limited to failure of EHABI unwinding when
> > starting from a function that uses r7 to restore its stack pointer, but
> > the possibility for further breakage (which would be invisible on
> > non-Thumb kernels) is worrying.
[...]
> I'm struggling to understand exactly the problem that this patch is trying
> to address. If it's just a code consistency issue, I don't think it's worth
> it (I actually find it less confusing the way we currently have things) but
> if there is a real bug, perhaps you could provide a testcase?

There is a real bug here, but my commit message wasn't very clear.  This
was breaking PERF_COUNT_SW_CONTEXT_SWITCHES with CONFIG_THUMB2_KERNEL=y
(with my other recently posted patch applied), because kernel/sched.c is
built with -fno-omit-frame-pointer (which is wrong, but that's a problem
for another patch) and so __schedule's EHABI entry uses 0x97 (mov sp, r7),
and somewhere along the line the unwinder gets the r11 value instead.
This would also apply to any function with a variable-length array, but
__schedule happens to have the perf hook I was trying to use.

I should add that this bug doesn't affect me directly at the moment,
because we're not currently using CONFIG_THUMB2_KERNEL on Firefox OS,
because our kernels are assorted older versions with hardware vendors'
changes and there are some issues with it.  But I felt it was worth
tracking this down before trying to send changes upstream.

The "right" thing to do here might be to just include all the registers,
or at least {r4-pc}, in struct stackframe.  The parts that aren't {fp,
sp, lr, pc} could be ifdef'ed if we're concerned enough about the
overhead in kernels using APCS frame pointer unwinding.

I agree that a test case would be good -- I'm more than a little worried
of regressions without one -- but I could use some advice on how best to
do that.

--Jed

[PATCH] ARM: Fix r7/r11 confusion when CONFIG_THUMB2_KERNEL=y

[Jed Davis]

On Mon, Jul 15, 2013 at 02:54:20PM +0100, Will Deacon wrote:
> On Sat, Jul 13, 2013 at 04:18:20AM +0100, Jed Davis wrote:
[...]
> > Effects of this are probably limited to failure of EHABI unwinding when
> > starting from a function that uses r7 to restore its stack pointer, but
> > the possibility for further breakage (which would be invisible on
> > non-Thumb kernels) is worrying.
[...]
> I'm struggling to understand exactly the problem that this patch is trying
> to address. If it's just a code consistency issue, I don't think it's worth
> it (I actually find it less confusing the way we currently have things) but
> if there is a real bug, perhaps you could provide a testcase?

There is a real bug here, but my commit message wasn't very clear.  This
was breaking PERF_COUNT_SW_CONTEXT_SWITCHES with CONFIG_THUMB2_KERNEL=y
(with my other recently posted patch applied), because kernel/sched.c is
built with -fno-omit-frame-pointer (which is wrong, but that's a problem
for another patch) and so __schedule's EHABI entry uses 0x97 (mov sp, r7),
and somewhere along the line the unwinder gets the r11 value instead.
This would also apply to any function with a variable-length array, but
__schedule happens to have the perf hook I was trying to use.

I should add that this bug doesn't affect me directly at the moment,
because we're not currently using CONFIG_THUMB2_KERNEL on Firefox OS,
because our kernels are assorted older versions with hardware vendors'
changes and there are some issues with it.  But I felt it was worth
tracking this down before trying to send changes upstream.

The "right" thing to do here might be to just include all the registers,
or at least {r4-pc}, in struct stackframe.  The parts that aren't {fp,
sp, lr, pc} could be ifdef'ed if we're concerned enough about the
overhead in kernels using APCS frame pointer unwinding.

I agree that a test case would be good -- I'm more than a little worried
of regressions without one -- but I could use some advice on how best to
do that.

--Jed

Re: [PATCH] ARM: Fix r7/r11 confusion when CONFIG_THUMB2_KERNEL=y

[Will Deacon]

Hello Jed,

Thanks for the reply.

On Sat, Jul 20, 2013 at 05:46:55AM +0100, Jed Davis wrote:
> On Mon, Jul 15, 2013 at 02:54:20PM +0100, Will Deacon wrote:
> > On Sat, Jul 13, 2013 at 04:18:20AM +0100, Jed Davis wrote:
> [...]
> > > Effects of this are probably limited to failure of EHABI unwinding when
> > > starting from a function that uses r7 to restore its stack pointer, but
> > > the possibility for further breakage (which would be invisible on
> > > non-Thumb kernels) is worrying.
> [...]
> > I'm struggling to understand exactly the problem that this patch is trying
> > to address. If it's just a code consistency issue, I don't think it's worth
> > it (I actually find it less confusing the way we currently have things) but
> > if there is a real bug, perhaps you could provide a testcase?
> 
> There is a real bug here, but my commit message wasn't very clear.  This
> was breaking PERF_COUNT_SW_CONTEXT_SWITCHES with CONFIG_THUMB2_KERNEL=y
> (with my other recently posted patch applied), because kernel/sched.c is
> built with -fno-omit-frame-pointer (which is wrong, but that's a problem
> for another patch) and so __schedule's EHABI entry uses 0x97 (mov sp, r7),
> and somewhere along the line the unwinder gets the r11 value instead.
> This would also apply to any function with a variable-length array, but
> __schedule happens to have the perf hook I was trying to use.

Ok, I think I'm with you now. I also think that a better solution would be
to try and limit the r7/fp confusion to one place, perhaps behind something
like:

void arm_get_current_stackframe(struct pt_regs *regs, struct stackframe *frame);

then that function can act as the bridge between pt_regs (where we leave
everything as it is) and stackframe (where we assign either r7 or fp into
the fp member). Then we just fix up the call sites to pass the regs they're
interested in to our new function.

What do you think?

Will

[PATCH] ARM: Fix r7/r11 confusion when CONFIG_THUMB2_KERNEL=y

[Will Deacon]

Hello Jed,

Thanks for the reply.

On Sat, Jul 20, 2013 at 05:46:55AM +0100, Jed Davis wrote:
> On Mon, Jul 15, 2013 at 02:54:20PM +0100, Will Deacon wrote:
> > On Sat, Jul 13, 2013 at 04:18:20AM +0100, Jed Davis wrote:
> [...]
> > > Effects of this are probably limited to failure of EHABI unwinding when
> > > starting from a function that uses r7 to restore its stack pointer, but
> > > the possibility for further breakage (which would be invisible on
> > > non-Thumb kernels) is worrying.
> [...]
> > I'm struggling to understand exactly the problem that this patch is trying
> > to address. If it's just a code consistency issue, I don't think it's worth
> > it (I actually find it less confusing the way we currently have things) but
> > if there is a real bug, perhaps you could provide a testcase?
> 
> There is a real bug here, but my commit message wasn't very clear.  This
> was breaking PERF_COUNT_SW_CONTEXT_SWITCHES with CONFIG_THUMB2_KERNEL=y
> (with my other recently posted patch applied), because kernel/sched.c is
> built with -fno-omit-frame-pointer (which is wrong, but that's a problem
> for another patch) and so __schedule's EHABI entry uses 0x97 (mov sp, r7),
> and somewhere along the line the unwinder gets the r11 value instead.
> This would also apply to any function with a variable-length array, but
> __schedule happens to have the perf hook I was trying to use.

Ok, I think I'm with you now. I also think that a better solution would be
to try and limit the r7/fp confusion to one place, perhaps behind something
like:

void arm_get_current_stackframe(struct pt_regs *regs, struct stackframe *frame);

then that function can act as the bridge between pt_regs (where we leave
everything as it is) and stackframe (where we assign either r7 or fp into
the fp member). Then we just fix up the call sites to pass the regs they're
interested in to our new function.

What do you think?

Will

Re: [PATCH] ARM: Fix r7/r11 confusion when CONFIG_THUMB2_KERNEL=y

[Robert Richter]

On 21.07.13 22:37:53, Will Deacon wrote:
> Ok, I think I'm with you now. I also think that a better solution would be
> to try and limit the r7/fp confusion to one place, perhaps behind something
> like:
> 
> void arm_get_current_stackframe(struct pt_regs *regs, struct stackframe *frame);

In unwind_backtrace() there is already common code to do this and also
to get it from a task_struct. This could be ripped out. I would prefer
then the following function:

 void init_stackframe(struct stackframe *frame, struct pt_regs *regs,
      		      struct task_struct *tsk)

-Robert

[PATCH] ARM: Fix r7/r11 confusion when CONFIG_THUMB2_KERNEL=y

[Robert Richter]

On 21.07.13 22:37:53, Will Deacon wrote:
> Ok, I think I'm with you now. I also think that a better solution would be
> to try and limit the r7/fp confusion to one place, perhaps behind something
> like:
> 
> void arm_get_current_stackframe(struct pt_regs *regs, struct stackframe *frame);

In unwind_backtrace() there is already common code to do this and also
to get it from a task_struct. This could be ripped out. I would prefer
then the following function:

 void init_stackframe(struct stackframe *frame, struct pt_regs *regs,
      		      struct task_struct *tsk)

-Robert

Re: [PATCH] ARM: Fix r7/r11 confusion when CONFIG_THUMB2_KERNEL=y

[Dave Martin]

On Sun, Jul 21, 2013 at 10:37:53PM +0100, Will Deacon wrote:
> Hello Jed,
> 
> Thanks for the reply.
> 
> On Sat, Jul 20, 2013 at 05:46:55AM +0100, Jed Davis wrote:
> > On Mon, Jul 15, 2013 at 02:54:20PM +0100, Will Deacon wrote:
> > > On Sat, Jul 13, 2013 at 04:18:20AM +0100, Jed Davis wrote:
> > [...]
> > > > Effects of this are probably limited to failure of EHABI unwinding when
> > > > starting from a function that uses r7 to restore its stack pointer, but
> > > > the possibility for further breakage (which would be invisible on
> > > > non-Thumb kernels) is worrying.
> > [...]
> > > I'm struggling to understand exactly the problem that this patch is trying
> > > to address. If it's just a code consistency issue, I don't think it's worth
> > > it (I actually find it less confusing the way we currently have things) but
> > > if there is a real bug, perhaps you could provide a testcase?
> > 
> > There is a real bug here, but my commit message wasn't very clear.  This
> > was breaking PERF_COUNT_SW_CONTEXT_SWITCHES with CONFIG_THUMB2_KERNEL=y
> > (with my other recently posted patch applied), because kernel/sched.c is
> > built with -fno-omit-frame-pointer (which is wrong, but that's a problem
> > for another patch) and so __schedule's EHABI entry uses 0x97 (mov sp, r7),
> > and somewhere along the line the unwinder gets the r11 value instead.
> > This would also apply to any function with a variable-length array, but
> > __schedule happens to have the perf hook I was trying to use.
> 
> Ok, I think I'm with you now. I also think that a better solution would be
> to try and limit the r7/fp confusion to one place, perhaps behind something
> like:
> 
> void arm_get_current_stackframe(struct pt_regs *regs, struct stackframe *frame);
> 
> then that function can act as the bridge between pt_regs (where we leave
> everything as it is) and stackframe (where we assign either r7 or fp into
> the fp member). Then we just fix up the call sites to pass the regs they're
> interested in to our new function.
> 
> What do you think?

Do the ARM unwind tables guarantee not to need knowledge of any
virtual registers for the purpose of processing the opcodes of a single
function's unwind table entry, except those virtual regs that we happen
to initialise?  Or do we just rely on luck?

For compiler-generated unwind entries, sp is likely to be enough in most
cases... but I think that may be more a gcc implementation detail than
an ABI guarantee.  For custom unwind entries (we do have a few of those)
I think all bets might be off... but again, there's a limit to how
insane those are likely to be in practice, and there aren't many of
them.

If the unwind tables might need the value of r7 (or other random
registers), then we need r7 (or all possible regs) in struct stackframe.


Compiling a function with a simple runtime-sized array causes GCC
to generate:

        .setfp r7, sp, #0

among the unwind annotations, so the unwind opcodes will definitely
refer to r7 in that case.  But r7 is not a magic register in the ABI, so
I think the compiler would be allowed to use any other register for the
same purpose...

Frames of this sort will be relatively unusual, which might be why this
wasn't identified as a problem earlier.


GCC's commitment to r7 if a frame pointer is needed in Thumb appears
quite strong, even with -fomit-frame-pointer... but this is still
an implementation detail of GCC and a legacy of Thumb-1, rather than
ABI.

A variable-sized frame seems to cause GCC to force r7 as a framepointer
anyway.  Trying to clobber r7 from an asm within such a frame results
in a compile error, even with -fomit-frame-pointer.


The purist answer seems to be: we might need all the regs in struct
stackframe.

The pragmatic answer might be that we definitely need r7 for Thumb code,
but given the nimbleness of GCC to evolve we might get away with not
including extra registers for a long time yet.  Thumb code probably
doesn't use r11 ("fp") in the same way, though that will be needed for
ARM (with or without ARM_UNWIND).

A review of existing custom unwind annotations might be a good idea
anyway, to check whether any of them requires another register right now.


Cheers
---Dave

[PATCH] ARM: Fix r7/r11 confusion when CONFIG_THUMB2_KERNEL=y

[Dave Martin]

On Sun, Jul 21, 2013 at 10:37:53PM +0100, Will Deacon wrote:
> Hello Jed,
> 
> Thanks for the reply.
> 
> On Sat, Jul 20, 2013 at 05:46:55AM +0100, Jed Davis wrote:
> > On Mon, Jul 15, 2013 at 02:54:20PM +0100, Will Deacon wrote:
> > > On Sat, Jul 13, 2013 at 04:18:20AM +0100, Jed Davis wrote:
> > [...]
> > > > Effects of this are probably limited to failure of EHABI unwinding when
> > > > starting from a function that uses r7 to restore its stack pointer, but
> > > > the possibility for further breakage (which would be invisible on
> > > > non-Thumb kernels) is worrying.
> > [...]
> > > I'm struggling to understand exactly the problem that this patch is trying
> > > to address. If it's just a code consistency issue, I don't think it's worth
> > > it (I actually find it less confusing the way we currently have things) but
> > > if there is a real bug, perhaps you could provide a testcase?
> > 
> > There is a real bug here, but my commit message wasn't very clear.  This
> > was breaking PERF_COUNT_SW_CONTEXT_SWITCHES with CONFIG_THUMB2_KERNEL=y
> > (with my other recently posted patch applied), because kernel/sched.c is
> > built with -fno-omit-frame-pointer (which is wrong, but that's a problem
> > for another patch) and so __schedule's EHABI entry uses 0x97 (mov sp, r7),
> > and somewhere along the line the unwinder gets the r11 value instead.
> > This would also apply to any function with a variable-length array, but
> > __schedule happens to have the perf hook I was trying to use.
> 
> Ok, I think I'm with you now. I also think that a better solution would be
> to try and limit the r7/fp confusion to one place, perhaps behind something
> like:
> 
> void arm_get_current_stackframe(struct pt_regs *regs, struct stackframe *frame);
> 
> then that function can act as the bridge between pt_regs (where we leave
> everything as it is) and stackframe (where we assign either r7 or fp into
> the fp member). Then we just fix up the call sites to pass the regs they're
> interested in to our new function.
> 
> What do you think?

Do the ARM unwind tables guarantee not to need knowledge of any
virtual registers for the purpose of processing the opcodes of a single
function's unwind table entry, except those virtual regs that we happen
to initialise?  Or do we just rely on luck?

For compiler-generated unwind entries, sp is likely to be enough in most
cases... but I think that may be more a gcc implementation detail than
an ABI guarantee.  For custom unwind entries (we do have a few of those)
I think all bets might be off... but again, there's a limit to how
insane those are likely to be in practice, and there aren't many of
them.

If the unwind tables might need the value of r7 (or other random
registers), then we need r7 (or all possible regs) in struct stackframe.


Compiling a function with a simple runtime-sized array causes GCC
to generate:

        .setfp r7, sp, #0

among the unwind annotations, so the unwind opcodes will definitely
refer to r7 in that case.  But r7 is not a magic register in the ABI, so
I think the compiler would be allowed to use any other register for the
same purpose...

Frames of this sort will be relatively unusual, which might be why this
wasn't identified as a problem earlier.


GCC's commitment to r7 if a frame pointer is needed in Thumb appears
quite strong, even with -fomit-frame-pointer... but this is still
an implementation detail of GCC and a legacy of Thumb-1, rather than
ABI.

A variable-sized frame seems to cause GCC to force r7 as a framepointer
anyway.  Trying to clobber r7 from an asm within such a frame results
in a compile error, even with -fomit-frame-pointer.


The purist answer seems to be: we might need all the regs in struct
stackframe.

The pragmatic answer might be that we definitely need r7 for Thumb code,
but given the nimbleness of GCC to evolve we might get away with not
including extra registers for a long time yet.  Thumb code probably
doesn't use r11 ("fp") in the same way, though that will be needed for
ARM (with or without ARM_UNWIND).

A review of existing custom unwind annotations might be a good idea
anyway, to check whether any of them requires another register right now.


Cheers
---Dave

Re: [PATCH] ARM: Fix r7/r11 confusion when CONFIG_THUMB2_KERNEL=y

[Jed Davis]

On Mon, Jul 22, 2013 at 07:52:39PM +0100, Dave Martin wrote:
> On Sun, Jul 21, 2013 at 10:37:53PM +0100, Will Deacon wrote:
> > Ok, I think I'm with you now. I also think that a better solution would be
> > to try and limit the r7/fp confusion to one place, perhaps behind something
> > like:
> > 
> > void arm_get_current_stackframe(struct pt_regs *regs, struct stackframe *frame);
> > 
> > then that function can act as the bridge between pt_regs (where we leave
> > everything as it is) and stackframe (where we assign either r7 or fp into
> > the fp member). Then we just fix up the call sites to pass the regs they're
> > interested in to our new function.
> > 
> > What do you think?

I can see that being useful if we wanted to opacify struct stackframe,
but... all uses of stackframe that I see involve passing it to
unwind_frame, which expands it back out into an array of registers.
(Except with CONFIG_FRAME_POINTER, but "APCS variants that require a
frame pointer register are obsolete.")

So... why not make pt_regs and stackframe the same, and avoid the
translations entirely?

> Do the ARM unwind tables guarantee not to need knowledge of any
> virtual registers for the purpose of processing the opcodes of a single
> function's unwind table entry, except those virtual regs that we happen
> to initialise?  Or do we just rely on luck?

Yes, for some value of "luck".  The spec documents 0x90|N, for N a core
register number other than 13 or 15, as setting the vSP to the value of
virtual register N.  We can get away with some omissions for kernel code
(e.g., unwind.c doesn't handle saved floating point registers, nor adding
constants larger than 1024 to vSP), but is this one of them?

[...]
> The purist answer seems to be: we might need all the regs in struct
> stackframe.
> 
> The pragmatic answer might be that we definitely need r7 for Thumb code,
> but given the nimbleness of GCC to evolve we might get away with not
> including extra registers for a long time yet.

The other question to ask here might be: what does the "pragmatic
answer" gain us over the "purist answer"?

> A review of existing custom unwind annotations might be a good idea
> anyway, to check whether any of them requires another register right now.

`egrep -r '\.(setf|movs)p' arch/arm` finds nothing, for what it's worth.

--Jed

[PATCH] ARM: Fix r7/r11 confusion when CONFIG_THUMB2_KERNEL=y

[Jed Davis]

On Mon, Jul 22, 2013 at 07:52:39PM +0100, Dave Martin wrote:
> On Sun, Jul 21, 2013 at 10:37:53PM +0100, Will Deacon wrote:
> > Ok, I think I'm with you now. I also think that a better solution would be
> > to try and limit the r7/fp confusion to one place, perhaps behind something
> > like:
> > 
> > void arm_get_current_stackframe(struct pt_regs *regs, struct stackframe *frame);
> > 
> > then that function can act as the bridge between pt_regs (where we leave
> > everything as it is) and stackframe (where we assign either r7 or fp into
> > the fp member). Then we just fix up the call sites to pass the regs they're
> > interested in to our new function.
> > 
> > What do you think?

I can see that being useful if we wanted to opacify struct stackframe,
but... all uses of stackframe that I see involve passing it to
unwind_frame, which expands it back out into an array of registers.
(Except with CONFIG_FRAME_POINTER, but "APCS variants that require a
frame pointer register are obsolete.")

So... why not make pt_regs and stackframe the same, and avoid the
translations entirely?

> Do the ARM unwind tables guarantee not to need knowledge of any
> virtual registers for the purpose of processing the opcodes of a single
> function's unwind table entry, except those virtual regs that we happen
> to initialise?  Or do we just rely on luck?

Yes, for some value of "luck".  The spec documents 0x90|N, for N a core
register number other than 13 or 15, as setting the vSP to the value of
virtual register N.  We can get away with some omissions for kernel code
(e.g., unwind.c doesn't handle saved floating point registers, nor adding
constants larger than 1024 to vSP), but is this one of them?

[...]
> The purist answer seems to be: we might need all the regs in struct
> stackframe.
> 
> The pragmatic answer might be that we definitely need r7 for Thumb code,
> but given the nimbleness of GCC to evolve we might get away with not
> including extra registers for a long time yet.

The other question to ask here might be: what does the "pragmatic
answer" gain us over the "purist answer"?

> A review of existing custom unwind annotations might be a good idea
> anyway, to check whether any of them requires another register right now.

`egrep -r '\.(setf|movs)p' arch/arm` finds nothing, for what it's worth.

--Jed

Re: [PATCH] ARM: Fix r7/r11 confusion when CONFIG_THUMB2_KERNEL=y

[Dave Martin]

On Mon, Jul 29, 2013 at 02:21:40PM -0700, Jed Davis wrote:
> On Mon, Jul 22, 2013 at 07:52:39PM +0100, Dave Martin wrote:
> > On Sun, Jul 21, 2013 at 10:37:53PM +0100, Will Deacon wrote:
> > > Ok, I think I'm with you now. I also think that a better solution would be
> > > to try and limit the r7/fp confusion to one place, perhaps behind something
> > > like:
> > > 
> > > void arm_get_current_stackframe(struct pt_regs *regs, struct stackframe *frame);
> > > 
> > > then that function can act as the bridge between pt_regs (where we leave
> > > everything as it is) and stackframe (where we assign either r7 or fp into
> > > the fp member). Then we just fix up the call sites to pass the regs they're
> > > interested in to our new function.
> > > 
> > > What do you think?
> 
> I can see that being useful if we wanted to opacify struct stackframe,
> but... all uses of stackframe that I see involve passing it to
> unwind_frame, which expands it back out into an array of registers.
> (Except with CONFIG_FRAME_POINTER, but "APCS variants that require a
> frame pointer register are obsolete.")
> 
> So... why not make pt_regs and stackframe the same, and avoid the
> translations entirely?
> 
> > Do the ARM unwind tables guarantee not to need knowledge of any
> > virtual registers for the purpose of processing the opcodes of a single
> > function's unwind table entry, except those virtual regs that we happen
> > to initialise?  Or do we just rely on luck?
> 
> Yes, for some value of "luck".  The spec documents 0x90|N, for N a core
> register number other than 13 or 15, as setting the vSP to the value of
> virtual register N.  We can get away with some omissions for kernel code
> (e.g., unwind.c doesn't handle saved floating point registers, nor adding
> constants larger than 1024 to vSP), but is this one of them?

I think in practice yes.  After all, even requiring r7 is sufficiently
rare that it wasn't flagged up until now.  GCC seems to be quite rigid
in the way it generates stackframe management code.  There's no
guarantee that won't change in the future, of course.

> [...]
> > The purist answer seems to be: we might need all the regs in struct
> > stackframe.
> > 
> > The pragmatic answer might be that we definitely need r7 for Thumb code,
> > but given the nimbleness of GCC to evolve we might get away with not
> > including extra registers for a long time yet.
> 
> The other question to ask here might be: what does the "pragmatic
> answer" gain us over the "purist answer"?

The pragmatic route is less contraversial and lower overhead: even though
it's not correct as per the ABI, GCC is the only supported compiler for
building the kernel anyway.

Tracking the whole register set might actually be useful as a debugging
aid though, even if it's not needed for reliable backtraces.  It might
be worth considering that as a separate enhancement.

> 
> > A review of existing custom unwind annotations might be a good idea
> > anyway, to check whether any of them requires another register right now.
> 
> `egrep -r '\.(setf|movs)p' arch/arm` finds nothing, for what it's worth.

Good idea.  I suspected as much, since the number of custom annotations is
fairly small.  Thanks for checking.

Cheers
---Dave

[PATCH] ARM: Fix r7/r11 confusion when CONFIG_THUMB2_KERNEL=y

[Dave Martin]

On Mon, Jul 29, 2013 at 02:21:40PM -0700, Jed Davis wrote:
> On Mon, Jul 22, 2013 at 07:52:39PM +0100, Dave Martin wrote:
> > On Sun, Jul 21, 2013 at 10:37:53PM +0100, Will Deacon wrote:
> > > Ok, I think I'm with you now. I also think that a better solution would be
> > > to try and limit the r7/fp confusion to one place, perhaps behind something
> > > like:
> > > 
> > > void arm_get_current_stackframe(struct pt_regs *regs, struct stackframe *frame);
> > > 
> > > then that function can act as the bridge between pt_regs (where we leave
> > > everything as it is) and stackframe (where we assign either r7 or fp into
> > > the fp member). Then we just fix up the call sites to pass the regs they're
> > > interested in to our new function.
> > > 
> > > What do you think?
> 
> I can see that being useful if we wanted to opacify struct stackframe,
> but... all uses of stackframe that I see involve passing it to
> unwind_frame, which expands it back out into an array of registers.
> (Except with CONFIG_FRAME_POINTER, but "APCS variants that require a
> frame pointer register are obsolete.")
> 
> So... why not make pt_regs and stackframe the same, and avoid the
> translations entirely?
> 
> > Do the ARM unwind tables guarantee not to need knowledge of any
> > virtual registers for the purpose of processing the opcodes of a single
> > function's unwind table entry, except those virtual regs that we happen
> > to initialise?  Or do we just rely on luck?
> 
> Yes, for some value of "luck".  The spec documents 0x90|N, for N a core
> register number other than 13 or 15, as setting the vSP to the value of
> virtual register N.  We can get away with some omissions for kernel code
> (e.g., unwind.c doesn't handle saved floating point registers, nor adding
> constants larger than 1024 to vSP), but is this one of them?

I think in practice yes.  After all, even requiring r7 is sufficiently
rare that it wasn't flagged up until now.  GCC seems to be quite rigid
in the way it generates stackframe management code.  There's no
guarantee that won't change in the future, of course.

> [...]
> > The purist answer seems to be: we might need all the regs in struct
> > stackframe.
> > 
> > The pragmatic answer might be that we definitely need r7 for Thumb code,
> > but given the nimbleness of GCC to evolve we might get away with not
> > including extra registers for a long time yet.
> 
> The other question to ask here might be: what does the "pragmatic
> answer" gain us over the "purist answer"?

The pragmatic route is less contraversial and lower overhead: even though
it's not correct as per the ABI, GCC is the only supported compiler for
building the kernel anyway.

Tracking the whole register set might actually be useful as a debugging
aid though, even if it's not needed for reliable backtraces.  It might
be worth considering that as a separate enhancement.

> 
> > A review of existing custom unwind annotations might be a good idea
> > anyway, to check whether any of them requires another register right now.
> 
> `egrep -r '\.(setf|movs)p' arch/arm` finds nothing, for what it's worth.

Good idea.  I suspected as much, since the number of custom annotations is
fairly small.  Thanks for checking.

Cheers
---Dave

Re: [PATCH] ARM: Fix r7/r11 confusion when CONFIG_THUMB2_KERNEL=y [OT]

[Jean-Francois Moine]

On Tue, 30 Jul 2013 10:25:18 +0100
Dave Martin <Dave.Martin@arm.com> wrote:

> The pragmatic route is less contraversial and lower overhead: even though
> it's not correct as per the ABI, GCC is the only supported compiler for
> building the kernel anyway.

BTW, kernels compiled with gcc-4.8 don't work.

Did anybody succeed with clang?

-- 
Ken ar c'hentañ	|	      ** Breizh ha Linux atav! **
Jef		|		http://moinejf.free.fr/

[PATCH] ARM: Fix r7/r11 confusion when CONFIG_THUMB2_KERNEL=y [OT]

[Jean-Francois Moine]

On Tue, 30 Jul 2013 10:25:18 +0100
Dave Martin <Dave.Martin@arm.com> wrote:

> The pragmatic route is less contraversial and lower overhead: even though
> it's not correct as per the ABI, GCC is the only supported compiler for
> building the kernel anyway.

BTW, kernels compiled with gcc-4.8 don't work.

Did anybody succeed with clang?

-- 
Ken ar c'henta?	|	      ** Breizh ha Linux atav! **
Jef		|		http://moinejf.free.fr/

Re: [PATCH] ARM: Fix r7/r11 confusion when CONFIG_THUMB2_KERNEL=y [OT]

[Dave Martin]

On Tue, Jul 30, 2013 at 11:38:53AM +0200, Jean-Francois Moine wrote:
> On Tue, 30 Jul 2013 10:25:18 +0100
> Dave Martin <Dave.Martin@arm.com> wrote:
> 
> > The pragmatic route is less contraversial and lower overhead: even though
> > it's not correct as per the ABI, GCC is the only supported compiler for
> > building the kernel anyway.
> 
> BTW, kernels compiled with gcc-4.8 don't work.

I haven't tried 4.8 yet.  Do you know what the problem is?

> Did anybody succeed with clang?

Hmm, I've no idea.  Is this possible?

Cheers
---Dave

> 
> -- 
> Ken ar c'hentañ	|	      ** Breizh ha Linux atav! **
> Jef		|		http://moinejf.free.fr/
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH] ARM: Fix r7/r11 confusion when CONFIG_THUMB2_KERNEL=y [OT]

[Dave Martin]

On Tue, Jul 30, 2013 at 11:38:53AM +0200, Jean-Francois Moine wrote:
> On Tue, 30 Jul 2013 10:25:18 +0100
> Dave Martin <Dave.Martin@arm.com> wrote:
> 
> > The pragmatic route is less contraversial and lower overhead: even though
> > it's not correct as per the ABI, GCC is the only supported compiler for
> > building the kernel anyway.
> 
> BTW, kernels compiled with gcc-4.8 don't work.

I haven't tried 4.8 yet.  Do you know what the problem is?

> Did anybody succeed with clang?

Hmm, I've no idea.  Is this possible?

Cheers
---Dave

> 
> -- 
> Ken ar c'henta?	|	      ** Breizh ha Linux atav! **
> Jef		|		http://moinejf.free.fr/
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH] ARM: Fix r7/r11 confusion when CONFIG_THUMB2_KERNEL=y [OT]

[Will Deacon]

On Tue, Jul 30, 2013 at 10:38:53AM +0100, Jean-Francois Moine wrote:
> BTW, kernels compiled with gcc-4.8 don't work.

Erm. Can you elaborate please? There was an issue where SLUB would get
miscompiled with 4.8 due to some per-cpu variable reordering across
barrier(), but I fixed that for ARM in 3.10.

... or are you referring specifically to the unwinder?

Will

[PATCH] ARM: Fix r7/r11 confusion when CONFIG_THUMB2_KERNEL=y [OT]

[Will Deacon]

On Tue, Jul 30, 2013 at 10:38:53AM +0100, Jean-Francois Moine wrote:
> BTW, kernels compiled with gcc-4.8 don't work.

Erm. Can you elaborate please? There was an issue where SLUB would get
miscompiled with 4.8 due to some per-cpu variable reordering across
barrier(), but I fixed that for ARM in 3.10.

... or are you referring specifically to the unwinder?

Will

Re: [PATCH] ARM: Fix r7/r11 confusion when CONFIG_THUMB2_KERNEL=y [OT]

[Jean-Francois Moine]

On Tue, 30 Jul 2013 10:44:57 +0100
Dave Martin <Dave.Martin@arm.com> wrote:

> On Tue, Jul 30, 2013 at 11:38:53AM +0200, Jean-Francois Moine wrote:
> > On Tue, 30 Jul 2013 10:25:18 +0100
> > Dave Martin <Dave.Martin@arm.com> wrote:
> >   
> > > The pragmatic route is less contraversial and lower overhead: even though
> > > it's not correct as per the ABI, GCC is the only supported compiler for
> > > building the kernel anyway.  
> > 
> > BTW, kernels compiled with gcc-4.8 don't work.  
> 
> I haven't tried 4.8 yet.  Do you know what the problem is?

I randomly get 'NULL pointer dereference' in ext3 (trace below).

I compared the gcc-4.6 and gcc-4.8 ARM codes of the function where the
problem occurs, and, while the gcc-4.8 code seems a bit odd, the
problem should be somewhere else, surely in the memory management.

> > Did anybody succeed with clang?  
> 
> Hmm, I've no idea.  Is this possible?

freebsd kernels are compiled with clang, and I heard about linux
patches, but I did not find them yet.

Otherwise, replacing gcc with clang in the main kernel Makefile stops
on an assembly instruction where odd register numbers could not be
used. I did not go further.

------------------ gcc-4.8.1 kernel oops ----------------
Unable to handle kernel NULL pointer dereference at virtual address 00000003
pgd = bcf74000
[00000003] *pgd=3cf16831, *pte=00000000, *ppte=00000000
Internal error: Oops: 811 [#1] PREEMPT ARM
Modules linked in: arc4 p54usb p54common crc_ccitt mac80211 cfg80211 fbcon bitblit softcursor font snd_soc_spdif_tx tda998x dove_drm drm_kms_helper snd_soc_kirkwood mv_cesa drm snd_soc_kirkwood_spdif
CPU: 0 PID: 2426 Comm: iceweasel Not tainted 3.10.0-dirty #55
task: bd92b700 ti: bcf48000 task.ti: bcf48000
PC is at do_mpage_readpage+0x754/0x888
LR is at bio_add_page+0x44/0x4c
pc : [<800e3c70>]    lr : [<800db8ac>]    psr: 600f0113
sp : bcf49c34  ip : bcf49c88  fp : bcf49c5c
r10: 00000003  r9 : 00000000  r8 : 00000043
r7 : 00000001  r6 : 800e3f54  r5 : bcf49c30  r4 : 00000003
r3 : 00020000  r2 : 00000042  r1 : 00000000  r0 : bcf49c5c
Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
Control: 10c5387d  Table: 3cf74019  DAC: 00000015
Process iceweasel (pid: 2426, stack limit = 0xbcf48240)
Stack: (0xbcf49c34 to 0xbcf4a000)
9c20:                                              00000020 bcf49d24 00200200
9c40: 00100100 bd580d94 00000000 80de4260 bcf49cf4 bcf49c60 800e3e78 800e3528
9c60: bcf49c88 bcf49c7c 801164cc 000000c1 804d660c 801164cc da0716b4 00000042
9c80: 00000000 00000000 00000020 00000000 80de4260 000000c1 00287ab6 00000000
9ca0: 00020000 80073500 bd402c80 804d6670 00100100 00000002 00200200 8039a2ac
9cc0: 804d660c 00000002 804d6ca0 80113f84 00000020 00000020 00000042 000000b4
9ce0: 00000000 00000020 bcf49d04 bcf49cf8 80113fa8 800e3db0 bcf49d6c bcf49d08
9d00: 80079ef4 80113f90 bcf00c00 00000018 bd580d94 00000020 bd580d98 bcf49d24
9d20: 00000001 80de4394 80de4254 91827364 bcf49d30 bcf49d30 bcf49d38 bcf49d38
9d40: 00000052 00000052 bcf00c00 bd580d94 bd580d94 bcf49df0 00000000 bcf6c0d0
9d60: bcf49d84 bcf49d70 8007a600 80079d10 00000008 7319d000 bcf49ddc bcf49d88
9d80: 800719f4 8007a5dc 80076670 80075448 00000001 000000c1 bcf00c48 00000002
9da0: 3c5e818f 00000000 bcf48008 bd580ce0 80013e40 bcf6c0d0 bdbc2e40 00000000
9dc0: 7319d000 00000028 00000000 bcf75cc0 bcf49e2c bcf49de0 8008b0ac 8007163c
9de0: bdb247a8 00000000 00000000 00000200 00000028 00000052 7319d000 00000000
9e00: 8007b8d0 bcf6c0d0 7319d000 7319d000 bdbc2e40 bcf6c0d0 00000028 00000000
9e20: bcf49e7c bcf49e30 8008e584 8008b048 00000052 00000028 00000000 000000b1
9e40: da538506 000000b1 804bb718 00000004 804bb708 bcf74000 00000398 7319d000
9e60: bdbc2e40 bcf6c0d0 00000028 bcf75cc0 bcf49eb4 bcf49e80 8008ed14 8008e51c
9e80: bcf75cc0 00000028 da538506 00000017 bcf49fb0 bdbc2e40 bd92b700 7319d288
9ea0: bcf48038 00000028 bcf49efc bcf49eb8 80013c38 8008ec80 0000b533 00000000
9ec0: 0000b533 00000200 00000000 bdbc2e78 00000000 00000017 80013a64 804b76f4
9ee0: 7319d288 bcf49fb0 00000ea1 00000000 bcf49fac bcf49f00 80008460 80013a70
9f00: bcf00c00 00000001 000b45c0 804bc488 bcf48000 00000000 0000001d 00000000
9f20: 00000001 73098000 bcf49f54 804bc488 bcf49f54 bcf49f40 8006a284 8006b524
9f40: 804bb900 bcf48028 00000000 00000000 0000001d 00000000 bcf49f7c bcf49f68
9f60: 80022424 8006db18 00020000 804c3c90 bcf49f9c bcf49f80 8000ec2c 800223a4
9f80: 00000621 75253ff0 200f0030 75238ed2 200f0030 ffffffff 00000000 00000ea1
9fa0: 00000000 bcf49fb0 8000e118 8000842c 7319d2ec 7319d292 7ee06c98 7319d288
9fc0: 7ee06c98 73098000 00000000 00000000 00000ea1 00000ea1 00000000 73223be0
9fe0: 752811fc 7ee06b88 7523bd75 75238ed2 200f0030 ffffffff 00000000 00000000
Backtrace: 
[<800e351c>] (do_mpage_readpage+0x0/0x888) from [<800e3e78>] (mpage_readpages+0xd4/0x130)
[<800e3da4>] (mpage_readpages+0x0/0x130) from [<80113fa8>] (ext3_readpages+0x24/0x28)
[<80113f84>] (ext3_readpages+0x0/0x28) from [<80079ef4>] (__do_page_cache_readahead+0x1f0/0x2d8)
[<80079d04>] (__do_page_cache_readahead+0x0/0x2d8) from [<8007a600>] (ra_submit+0x30/0x38)
[<8007a5d0>] (ra_submit+0x0/0x38) from [<800719f4>] (filemap_fault+0x3c4/0x4b0)
[<80071630>] (filemap_fault+0x0/0x4b0) from [<8008b0ac>] (__do_fault+0x70/0x4a8)
[<8008b03c>] (__do_fault+0x0/0x4a8) from [<8008e584>] (handle_pte_fault+0x74/0x764)
[<8008e510>] (handle_pte_fault+0x0/0x764) from [<8008ed14>] (handle_mm_fault+0xa0/0xd4)
[<8008ec74>] (handle_mm_fault+0x0/0xd4) from [<80013c38>] (do_page_fault+0x1d4/0x278)
[<80013a64>] (do_page_fault+0x0/0x278) from [<80008460>] (do_DataAbort+0x40/0xa0)
[<80008420>] (do_DataAbort+0x0/0xa0) from [<8000e118>] (__dabt_usr+0x38/0x40)
Exception stack(0xbcf49fb0 to 0xbcf49ff8)
9fa0:                                     7319d2ec 7319d292 7ee06c98 7319d288
9fc0: 7ee06c98 73098000 00000000 00000000 00000ea1 00000ea1 00000000 73223be0
9fe0: 752811fc 7ee06b88 7523bd75 75238ed2 200f0030 ffffffff
 r8:00000ea1 r7:00000000 r6:ffffffff r5:200f0030 r4:75238ed2
Code: e0854184 e51b0084 e14424d8 e51b40a0 (e1c420f0) 
---[ end trace 838796f906351fb0 ]---


-- 
Ken ar c'hentañ	|	      ** Breizh ha Linux atav! **
Jef		|		http://moinejf.free.fr/

[PATCH] ARM: Fix r7/r11 confusion when CONFIG_THUMB2_KERNEL=y [OT]

[Jean-Francois Moine]

On Tue, 30 Jul 2013 10:44:57 +0100
Dave Martin <Dave.Martin@arm.com> wrote:

> On Tue, Jul 30, 2013 at 11:38:53AM +0200, Jean-Francois Moine wrote:
> > On Tue, 30 Jul 2013 10:25:18 +0100
> > Dave Martin <Dave.Martin@arm.com> wrote:
> >   
> > > The pragmatic route is less contraversial and lower overhead: even though
> > > it's not correct as per the ABI, GCC is the only supported compiler for
> > > building the kernel anyway.  
> > 
> > BTW, kernels compiled with gcc-4.8 don't work.  
> 
> I haven't tried 4.8 yet.  Do you know what the problem is?

I randomly get 'NULL pointer dereference' in ext3 (trace below).

I compared the gcc-4.6 and gcc-4.8 ARM codes of the function where the
problem occurs, and, while the gcc-4.8 code seems a bit odd, the
problem should be somewhere else, surely in the memory management.

> > Did anybody succeed with clang?  
> 
> Hmm, I've no idea.  Is this possible?

freebsd kernels are compiled with clang, and I heard about linux
patches, but I did not find them yet.

Otherwise, replacing gcc with clang in the main kernel Makefile stops
on an assembly instruction where odd register numbers could not be
used. I did not go further.

------------------ gcc-4.8.1 kernel oops ----------------
Unable to handle kernel NULL pointer dereference at virtual address 00000003
pgd = bcf74000
[00000003] *pgd=3cf16831, *pte=00000000, *ppte=00000000
Internal error: Oops: 811 [#1] PREEMPT ARM
Modules linked in: arc4 p54usb p54common crc_ccitt mac80211 cfg80211 fbcon bitblit softcursor font snd_soc_spdif_tx tda998x dove_drm drm_kms_helper snd_soc_kirkwood mv_cesa drm snd_soc_kirkwood_spdif
CPU: 0 PID: 2426 Comm: iceweasel Not tainted 3.10.0-dirty #55
task: bd92b700 ti: bcf48000 task.ti: bcf48000
PC is at do_mpage_readpage+0x754/0x888
LR is at bio_add_page+0x44/0x4c
pc : [<800e3c70>]    lr : [<800db8ac>]    psr: 600f0113
sp : bcf49c34  ip : bcf49c88  fp : bcf49c5c
r10: 00000003  r9 : 00000000  r8 : 00000043
r7 : 00000001  r6 : 800e3f54  r5 : bcf49c30  r4 : 00000003
r3 : 00020000  r2 : 00000042  r1 : 00000000  r0 : bcf49c5c
Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
Control: 10c5387d  Table: 3cf74019  DAC: 00000015
Process iceweasel (pid: 2426, stack limit = 0xbcf48240)
Stack: (0xbcf49c34 to 0xbcf4a000)
9c20:                                              00000020 bcf49d24 00200200
9c40: 00100100 bd580d94 00000000 80de4260 bcf49cf4 bcf49c60 800e3e78 800e3528
9c60: bcf49c88 bcf49c7c 801164cc 000000c1 804d660c 801164cc da0716b4 00000042
9c80: 00000000 00000000 00000020 00000000 80de4260 000000c1 00287ab6 00000000
9ca0: 00020000 80073500 bd402c80 804d6670 00100100 00000002 00200200 8039a2ac
9cc0: 804d660c 00000002 804d6ca0 80113f84 00000020 00000020 00000042 000000b4
9ce0: 00000000 00000020 bcf49d04 bcf49cf8 80113fa8 800e3db0 bcf49d6c bcf49d08
9d00: 80079ef4 80113f90 bcf00c00 00000018 bd580d94 00000020 bd580d98 bcf49d24
9d20: 00000001 80de4394 80de4254 91827364 bcf49d30 bcf49d30 bcf49d38 bcf49d38
9d40: 00000052 00000052 bcf00c00 bd580d94 bd580d94 bcf49df0 00000000 bcf6c0d0
9d60: bcf49d84 bcf49d70 8007a600 80079d10 00000008 7319d000 bcf49ddc bcf49d88
9d80: 800719f4 8007a5dc 80076670 80075448 00000001 000000c1 bcf00c48 00000002
9da0: 3c5e818f 00000000 bcf48008 bd580ce0 80013e40 bcf6c0d0 bdbc2e40 00000000
9dc0: 7319d000 00000028 00000000 bcf75cc0 bcf49e2c bcf49de0 8008b0ac 8007163c
9de0: bdb247a8 00000000 00000000 00000200 00000028 00000052 7319d000 00000000
9e00: 8007b8d0 bcf6c0d0 7319d000 7319d000 bdbc2e40 bcf6c0d0 00000028 00000000
9e20: bcf49e7c bcf49e30 8008e584 8008b048 00000052 00000028 00000000 000000b1
9e40: da538506 000000b1 804bb718 00000004 804bb708 bcf74000 00000398 7319d000
9e60: bdbc2e40 bcf6c0d0 00000028 bcf75cc0 bcf49eb4 bcf49e80 8008ed14 8008e51c
9e80: bcf75cc0 00000028 da538506 00000017 bcf49fb0 bdbc2e40 bd92b700 7319d288
9ea0: bcf48038 00000028 bcf49efc bcf49eb8 80013c38 8008ec80 0000b533 00000000
9ec0: 0000b533 00000200 00000000 bdbc2e78 00000000 00000017 80013a64 804b76f4
9ee0: 7319d288 bcf49fb0 00000ea1 00000000 bcf49fac bcf49f00 80008460 80013a70
9f00: bcf00c00 00000001 000b45c0 804bc488 bcf48000 00000000 0000001d 00000000
9f20: 00000001 73098000 bcf49f54 804bc488 bcf49f54 bcf49f40 8006a284 8006b524
9f40: 804bb900 bcf48028 00000000 00000000 0000001d 00000000 bcf49f7c bcf49f68
9f60: 80022424 8006db18 00020000 804c3c90 bcf49f9c bcf49f80 8000ec2c 800223a4
9f80: 00000621 75253ff0 200f0030 75238ed2 200f0030 ffffffff 00000000 00000ea1
9fa0: 00000000 bcf49fb0 8000e118 8000842c 7319d2ec 7319d292 7ee06c98 7319d288
9fc0: 7ee06c98 73098000 00000000 00000000 00000ea1 00000ea1 00000000 73223be0
9fe0: 752811fc 7ee06b88 7523bd75 75238ed2 200f0030 ffffffff 00000000 00000000
Backtrace: 
[<800e351c>] (do_mpage_readpage+0x0/0x888) from [<800e3e78>] (mpage_readpages+0xd4/0x130)
[<800e3da4>] (mpage_readpages+0x0/0x130) from [<80113fa8>] (ext3_readpages+0x24/0x28)
[<80113f84>] (ext3_readpages+0x0/0x28) from [<80079ef4>] (__do_page_cache_readahead+0x1f0/0x2d8)
[<80079d04>] (__do_page_cache_readahead+0x0/0x2d8) from [<8007a600>] (ra_submit+0x30/0x38)
[<8007a5d0>] (ra_submit+0x0/0x38) from [<800719f4>] (filemap_fault+0x3c4/0x4b0)
[<80071630>] (filemap_fault+0x0/0x4b0) from [<8008b0ac>] (__do_fault+0x70/0x4a8)
[<8008b03c>] (__do_fault+0x0/0x4a8) from [<8008e584>] (handle_pte_fault+0x74/0x764)
[<8008e510>] (handle_pte_fault+0x0/0x764) from [<8008ed14>] (handle_mm_fault+0xa0/0xd4)
[<8008ec74>] (handle_mm_fault+0x0/0xd4) from [<80013c38>] (do_page_fault+0x1d4/0x278)
[<80013a64>] (do_page_fault+0x0/0x278) from [<80008460>] (do_DataAbort+0x40/0xa0)
[<80008420>] (do_DataAbort+0x0/0xa0) from [<8000e118>] (__dabt_usr+0x38/0x40)
Exception stack(0xbcf49fb0 to 0xbcf49ff8)
9fa0:                                     7319d2ec 7319d292 7ee06c98 7319d288
9fc0: 7ee06c98 73098000 00000000 00000000 00000ea1 00000ea1 00000000 73223be0
9fe0: 752811fc 7ee06b88 7523bd75 75238ed2 200f0030 ffffffff
 r8:00000ea1 r7:00000000 r6:ffffffff r5:200f0030 r4:75238ed2
Code: e0854184 e51b0084 e14424d8 e51b40a0 (e1c420f0) 
---[ end trace 838796f906351fb0 ]---


-- 
Ken ar c'henta?	|	      ** Breizh ha Linux atav! **
Jef		|		http://moinejf.free.fr/

Re: [PATCH] ARM: Fix r7/r11 confusion when CONFIG_THUMB2_KERNEL=y [OT]

[Dave Martin]

On Tue, Jul 30, 2013 at 12:09:07PM +0200, Jean-Francois Moine wrote:
> On Tue, 30 Jul 2013 10:44:57 +0100
> Dave Martin <Dave.Martin@arm.com> wrote:
> 
> > On Tue, Jul 30, 2013 at 11:38:53AM +0200, Jean-Francois Moine wrote:
> > > On Tue, 30 Jul 2013 10:25:18 +0100
> > > Dave Martin <Dave.Martin@arm.com> wrote:
> > >   
> > > > The pragmatic route is less contraversial and lower overhead: even though
> > > > it's not correct as per the ABI, GCC is the only supported compiler for
> > > > building the kernel anyway.  
> > > 
> > > BTW, kernels compiled with gcc-4.8 don't work.  
> > 
> > I haven't tried 4.8 yet.  Do you know what the problem is?
> 
> I randomly get 'NULL pointer dereference' in ext3 (trace below).
> 
> I compared the gcc-4.6 and gcc-4.8 ARM codes of the function where the
> problem occurs, and, while the gcc-4.8 code seems a bit odd, the
> problem should be somewhere else, surely in the memory management.
> 
> > > Did anybody succeed with clang?  
> > 
> > Hmm, I've no idea.  Is this possible?
> 
> freebsd kernels are compiled with clang, and I heard about linux
> patches, but I did not find them yet.

Given the tricks the kernel has to pull with undocumented features of
inline asm and the like, the prospect of dropping in a different
compiler is more than a little scary...

> Otherwise, replacing gcc with clang in the main kernel Makefile stops
> on an assembly instruction where odd register numbers could not be
> used. I did not go further.

Hmm.  Dunno what this is... but I guess it's nothing to do with
backtraces.

Cheers
---Dave

> 
> ------------------ gcc-4.8.1 kernel oops ----------------
> Unable to handle kernel NULL pointer dereference at virtual address 00000003
> pgd = bcf74000
> [00000003] *pgd=3cf16831, *pte=00000000, *ppte=00000000
> Internal error: Oops: 811 [#1] PREEMPT ARM
> Modules linked in: arc4 p54usb p54common crc_ccitt mac80211 cfg80211 fbcon bitblit softcursor font snd_soc_spdif_tx tda998x dove_drm drm_kms_helper snd_soc_kirkwood mv_cesa drm snd_soc_kirkwood_spdif
> CPU: 0 PID: 2426 Comm: iceweasel Not tainted 3.10.0-dirty #55
> task: bd92b700 ti: bcf48000 task.ti: bcf48000
> PC is at do_mpage_readpage+0x754/0x888
> LR is at bio_add_page+0x44/0x4c
> pc : [<800e3c70>]    lr : [<800db8ac>]    psr: 600f0113
> sp : bcf49c34  ip : bcf49c88  fp : bcf49c5c
> r10: 00000003  r9 : 00000000  r8 : 00000043
> r7 : 00000001  r6 : 800e3f54  r5 : bcf49c30  r4 : 00000003
> r3 : 00020000  r2 : 00000042  r1 : 00000000  r0 : bcf49c5c
> Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
> Control: 10c5387d  Table: 3cf74019  DAC: 00000015
> Process iceweasel (pid: 2426, stack limit = 0xbcf48240)
> Stack: (0xbcf49c34 to 0xbcf4a000)
> 9c20:                                              00000020 bcf49d24 00200200
> 9c40: 00100100 bd580d94 00000000 80de4260 bcf49cf4 bcf49c60 800e3e78 800e3528
> 9c60: bcf49c88 bcf49c7c 801164cc 000000c1 804d660c 801164cc da0716b4 00000042
> 9c80: 00000000 00000000 00000020 00000000 80de4260 000000c1 00287ab6 00000000
> 9ca0: 00020000 80073500 bd402c80 804d6670 00100100 00000002 00200200 8039a2ac
> 9cc0: 804d660c 00000002 804d6ca0 80113f84 00000020 00000020 00000042 000000b4
> 9ce0: 00000000 00000020 bcf49d04 bcf49cf8 80113fa8 800e3db0 bcf49d6c bcf49d08
> 9d00: 80079ef4 80113f90 bcf00c00 00000018 bd580d94 00000020 bd580d98 bcf49d24
> 9d20: 00000001 80de4394 80de4254 91827364 bcf49d30 bcf49d30 bcf49d38 bcf49d38
> 9d40: 00000052 00000052 bcf00c00 bd580d94 bd580d94 bcf49df0 00000000 bcf6c0d0
> 9d60: bcf49d84 bcf49d70 8007a600 80079d10 00000008 7319d000 bcf49ddc bcf49d88
> 9d80: 800719f4 8007a5dc 80076670 80075448 00000001 000000c1 bcf00c48 00000002
> 9da0: 3c5e818f 00000000 bcf48008 bd580ce0 80013e40 bcf6c0d0 bdbc2e40 00000000
> 9dc0: 7319d000 00000028 00000000 bcf75cc0 bcf49e2c bcf49de0 8008b0ac 8007163c
> 9de0: bdb247a8 00000000 00000000 00000200 00000028 00000052 7319d000 00000000
> 9e00: 8007b8d0 bcf6c0d0 7319d000 7319d000 bdbc2e40 bcf6c0d0 00000028 00000000
> 9e20: bcf49e7c bcf49e30 8008e584 8008b048 00000052 00000028 00000000 000000b1
> 9e40: da538506 000000b1 804bb718 00000004 804bb708 bcf74000 00000398 7319d000
> 9e60: bdbc2e40 bcf6c0d0 00000028 bcf75cc0 bcf49eb4 bcf49e80 8008ed14 8008e51c
> 9e80: bcf75cc0 00000028 da538506 00000017 bcf49fb0 bdbc2e40 bd92b700 7319d288
> 9ea0: bcf48038 00000028 bcf49efc bcf49eb8 80013c38 8008ec80 0000b533 00000000
> 9ec0: 0000b533 00000200 00000000 bdbc2e78 00000000 00000017 80013a64 804b76f4
> 9ee0: 7319d288 bcf49fb0 00000ea1 00000000 bcf49fac bcf49f00 80008460 80013a70
> 9f00: bcf00c00 00000001 000b45c0 804bc488 bcf48000 00000000 0000001d 00000000
> 9f20: 00000001 73098000 bcf49f54 804bc488 bcf49f54 bcf49f40 8006a284 8006b524
> 9f40: 804bb900 bcf48028 00000000 00000000 0000001d 00000000 bcf49f7c bcf49f68
> 9f60: 80022424 8006db18 00020000 804c3c90 bcf49f9c bcf49f80 8000ec2c 800223a4
> 9f80: 00000621 75253ff0 200f0030 75238ed2 200f0030 ffffffff 00000000 00000ea1
> 9fa0: 00000000 bcf49fb0 8000e118 8000842c 7319d2ec 7319d292 7ee06c98 7319d288
> 9fc0: 7ee06c98 73098000 00000000 00000000 00000ea1 00000ea1 00000000 73223be0
> 9fe0: 752811fc 7ee06b88 7523bd75 75238ed2 200f0030 ffffffff 00000000 00000000
> Backtrace: 
> [<800e351c>] (do_mpage_readpage+0x0/0x888) from [<800e3e78>] (mpage_readpages+0xd4/0x130)
> [<800e3da4>] (mpage_readpages+0x0/0x130) from [<80113fa8>] (ext3_readpages+0x24/0x28)
> [<80113f84>] (ext3_readpages+0x0/0x28) from [<80079ef4>] (__do_page_cache_readahead+0x1f0/0x2d8)
> [<80079d04>] (__do_page_cache_readahead+0x0/0x2d8) from [<8007a600>] (ra_submit+0x30/0x38)
> [<8007a5d0>] (ra_submit+0x0/0x38) from [<800719f4>] (filemap_fault+0x3c4/0x4b0)
> [<80071630>] (filemap_fault+0x0/0x4b0) from [<8008b0ac>] (__do_fault+0x70/0x4a8)
> [<8008b03c>] (__do_fault+0x0/0x4a8) from [<8008e584>] (handle_pte_fault+0x74/0x764)
> [<8008e510>] (handle_pte_fault+0x0/0x764) from [<8008ed14>] (handle_mm_fault+0xa0/0xd4)
> [<8008ec74>] (handle_mm_fault+0x0/0xd4) from [<80013c38>] (do_page_fault+0x1d4/0x278)
> [<80013a64>] (do_page_fault+0x0/0x278) from [<80008460>] (do_DataAbort+0x40/0xa0)
> [<80008420>] (do_DataAbort+0x0/0xa0) from [<8000e118>] (__dabt_usr+0x38/0x40)
> Exception stack(0xbcf49fb0 to 0xbcf49ff8)
> 9fa0:                                     7319d2ec 7319d292 7ee06c98 7319d288
> 9fc0: 7ee06c98 73098000 00000000 00000000 00000ea1 00000ea1 00000000 73223be0
> 9fe0: 752811fc 7ee06b88 7523bd75 75238ed2 200f0030 ffffffff
>  r8:00000ea1 r7:00000000 r6:ffffffff r5:200f0030 r4:75238ed2
> Code: e0854184 e51b0084 e14424d8 e51b40a0 (e1c420f0) 
> ---[ end trace 838796f906351fb0 ]---
> 
> 
> -- 
> Ken ar c'hentañ	|	      ** Breizh ha Linux atav! **
> Jef		|		http://moinejf.free.fr/
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH] ARM: Fix r7/r11 confusion when CONFIG_THUMB2_KERNEL=y [OT]

[Dave Martin]

On Tue, Jul 30, 2013 at 12:09:07PM +0200, Jean-Francois Moine wrote:
> On Tue, 30 Jul 2013 10:44:57 +0100
> Dave Martin <Dave.Martin@arm.com> wrote:
> 
> > On Tue, Jul 30, 2013 at 11:38:53AM +0200, Jean-Francois Moine wrote:
> > > On Tue, 30 Jul 2013 10:25:18 +0100
> > > Dave Martin <Dave.Martin@arm.com> wrote:
> > >   
> > > > The pragmatic route is less contraversial and lower overhead: even though
> > > > it's not correct as per the ABI, GCC is the only supported compiler for
> > > > building the kernel anyway.  
> > > 
> > > BTW, kernels compiled with gcc-4.8 don't work.  
> > 
> > I haven't tried 4.8 yet.  Do you know what the problem is?
> 
> I randomly get 'NULL pointer dereference' in ext3 (trace below).
> 
> I compared the gcc-4.6 and gcc-4.8 ARM codes of the function where the
> problem occurs, and, while the gcc-4.8 code seems a bit odd, the
> problem should be somewhere else, surely in the memory management.
> 
> > > Did anybody succeed with clang?  
> > 
> > Hmm, I've no idea.  Is this possible?
> 
> freebsd kernels are compiled with clang, and I heard about linux
> patches, but I did not find them yet.

Given the tricks the kernel has to pull with undocumented features of
inline asm and the like, the prospect of dropping in a different
compiler is more than a little scary...

> Otherwise, replacing gcc with clang in the main kernel Makefile stops
> on an assembly instruction where odd register numbers could not be
> used. I did not go further.

Hmm.  Dunno what this is... but I guess it's nothing to do with
backtraces.

Cheers
---Dave

> 
> ------------------ gcc-4.8.1 kernel oops ----------------
> Unable to handle kernel NULL pointer dereference at virtual address 00000003
> pgd = bcf74000
> [00000003] *pgd=3cf16831, *pte=00000000, *ppte=00000000
> Internal error: Oops: 811 [#1] PREEMPT ARM
> Modules linked in: arc4 p54usb p54common crc_ccitt mac80211 cfg80211 fbcon bitblit softcursor font snd_soc_spdif_tx tda998x dove_drm drm_kms_helper snd_soc_kirkwood mv_cesa drm snd_soc_kirkwood_spdif
> CPU: 0 PID: 2426 Comm: iceweasel Not tainted 3.10.0-dirty #55
> task: bd92b700 ti: bcf48000 task.ti: bcf48000
> PC is at do_mpage_readpage+0x754/0x888
> LR is at bio_add_page+0x44/0x4c
> pc : [<800e3c70>]    lr : [<800db8ac>]    psr: 600f0113
> sp : bcf49c34  ip : bcf49c88  fp : bcf49c5c
> r10: 00000003  r9 : 00000000  r8 : 00000043
> r7 : 00000001  r6 : 800e3f54  r5 : bcf49c30  r4 : 00000003
> r3 : 00020000  r2 : 00000042  r1 : 00000000  r0 : bcf49c5c
> Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
> Control: 10c5387d  Table: 3cf74019  DAC: 00000015
> Process iceweasel (pid: 2426, stack limit = 0xbcf48240)
> Stack: (0xbcf49c34 to 0xbcf4a000)
> 9c20:                                              00000020 bcf49d24 00200200
> 9c40: 00100100 bd580d94 00000000 80de4260 bcf49cf4 bcf49c60 800e3e78 800e3528
> 9c60: bcf49c88 bcf49c7c 801164cc 000000c1 804d660c 801164cc da0716b4 00000042
> 9c80: 00000000 00000000 00000020 00000000 80de4260 000000c1 00287ab6 00000000
> 9ca0: 00020000 80073500 bd402c80 804d6670 00100100 00000002 00200200 8039a2ac
> 9cc0: 804d660c 00000002 804d6ca0 80113f84 00000020 00000020 00000042 000000b4
> 9ce0: 00000000 00000020 bcf49d04 bcf49cf8 80113fa8 800e3db0 bcf49d6c bcf49d08
> 9d00: 80079ef4 80113f90 bcf00c00 00000018 bd580d94 00000020 bd580d98 bcf49d24
> 9d20: 00000001 80de4394 80de4254 91827364 bcf49d30 bcf49d30 bcf49d38 bcf49d38
> 9d40: 00000052 00000052 bcf00c00 bd580d94 bd580d94 bcf49df0 00000000 bcf6c0d0
> 9d60: bcf49d84 bcf49d70 8007a600 80079d10 00000008 7319d000 bcf49ddc bcf49d88
> 9d80: 800719f4 8007a5dc 80076670 80075448 00000001 000000c1 bcf00c48 00000002
> 9da0: 3c5e818f 00000000 bcf48008 bd580ce0 80013e40 bcf6c0d0 bdbc2e40 00000000
> 9dc0: 7319d000 00000028 00000000 bcf75cc0 bcf49e2c bcf49de0 8008b0ac 8007163c
> 9de0: bdb247a8 00000000 00000000 00000200 00000028 00000052 7319d000 00000000
> 9e00: 8007b8d0 bcf6c0d0 7319d000 7319d000 bdbc2e40 bcf6c0d0 00000028 00000000
> 9e20: bcf49e7c bcf49e30 8008e584 8008b048 00000052 00000028 00000000 000000b1
> 9e40: da538506 000000b1 804bb718 00000004 804bb708 bcf74000 00000398 7319d000
> 9e60: bdbc2e40 bcf6c0d0 00000028 bcf75cc0 bcf49eb4 bcf49e80 8008ed14 8008e51c
> 9e80: bcf75cc0 00000028 da538506 00000017 bcf49fb0 bdbc2e40 bd92b700 7319d288
> 9ea0: bcf48038 00000028 bcf49efc bcf49eb8 80013c38 8008ec80 0000b533 00000000
> 9ec0: 0000b533 00000200 00000000 bdbc2e78 00000000 00000017 80013a64 804b76f4
> 9ee0: 7319d288 bcf49fb0 00000ea1 00000000 bcf49fac bcf49f00 80008460 80013a70
> 9f00: bcf00c00 00000001 000b45c0 804bc488 bcf48000 00000000 0000001d 00000000
> 9f20: 00000001 73098000 bcf49f54 804bc488 bcf49f54 bcf49f40 8006a284 8006b524
> 9f40: 804bb900 bcf48028 00000000 00000000 0000001d 00000000 bcf49f7c bcf49f68
> 9f60: 80022424 8006db18 00020000 804c3c90 bcf49f9c bcf49f80 8000ec2c 800223a4
> 9f80: 00000621 75253ff0 200f0030 75238ed2 200f0030 ffffffff 00000000 00000ea1
> 9fa0: 00000000 bcf49fb0 8000e118 8000842c 7319d2ec 7319d292 7ee06c98 7319d288
> 9fc0: 7ee06c98 73098000 00000000 00000000 00000ea1 00000ea1 00000000 73223be0
> 9fe0: 752811fc 7ee06b88 7523bd75 75238ed2 200f0030 ffffffff 00000000 00000000
> Backtrace: 
> [<800e351c>] (do_mpage_readpage+0x0/0x888) from [<800e3e78>] (mpage_readpages+0xd4/0x130)
> [<800e3da4>] (mpage_readpages+0x0/0x130) from [<80113fa8>] (ext3_readpages+0x24/0x28)
> [<80113f84>] (ext3_readpages+0x0/0x28) from [<80079ef4>] (__do_page_cache_readahead+0x1f0/0x2d8)
> [<80079d04>] (__do_page_cache_readahead+0x0/0x2d8) from [<8007a600>] (ra_submit+0x30/0x38)
> [<8007a5d0>] (ra_submit+0x0/0x38) from [<800719f4>] (filemap_fault+0x3c4/0x4b0)
> [<80071630>] (filemap_fault+0x0/0x4b0) from [<8008b0ac>] (__do_fault+0x70/0x4a8)
> [<8008b03c>] (__do_fault+0x0/0x4a8) from [<8008e584>] (handle_pte_fault+0x74/0x764)
> [<8008e510>] (handle_pte_fault+0x0/0x764) from [<8008ed14>] (handle_mm_fault+0xa0/0xd4)
> [<8008ec74>] (handle_mm_fault+0x0/0xd4) from [<80013c38>] (do_page_fault+0x1d4/0x278)
> [<80013a64>] (do_page_fault+0x0/0x278) from [<80008460>] (do_DataAbort+0x40/0xa0)
> [<80008420>] (do_DataAbort+0x0/0xa0) from [<8000e118>] (__dabt_usr+0x38/0x40)
> Exception stack(0xbcf49fb0 to 0xbcf49ff8)
> 9fa0:                                     7319d2ec 7319d292 7ee06c98 7319d288
> 9fc0: 7ee06c98 73098000 00000000 00000000 00000ea1 00000ea1 00000000 73223be0
> 9fe0: 752811fc 7ee06b88 7523bd75 75238ed2 200f0030 ffffffff
>  r8:00000ea1 r7:00000000 r6:ffffffff r5:200f0030 r4:75238ed2
> Code: e0854184 e51b0084 e14424d8 e51b40a0 (e1c420f0) 
> ---[ end trace 838796f906351fb0 ]---
> 
> 
> -- 
> Ken ar c'henta?	|	      ** Breizh ha Linux atav! **
> Jef		|		http://moinejf.free.fr/
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH] ARM: Fix r7/r11 confusion when CONFIG_THUMB2_KERNEL=y [OT]

[Christopher Covington]

On 07/30/2013 06:09 AM, Jean-Francois Moine wrote:
> On Tue, 30 Jul 2013 10:44:57 +0100
> Dave Martin <Dave.Martin@arm.com> wrote:
>> On Tue, Jul 30, 2013 at 11:38:53AM +0200, Jean-Francois Moine wrote:
>>> On Tue, 30 Jul 2013 10:25:18 +0100
>>> Dave Martin <Dave.Martin@arm.com> wrote:
>>>> The pragmatic route is less contraversial and lower overhead: even though
>>>> it's not correct as per the ABI, GCC is the only supported compiler for
>>>> building the kernel anyway.  

[...]

>>> Did anybody succeed with clang?  
>>
>> Hmm, I've no idea.  Is this possible?
> 
> freebsd kernels are compiled with clang, and I heard about linux
> patches, but I did not find them yet.

There's a project home page here:

http://llvm.linuxfoundation.org/index.php/Main_Page

Christopher

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by the Linux Foundation.

[PATCH] ARM: Fix r7/r11 confusion when CONFIG_THUMB2_KERNEL=y [OT]

[Christopher Covington]

On 07/30/2013 06:09 AM, Jean-Francois Moine wrote:
> On Tue, 30 Jul 2013 10:44:57 +0100
> Dave Martin <Dave.Martin@arm.com> wrote:
>> On Tue, Jul 30, 2013 at 11:38:53AM +0200, Jean-Francois Moine wrote:
>>> On Tue, 30 Jul 2013 10:25:18 +0100
>>> Dave Martin <Dave.Martin@arm.com> wrote:
>>>> The pragmatic route is less contraversial and lower overhead: even though
>>>> it's not correct as per the ABI, GCC is the only supported compiler for
>>>> building the kernel anyway.  

[...]

>>> Did anybody succeed with clang?  
>>
>> Hmm, I've no idea.  Is this possible?
> 
> freebsd kernels are compiled with clang, and I heard about linux
> patches, but I did not find them yet.

There's a project home page here:

http://llvm.linuxfoundation.org/index.php/Main_Page

Christopher

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by the Linux Foundation.

Re: [PATCH] ARM: Fix r7/r11 confusion when CONFIG_THUMB2_KERNEL=y [OT]

[Jean-Francois Moine]

On Tue, 30 Jul 2013 10:49:04 +0100
Will Deacon <will.deacon@arm.com> wrote:

> On Tue, Jul 30, 2013 at 10:38:53AM +0100, Jean-Francois Moine wrote:
> > BTW, kernels compiled with gcc-4.8 don't work.  
> 
> Erm. Can you elaborate please? There was an issue where SLUB would get
> miscompiled with 4.8 due to some per-cpu variable reordering across
> barrier(), but I fixed that for ARM in 3.10.

I compiled the 3.11.0-rc3 with gcc-4.8.1 and I still get oops in ext3
(no problem when compiled with gcc-4.6). Here is the dmesg.

Booting Linux on physical CPU 0x0
Linux version 3.11.0-rc3-00004-g36f571e-dirty (jef@armhf) (gcc version 4.8.1 (Debian 4.8.1-8) ) #1 PREEMPT Wed Jul 31 09:22:30 CEST 2013
CPU: ARMv7 Processor [560f5815] revision 5 (ARMv7), cr=10c53c7d
CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
Machine: Marvell Dove (Flattened Device Tree), model: SolidRun CuBox
cma: CMA: reserved 32 MiB at 3e000000
Memory policy: ECC disabled, Data cache writeback
On node 0 totalpages: 262144
free_area_init_node: node 0, pgdat 804ebd2c, node_mem_map 8075b000
  Normal zone: 2048 pages used for memmap
  Normal zone: 0 pages reserved
  Normal zone: 262144 pages, LIFO batch:31
CPU: All CPU(s) started in SVC mode.
pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
pcpu-alloc: [0] 0 
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 260096
Kernel command line: console=ttyS0,115200n8 console=tty1,115200 root=/dev/sda7 rootwait video=HDMI-A-1:1920x1080-32@60
PID hash table entries: 4096 (order: 2, 16384 bytes)
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 1001516K/1048576K available (3715K kernel code, 177K rwdata, 980K rodata, 135K init, 129K bss, 47060K reserved)
Virtual kernel memory layout:
    vector  : 0xffff0000 - 0xffff1000   (   4 kB)
    fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
    vmalloc : 0xc0800000 - 0xff000000   (1000 MB)
    lowmem  : 0x80000000 - 0xc0000000   (1024 MB)
    modules : 0x7f000000 - 0x80000000   (  16 MB)
      .text : 0x80008000 - 0x8049df34   (4696 kB)
      .init : 0x8049e000 - 0x804bfe68   ( 136 kB)
      .data : 0x804c0000 - 0x804ec5c0   ( 178 kB)
       .bss : 0x804ec5c0 - 0x8050cad0   ( 130 kB)
Preemptible hierarchical RCU implementation.
	Dump stacks of tasks blocking RCU-preempt GP.
NR_IRQS:135
sched_clock: 32 bits at 166MHz, resolution 5ns, wraps every 25769ms
Console: colour dummy device 80x30
console [tty1] enabled
Calibrating delay loop... 789.70 BogoMIPS (lpj=3948544)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
Setting up static identity map for 0x803a6620 - 0x803a6654
devtmpfs: initialized
pinctrl core: initialized pinctrl subsystem
regulator-dummy: no parameters
NET: Registered protocol family 16
DMA: preallocated 256 KiB pool for atomic coherent allocations
Dove 88AP510 SoC
Tauros2: Disabling L2 prefetch.
Tauros2: Disabling line fill burt8.
Tauros2: Enabling L2 cache.
Tauros2: L2 cache support initialised in ARMv7 mode.
bio: create slab <bio-0> at 0
USB Power: Failed to request enable GPIO1: -517
reg-fixed-voltage 1.regulator: Failed to register regulator: -517
platform 1.regulator: Driver reg-fixed-voltage requests probe deferral
SCSI subsystem initialized
libata version 3.00 loaded.
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
Linux video capture interface: v2.00
Advanced Linux Sound Architecture Driver Initialized.
Switched to clocksource orion_clocksource
NET: Registered protocol family 2
TCP established hash table entries: 8192 (order: 4, 65536 bytes)
TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
TCP: reno registered
UDP hash table entries: 512 (order: 1, 8192 bytes)
UDP-Lite hash table entries: 512 (order: 1, 8192 bytes)
NET: Registered protocol family 1
audit: initializing netlink socket (disabled)
type=2000 audit(0.070:1): initialized
msgmni has been set to 2020
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
dove-pinctrl f10d0200.pinctrl: registered pinctrl driver
mv_xor f1060800.dma-engine: Marvell shared XOR driver
mv_xor f1060800.dma-engine: Marvell XOR: ( xor cpy )
mv_xor f1060800.dma-engine: Marvell XOR: ( xor cpy )
mv_xor f1060900.dma-engine: Marvell shared XOR driver
mv_xor f1060900.dma-engine: Marvell XOR: ( xor cpy )
mv_xor f1060900.dma-engine: Marvell XOR: ( xor cpy )
Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled
f1012000.serial: ttyS0 at MMIO 0xf1012000 (irq = 7) is a 16550A
console [ttyS0] enabled
brd: module loaded
sata_mv f10a0000.sata: version 1.28
sata_mv f10a0000.sata: slots 32 ports 1
scsi0 : sata_mv
ata1: SATA max UDMA/133 irq 62
libphy: orion_mdio_bus: probed
mv643xx_eth: MV-643xx 10/100/1000 ethernet driver version 1.4
libphy: PHY orion-mdio-mii:08 not found
libphy: PHY orion-mdio-mii:09 not found
libphy: PHY orion-mdio-mii:0a not found
libphy: PHY orion-mdio-mii:0b not found
libphy: PHY orion-mdio-mii:0c not found
libphy: PHY orion-mdio-mii:0d not found
libphy: PHY orion-mdio-mii:0e not found
libphy: PHY orion-mdio-mii:0f not found
libphy: PHY orion-mdio-mii:10 not found
libphy: PHY orion-mdio-mii:11 not found
libphy: PHY orion-mdio-mii:12 not found
libphy: PHY orion-mdio-mii:13 not found
libphy: PHY orion-mdio-mii:14 not found
libphy: PHY orion-mdio-mii:15 not found
libphy: PHY orion-mdio-mii:16 not found
libphy: PHY orion-mdio-mii:17 not found
libphy: PHY orion-mdio-mii:18 not found
libphy: PHY orion-mdio-mii:19 not found
libphy: PHY orion-mdio-mii:1a not found
libphy: PHY orion-mdio-mii:1b not found
libphy: PHY orion-mdio-mii:1c not found
libphy: PHY orion-mdio-mii:1d not found
libphy: PHY orion-mdio-mii:1e not found
libphy: PHY orion-mdio-mii:1f not found
libphy: PHY orion-mdio-mii:00 not found
mv643xx_eth_port mv643xx_eth_port.0 eth0: port 0 with MAC address 00:50:43:b6:3b:10
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ehci-orion: EHCI orion driver
orion-ehci f1050000.usb-host: EHCI Host Controller
orion-ehci f1050000.usb-host: new USB bus registered, assigned bus number 1
orion-ehci f1050000.usb-host: irq 24, io mem 0xf1050000
orion-ehci f1050000.usb-host: USB 2.0 started, EHCI 1.00
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
orion-ehci f1051000.usb-host: EHCI Host Controller
orion-ehci f1051000.usb-host: new USB bus registered, assigned bus number 2
orion-ehci f1051000.usb-host: irq 25, io mem 0xf1051000
orion-ehci f1051000.usb-host: USB 2.0 started, EHCI 1.00
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 1 port detected
usbcore: registered new interface driver usb-storage
mousedev: PS/2 mouse device common for all mice
rtc-mv f10d8500.rtc: rtc core: registered f10d8500.rtc as rtc0
sdhci: Secure Digital Host Controller Interface driver
sdhci: Copyright(c) Pierre Ossman
sdhci-pltfm: SDHCI platform and OF driver helper
mmc0: no vqmmc regulator found
mmc0: no vmmc regulator found
mmc0: SDHCI controller on f1092000.sdio [f1092000.sdio] using DMA
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
TCP: cubic registered
NET: Registered protocol family 10
NET: Registered protocol family 17
VFP support v0.3: implementor 56 architecture 2 part 20 variant 9 rev 5
ThumbEE CPU extension supported.
PJ4 iWMMXt coprocessor enabled.
USB Power: 5000 mV 
rtc-mv f10d8500.rtc: setting system clock to 2013-07-31 08:15:22 UTC (1375258522)
ALSA device list:
  No soundcards found.
ata1: SATA link down (SStatus 0 SControl F300)
mmc0: new high speed SDHC card at address e624
mmcblk0: mmc0:e624 SU16G 14.8 GiB 
 mmcblk0: p1 p2 p3
Waiting for root device /dev/sda7...
usb 1-1: new high-speed USB device number 2 using orion-ehci
usb-storage 1-1:1.0: USB Mass Storage device detected
scsi1 : usb-storage 1-1:1.0
usb 2-1: new high-speed USB device number 2 using orion-ehci
hub 2-1:1.0: USB hub found
hub 2-1:1.0: 4 ports detected
usb 2-1.4: new high-speed USB device number 3 using orion-ehci
hub 2-1.4:1.0: USB hub found
hub 2-1.4:1.0: 4 ports detected
usb 2-1.4.2: new high-speed USB device number 4 using orion-ehci
scsi 1:0:0:0: Direct-Access     WDC WD25 00JB-55REA0      20.0 PQ: 0 ANSI: 0
sd 1:0:0:0: [sda] 488397168 512-byte logical blocks: (250 GB/232 GiB)
sd 1:0:0:0: [sda] Write Protect is off
sd 1:0:0:0: [sda] Mode Sense: 03 00 00 00
sd 1:0:0:0: [sda] No Caching mode page present
sd 1:0:0:0: [sda] Assuming drive cache: write through
sd 1:0:0:0: [sda] No Caching mode page present
sd 1:0:0:0: [sda] Assuming drive cache: write through
 sda: sda1 sda2 sda3 sda4 < sda5 sda6 sda7 >
sd 1:0:0:0: [sda] No Caching mode page present
sd 1:0:0:0: [sda] Assuming drive cache: write through
sd 1:0:0:0: [sda] Attached SCSI disk
EXT3-fs (sda7): mounted filesystem with ordered data mode
kjournald starting.  Commit interval 5 seconds
usb 2-1.4.3: new low-speed USB device number 5 using orion-ehci
VFS: Mounted root (ext3 filesystem) readonly on device 8:7.
devtmpfs: mounted
Freeing unused kernel memory: 132K (8049e000 - 804bf000)
input: Generic USB K/B as /devices/soc.0/f1051000.usb-host/usb2/2-1/2-1.4/2-1.4.3/2-1.4.3:1.0/input/input0
hid-generic 0003:13BA:0017.0001: input: USB HID v1.10 Keyboard [Generic USB K/B] on usb-f1051000.usb-host-1.4.3/input0
input: Generic USB K/B as /devices/soc.0/f1051000.usb-host/usb2/2-1/2-1.4/2-1.4.3/2-1.4.3:1.1/input/input1
hid-generic 0003:13BA:0017.0002: input: USB HID v1.10 Mouse [Generic USB K/B] on usb-f1051000.usb-host-1.4.3/input1
udevd[583]: starting version 175
[drm] Initialized drm 1.1.0 20060810
cfg80211: Calling CRDA to update world regulatory domain
simple-dt-audio sound.5:  dit-hifi <-> f10b4000.audio-controller mapping ok
tda998x 0-0070: found TDA19988
[drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[drm] No driver support for vblank timestamp query.
usb 2-1.4.2: reset high-speed USB device number 4 using orion-ehci
usb 2-1.4.2: Loading firmware file isl3887usb
usbcore: registered new interface driver p54usb
ieee80211 phy0: p54 detected a LM87 firmware
p54: rx_mtu reduced from 3240 to 2384
ieee80211 phy0: FW rev 2.13.25.0 - Softmac protocol 5.9
ieee80211 phy0: cryptographic accelerator WEP:YES, TKIP:YES, CCMP:YES
Console: switching to colour frame buffer device 240x67
dove-drm video.6: fb0:  frame buffer device
dove-drm video.6: registered panic notifier
[drm] Initialized dove-drm 1.0.0 20130516 on minor 0
ieee80211 phy0: hwaddr 00:12:bf:1e:9c:e4, MAC:isl3887 RF:Frisbee
ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
usb 2-1.4.2: is registered as 'phy0'
Unable to handle kernel NULL pointer dereference at virtual address 00000003
pgd = bd374000
[00000003] *pgd=3d3af831, *pte=00000000, *ppte=00000000
Internal error: Oops: 811 [#1] PREEMPT ARM
Modules linked in: arc4 p54usb p54common crc_ccitt fbcon bitblit mac80211 softcursor font cfg80211 dove_drm tda998x drm_kms_helper drm clk_si5351 snd_soc_simple_dt_card snd_soc_spdif_tx mv_cesa snd_soc_kirkwood
CPU: 0 PID: 731 Comm: usb-db Not tainted 3.11.0-rc3-00004-g36f571e-dirty #1
task: bda0dc00 ti: bd2fa000 task.ti: bd2fa000
PC is at do_mpage_readpage+0x754/0x888
LR is at bio_add_page+0x44/0x4c
pc : [<800e89c0>]    lr : [<800e05e4>]    psr: 600e0013
sp : bd2fbc74  ip : bd2fbcc8  fp : bd2fbc9c
r10: 00000003  r9 : 00000000  r8 : 00000004
r7 : 00000001  r6 : 800e8ca4  r5 : bd2fbc70  r4 : 00000003
r3 : 00001000  r2 : 00000003  r1 : 00000000  r0 : bd2fbc9c
Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
Control: 10c5387d  Table: 3d374019  DAC: 00000015
Process usb-db (pid: 731, stack limit = 0xbd2fa240)
Stack: (0xbd2fbc74 to 0xbd2fc000)
bc60:                                              00000001 bd2fbd64 00200200
bc80: 00100100 bd53cd54 bd9f1340 80eed380 bd2fbd34 bd2fbca0 800e8bc8 800e8278
bca0: bd2fbcc8 bd2fbcbc 8011c554 000000c1 804ebd2c 8011c554 00000002 00000003
bcc0: 0028de87 00000000 00000000 bd2fbcd8 80eed380 803a2f54 0028df40 00000000
bce0: 00001000 00000000 bd402ac0 8003b810 bd2fbcf0 bd2fbcf0 bd53ccb4 bd2fbd7c
bd00: bd53ccbc 00000002 bd2fbd24 8011a00c 00000004 00000004 00000000 0000007a
bd20: 00000000 00000004 bd2fbd44 bd2fbd38 8011a030 800e8b00 bd2fbdac bd2fbd48
bd40: 8007dd28 8011a018 bda54780 00000001 bd53cd54 00000004 bd53cd58 bd2fbd64
bd60: 800c23bc bd2fbd64 bd2fbd64 91827364 bd8d5de8 bd8d5de8 bd2fbd78 bd2fbd78
bd80: 800add50 bd53cd54 bda54780 bda547c8 00000000 00000020 00000003 bd53cd54
bda0: bd2fbdec bd2fbdb0 8007e0e0 8007db44 00000003 bd11e470 bd95462c bdbe1540
bdc0: bd2fbddc bd53cd54 00000000 00000000 bd53cc98 00000001 00000000 bda54780
bde0: bd2fbe0c bd2fbdf0 8007e3b8 8007dfc4 00000000 00000001 00000000 bd53cd54
be00: bd2fbeac bd2fbe10 8007471c 8007e378 00000001 bd954b78 bd9545f8 bd9545f8
be20: 76f24000 76f25000 00000001 00080001 bd2fbeb8 bd2fbec0 ffffffff 00000000
be40: 00000000 bdbe1540 00000001 bd954608 00000001 00000fff bd2fa000 bda547c8
be60: 00000000 00000001 76f25000 00000000 00000000 00001000 76f24000 00000000
be80: 80097780 00000000 00000000 00001000 bd2fbf78 bda54780 bda0dc00 00020000
bea0: bd2fbf44 bd2fbeb0 800abf60 800741cc 00000000 00000000 76f24000 00001000
bec0: 00000001 bda54780 00000000 00000000 00000000 bda0dc00 00000000 00000000
bee0: 00000000 00000000 00000000 00000000 00001000 00000000 00001000 00000000
bf00: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
bf20: bda54780 76f24000 bd2fbf78 76f24000 00000000 00001000 bd2fbf74 bd2fbf48
bf40: 800ac69c 800abeec 00800007 00000022 00000000 00000000 bda54780 76f24000
bf60: 00000000 00001000 bd2fbfa4 bd2fbf78 800acd84 800ac608 00000000 00000000
bf80: 017f7278 76ec7c58 00000000 00000003 8000e604 bd2fa000 00000000 bd2fbfa8
bfa0: 8000e480 800acd4c 017f7278 76ec7c58 00000003 76f24000 00001000 00000000
bfc0: 017f7278 76ec7c58 00000000 00000003 7eac3ad0 7eac3ad4 76f29000 00000000
bfe0: 00000000 7eac3a64 76e389cf 76e6f21c 400e0010 00000003 00000000 00000000
Backtrace: 
[<800e826c>] (do_mpage_readpage+0x0/0x888) from [<800e8bc8>] (mpage_readpages+0xd4/0x130)
[<800e8af4>] (mpage_readpages+0x0/0x130) from [<8011a030>] (ext3_readpages+0x24/0x28)
[<8011a00c>] (ext3_readpages+0x0/0x28) from [<8007dd28>] (__do_page_cache_readahead+0x1f0/0x2d8)
[<8007db38>] (__do_page_cache_readahead+0x0/0x2d8) from [<8007e0e0>] (ondemand_readahead+0x128/0x238)
[<8007dfb8>] (ondemand_readahead+0x0/0x238) from [<8007e3b8>] (page_cache_sync_readahead+0x4c/0x6c)
[<8007e36c>] (page_cache_sync_readahead+0x0/0x6c) from [<8007471c>] (generic_file_aio_read+0x55c/0x7c0)
 r4:bd53cd54
[<800741c0>] (generic_file_aio_read+0x0/0x7c0) from [<800abf60>] (do_sync_read+0x80/0xa8)
[<800abee0>] (do_sync_read+0x0/0xa8) from [<800ac69c>] (vfs_read+0xa0/0x148)
 r9:00001000 r8:00000000 r7:76f24000 r6:bd2fbf78 r5:76f24000
r4:bda54780
[<800ac5fc>] (vfs_read+0x0/0x148) from [<800acd84>] (SyS_read+0x44/0x80)
 r9:00001000 r8:00000000 r7:76f24000 r6:bda54780 r5:00000000
r4:00000000
[<800acd40>] (SyS_read+0x0/0x80) from [<8000e480>] (ret_fast_syscall+0x0/0x30)
 r9:bd2fa000 r8:8000e604 r7:00000003 r6:00000000 r5:76ec7c58
r4:017f7278
Code: e0854184 e51b0084 e14424d8 e51b40a0 (e1c420f0) 
---[ end trace e23d6b4d1dcd7a83 ]---
------------[ cut here ]------------
WARNING: CPU: 0 PID: 731 at /home/jef/kernel/kernel/exit.c:703 do_exit+0x54/0x900()
Modules linked in: arc4 p54usb p54common crc_ccitt fbcon bitblit mac80211 softcursor font cfg80211 dove_drm tda998x drm_kms_helper drm clk_si5351 snd_soc_simple_dt_card snd_soc_spdif_tx mv_cesa snd_soc_kirkwood
CPU: 0 PID: 731 Comm: usb-db Tainted: G      D      3.11.0-rc3-00004-g36f571e-dirty #1
Backtrace: 
[<800112c4>] (dump_backtrace+0x0/0x110) from [<800114dc>] (show_stack+0x18/0x1c)
 r6:000002bf r5:00000009 r4:00000000 r3:00000000
[<800114c4>] (show_stack+0x0/0x1c) from [<803a25b0>] (dump_stack+0x24/0x28)
[<803a258c>] (dump_stack+0x0/0x28) from [<8001ad28>] (warn_slowpath_common+0x74/0x8c)
[<8001acb4>] (warn_slowpath_common+0x0/0x8c) from [<8001ade4>] (warn_slowpath_null+0x24/0x2c)
 r8:00000811 r7:bd2fa000 r6:80439cc4 r5:0000000b r4:804cb598
[<8001adc0>] (warn_slowpath_null+0x0/0x2c) from [<8001f248>] (do_exit+0x54/0x900)
[<8001f1f4>] (do_exit+0x0/0x900) from [<80011664>] (die+0x184/0x238)
 r7:bd2fa000
[<800114e0>] (die+0x0/0x238) from [<803a07dc>] (__do_kernel_fault.part.10+0x6c/0x7c)
[<803a0770>] (__do_kernel_fault.part.10+0x0/0x7c) from [<8001420c>] (do_sect_fault+0x0/0x18)
 r7:bdbe1540 r3:bd2fbc28
[<8001417c>] (do_bad_area+0x0/0x90) from [<80015d10>] (do_alignment+0xd0/0x844)
 r7:00000003 r6:800e89c0 r5:804ec85c r4:bd2fbc28
[<80015c40>] (do_alignment+0x0/0x844) from [<80008460>] (do_DataAbort+0x40/0xa0)
[<80008420>] (do_DataAbort+0x0/0xa0) from [<80011fb8>] (__dabt_svc+0x38/0x60)
Exception stack(0xbd2fbc28 to 0xbd2fbc70)
bc20:                   bd2fbc9c 00000000 00000003 00001000 00000003 bd2fbc70
bc40: 800e8ca4 00000001 00000004 00000000 00000003 bd2fbc9c bd2fbcc8 bd2fbc74
bc60: 800e05e4 800e89c0 600e0013 ffffffff
 r8:00000004 r7:bd2fbc5c r6:ffffffff r5:600e0013 r4:800e89c0
[<800e826c>] (do_mpage_readpage+0x0/0x888) from [<800e8bc8>] (mpage_readpages+0xd4/0x130)
[<800e8af4>] (mpage_readpages+0x0/0x130) from [<8011a030>] (ext3_readpages+0x24/0x28)
[<8011a00c>] (ext3_readpages+0x0/0x28) from [<8007dd28>] (__do_page_cache_readahead+0x1f0/0x2d8)
[<8007db38>] (__do_page_cache_readahead+0x0/0x2d8) from [<8007e0e0>] (ondemand_readahead+0x128/0x238)
[<8007dfb8>] (ondemand_readahead+0x0/0x238) from [<8007e3b8>] (page_cache_sync_readahead+0x4c/0x6c)
[<8007e36c>] (page_cache_sync_readahead+0x0/0x6c) from [<8007471c>] (generic_file_aio_read+0x55c/0x7c0)
 r4:bd53cd54
[<800741c0>] (generic_file_aio_read+0x0/0x7c0) from [<800abf60>] (do_sync_read+0x80/0xa8)
[<800abee0>] (do_sync_read+0x0/0xa8) from [<800ac69c>] (vfs_read+0xa0/0x148)
 r9:00001000 r8:00000000 r7:76f24000 r6:bd2fbf78 r5:76f24000
r4:bda54780
[<800ac5fc>] (vfs_read+0x0/0x148) from [<800acd84>] (SyS_read+0x44/0x80)
 r9:00001000 r8:00000000 r7:76f24000 r6:bda54780 r5:00000000
r4:00000000
[<800acd40>] (SyS_read+0x0/0x80) from [<8000e480>] (ret_fast_syscall+0x0/0x30)
 r9:bd2fa000 r8:8000e604 r7:00000003 r6:00000000 r5:76ec7c58
r4:017f7278
---[ end trace e23d6b4d1dcd7a84 ]---
EXT3-fs (sda7): using internal journal
IPv6: ADDRCONF(NETDEV_UP): wlan1: link is not ready
wlan1: authenticate with 00:24:d4:9c:29:68
wlan1: send auth to 00:24:d4:9c:29:68 (try 1/3)
wlan1: authenticated
p54usb 2-1.4.2:1.0 wlan1: disabling HT/VHT due to WEP/TKIP use
wlan1: associate with 00:24:d4:9c:29:68 (try 1/3)
wlan1: RX AssocResp from 00:24:d4:9c:29:68 (capab=0x411 status=0 aid=1)
IPv6: ADDRCONF(NETDEV_CHANGE): wlan1: link becomes ready
wlan1: associated

-- 
Ken ar c'hentañ	|	      ** Breizh ha Linux atav! **
Jef		|		http://moinejf.free.fr/

[PATCH] ARM: Fix r7/r11 confusion when CONFIG_THUMB2_KERNEL=y [OT]

[Jean-Francois Moine]

On Tue, 30 Jul 2013 10:49:04 +0100
Will Deacon <will.deacon@arm.com> wrote:

> On Tue, Jul 30, 2013 at 10:38:53AM +0100, Jean-Francois Moine wrote:
> > BTW, kernels compiled with gcc-4.8 don't work.  
> 
> Erm. Can you elaborate please? There was an issue where SLUB would get
> miscompiled with 4.8 due to some per-cpu variable reordering across
> barrier(), but I fixed that for ARM in 3.10.

I compiled the 3.11.0-rc3 with gcc-4.8.1 and I still get oops in ext3
(no problem when compiled with gcc-4.6). Here is the dmesg.

Booting Linux on physical CPU 0x0
Linux version 3.11.0-rc3-00004-g36f571e-dirty (jef at armhf) (gcc version 4.8.1 (Debian 4.8.1-8) ) #1 PREEMPT Wed Jul 31 09:22:30 CEST 2013
CPU: ARMv7 Processor [560f5815] revision 5 (ARMv7), cr=10c53c7d
CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
Machine: Marvell Dove (Flattened Device Tree), model: SolidRun CuBox
cma: CMA: reserved 32 MiB at 3e000000
Memory policy: ECC disabled, Data cache writeback
On node 0 totalpages: 262144
free_area_init_node: node 0, pgdat 804ebd2c, node_mem_map 8075b000
  Normal zone: 2048 pages used for memmap
  Normal zone: 0 pages reserved
  Normal zone: 262144 pages, LIFO batch:31
CPU: All CPU(s) started in SVC mode.
pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
pcpu-alloc: [0] 0 
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 260096
Kernel command line: console=ttyS0,115200n8 console=tty1,115200 root=/dev/sda7 rootwait video=HDMI-A-1:1920x1080-32 at 60
PID hash table entries: 4096 (order: 2, 16384 bytes)
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 1001516K/1048576K available (3715K kernel code, 177K rwdata, 980K rodata, 135K init, 129K bss, 47060K reserved)
Virtual kernel memory layout:
    vector  : 0xffff0000 - 0xffff1000   (   4 kB)
    fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
    vmalloc : 0xc0800000 - 0xff000000   (1000 MB)
    lowmem  : 0x80000000 - 0xc0000000   (1024 MB)
    modules : 0x7f000000 - 0x80000000   (  16 MB)
      .text : 0x80008000 - 0x8049df34   (4696 kB)
      .init : 0x8049e000 - 0x804bfe68   ( 136 kB)
      .data : 0x804c0000 - 0x804ec5c0   ( 178 kB)
       .bss : 0x804ec5c0 - 0x8050cad0   ( 130 kB)
Preemptible hierarchical RCU implementation.
	Dump stacks of tasks blocking RCU-preempt GP.
NR_IRQS:135
sched_clock: 32 bits at 166MHz, resolution 5ns, wraps every 25769ms
Console: colour dummy device 80x30
console [tty1] enabled
Calibrating delay loop... 789.70 BogoMIPS (lpj=3948544)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
Setting up static identity map for 0x803a6620 - 0x803a6654
devtmpfs: initialized
pinctrl core: initialized pinctrl subsystem
regulator-dummy: no parameters
NET: Registered protocol family 16
DMA: preallocated 256 KiB pool for atomic coherent allocations
Dove 88AP510 SoC
Tauros2: Disabling L2 prefetch.
Tauros2: Disabling line fill burt8.
Tauros2: Enabling L2 cache.
Tauros2: L2 cache support initialised in ARMv7 mode.
bio: create slab <bio-0> at 0
USB Power: Failed to request enable GPIO1: -517
reg-fixed-voltage 1.regulator: Failed to register regulator: -517
platform 1.regulator: Driver reg-fixed-voltage requests probe deferral
SCSI subsystem initialized
libata version 3.00 loaded.
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
Linux video capture interface: v2.00
Advanced Linux Sound Architecture Driver Initialized.
Switched to clocksource orion_clocksource
NET: Registered protocol family 2
TCP established hash table entries: 8192 (order: 4, 65536 bytes)
TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
TCP: reno registered
UDP hash table entries: 512 (order: 1, 8192 bytes)
UDP-Lite hash table entries: 512 (order: 1, 8192 bytes)
NET: Registered protocol family 1
audit: initializing netlink socket (disabled)
type=2000 audit(0.070:1): initialized
msgmni has been set to 2020
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
dove-pinctrl f10d0200.pinctrl: registered pinctrl driver
mv_xor f1060800.dma-engine: Marvell shared XOR driver
mv_xor f1060800.dma-engine: Marvell XOR: ( xor cpy )
mv_xor f1060800.dma-engine: Marvell XOR: ( xor cpy )
mv_xor f1060900.dma-engine: Marvell shared XOR driver
mv_xor f1060900.dma-engine: Marvell XOR: ( xor cpy )
mv_xor f1060900.dma-engine: Marvell XOR: ( xor cpy )
Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled
f1012000.serial: ttyS0 at MMIO 0xf1012000 (irq = 7) is a 16550A
console [ttyS0] enabled
brd: module loaded
sata_mv f10a0000.sata: version 1.28
sata_mv f10a0000.sata: slots 32 ports 1
scsi0 : sata_mv
ata1: SATA max UDMA/133 irq 62
libphy: orion_mdio_bus: probed
mv643xx_eth: MV-643xx 10/100/1000 ethernet driver version 1.4
libphy: PHY orion-mdio-mii:08 not found
libphy: PHY orion-mdio-mii:09 not found
libphy: PHY orion-mdio-mii:0a not found
libphy: PHY orion-mdio-mii:0b not found
libphy: PHY orion-mdio-mii:0c not found
libphy: PHY orion-mdio-mii:0d not found
libphy: PHY orion-mdio-mii:0e not found
libphy: PHY orion-mdio-mii:0f not found
libphy: PHY orion-mdio-mii:10 not found
libphy: PHY orion-mdio-mii:11 not found
libphy: PHY orion-mdio-mii:12 not found
libphy: PHY orion-mdio-mii:13 not found
libphy: PHY orion-mdio-mii:14 not found
libphy: PHY orion-mdio-mii:15 not found
libphy: PHY orion-mdio-mii:16 not found
libphy: PHY orion-mdio-mii:17 not found
libphy: PHY orion-mdio-mii:18 not found
libphy: PHY orion-mdio-mii:19 not found
libphy: PHY orion-mdio-mii:1a not found
libphy: PHY orion-mdio-mii:1b not found
libphy: PHY orion-mdio-mii:1c not found
libphy: PHY orion-mdio-mii:1d not found
libphy: PHY orion-mdio-mii:1e not found
libphy: PHY orion-mdio-mii:1f not found
libphy: PHY orion-mdio-mii:00 not found
mv643xx_eth_port mv643xx_eth_port.0 eth0: port 0 with MAC address 00:50:43:b6:3b:10
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ehci-orion: EHCI orion driver
orion-ehci f1050000.usb-host: EHCI Host Controller
orion-ehci f1050000.usb-host: new USB bus registered, assigned bus number 1
orion-ehci f1050000.usb-host: irq 24, io mem 0xf1050000
orion-ehci f1050000.usb-host: USB 2.0 started, EHCI 1.00
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
orion-ehci f1051000.usb-host: EHCI Host Controller
orion-ehci f1051000.usb-host: new USB bus registered, assigned bus number 2
orion-ehci f1051000.usb-host: irq 25, io mem 0xf1051000
orion-ehci f1051000.usb-host: USB 2.0 started, EHCI 1.00
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 1 port detected
usbcore: registered new interface driver usb-storage
mousedev: PS/2 mouse device common for all mice
rtc-mv f10d8500.rtc: rtc core: registered f10d8500.rtc as rtc0
sdhci: Secure Digital Host Controller Interface driver
sdhci: Copyright(c) Pierre Ossman
sdhci-pltfm: SDHCI platform and OF driver helper
mmc0: no vqmmc regulator found
mmc0: no vmmc regulator found
mmc0: SDHCI controller on f1092000.sdio [f1092000.sdio] using DMA
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
TCP: cubic registered
NET: Registered protocol family 10
NET: Registered protocol family 17
VFP support v0.3: implementor 56 architecture 2 part 20 variant 9 rev 5
ThumbEE CPU extension supported.
PJ4 iWMMXt coprocessor enabled.
USB Power: 5000 mV 
rtc-mv f10d8500.rtc: setting system clock to 2013-07-31 08:15:22 UTC (1375258522)
ALSA device list:
  No soundcards found.
ata1: SATA link down (SStatus 0 SControl F300)
mmc0: new high speed SDHC card at address e624
mmcblk0: mmc0:e624 SU16G 14.8 GiB 
 mmcblk0: p1 p2 p3
Waiting for root device /dev/sda7...
usb 1-1: new high-speed USB device number 2 using orion-ehci
usb-storage 1-1:1.0: USB Mass Storage device detected
scsi1 : usb-storage 1-1:1.0
usb 2-1: new high-speed USB device number 2 using orion-ehci
hub 2-1:1.0: USB hub found
hub 2-1:1.0: 4 ports detected
usb 2-1.4: new high-speed USB device number 3 using orion-ehci
hub 2-1.4:1.0: USB hub found
hub 2-1.4:1.0: 4 ports detected
usb 2-1.4.2: new high-speed USB device number 4 using orion-ehci
scsi 1:0:0:0: Direct-Access     WDC WD25 00JB-55REA0      20.0 PQ: 0 ANSI: 0
sd 1:0:0:0: [sda] 488397168 512-byte logical blocks: (250 GB/232 GiB)
sd 1:0:0:0: [sda] Write Protect is off
sd 1:0:0:0: [sda] Mode Sense: 03 00 00 00
sd 1:0:0:0: [sda] No Caching mode page present
sd 1:0:0:0: [sda] Assuming drive cache: write through
sd 1:0:0:0: [sda] No Caching mode page present
sd 1:0:0:0: [sda] Assuming drive cache: write through
 sda: sda1 sda2 sda3 sda4 < sda5 sda6 sda7 >
sd 1:0:0:0: [sda] No Caching mode page present
sd 1:0:0:0: [sda] Assuming drive cache: write through
sd 1:0:0:0: [sda] Attached SCSI disk
EXT3-fs (sda7): mounted filesystem with ordered data mode
kjournald starting.  Commit interval 5 seconds
usb 2-1.4.3: new low-speed USB device number 5 using orion-ehci
VFS: Mounted root (ext3 filesystem) readonly on device 8:7.
devtmpfs: mounted
Freeing unused kernel memory: 132K (8049e000 - 804bf000)
input: Generic USB K/B as /devices/soc.0/f1051000.usb-host/usb2/2-1/2-1.4/2-1.4.3/2-1.4.3:1.0/input/input0
hid-generic 0003:13BA:0017.0001: input: USB HID v1.10 Keyboard [Generic USB K/B] on usb-f1051000.usb-host-1.4.3/input0
input: Generic USB K/B as /devices/soc.0/f1051000.usb-host/usb2/2-1/2-1.4/2-1.4.3/2-1.4.3:1.1/input/input1
hid-generic 0003:13BA:0017.0002: input: USB HID v1.10 Mouse [Generic USB K/B] on usb-f1051000.usb-host-1.4.3/input1
udevd[583]: starting version 175
[drm] Initialized drm 1.1.0 20060810
cfg80211: Calling CRDA to update world regulatory domain
simple-dt-audio sound.5:  dit-hifi <-> f10b4000.audio-controller mapping ok
tda998x 0-0070: found TDA19988
[drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[drm] No driver support for vblank timestamp query.
usb 2-1.4.2: reset high-speed USB device number 4 using orion-ehci
usb 2-1.4.2: Loading firmware file isl3887usb
usbcore: registered new interface driver p54usb
ieee80211 phy0: p54 detected a LM87 firmware
p54: rx_mtu reduced from 3240 to 2384
ieee80211 phy0: FW rev 2.13.25.0 - Softmac protocol 5.9
ieee80211 phy0: cryptographic accelerator WEP:YES, TKIP:YES, CCMP:YES
Console: switching to colour frame buffer device 240x67
dove-drm video.6: fb0:  frame buffer device
dove-drm video.6: registered panic notifier
[drm] Initialized dove-drm 1.0.0 20130516 on minor 0
ieee80211 phy0: hwaddr 00:12:bf:1e:9c:e4, MAC:isl3887 RF:Frisbee
ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
usb 2-1.4.2: is registered as 'phy0'
Unable to handle kernel NULL pointer dereference at virtual address 00000003
pgd = bd374000
[00000003] *pgd=3d3af831, *pte=00000000, *ppte=00000000
Internal error: Oops: 811 [#1] PREEMPT ARM
Modules linked in: arc4 p54usb p54common crc_ccitt fbcon bitblit mac80211 softcursor font cfg80211 dove_drm tda998x drm_kms_helper drm clk_si5351 snd_soc_simple_dt_card snd_soc_spdif_tx mv_cesa snd_soc_kirkwood
CPU: 0 PID: 731 Comm: usb-db Not tainted 3.11.0-rc3-00004-g36f571e-dirty #1
task: bda0dc00 ti: bd2fa000 task.ti: bd2fa000
PC is at do_mpage_readpage+0x754/0x888
LR is at bio_add_page+0x44/0x4c
pc : [<800e89c0>]    lr : [<800e05e4>]    psr: 600e0013
sp : bd2fbc74  ip : bd2fbcc8  fp : bd2fbc9c
r10: 00000003  r9 : 00000000  r8 : 00000004
r7 : 00000001  r6 : 800e8ca4  r5 : bd2fbc70  r4 : 00000003
r3 : 00001000  r2 : 00000003  r1 : 00000000  r0 : bd2fbc9c
Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
Control: 10c5387d  Table: 3d374019  DAC: 00000015
Process usb-db (pid: 731, stack limit = 0xbd2fa240)
Stack: (0xbd2fbc74 to 0xbd2fc000)
bc60:                                              00000001 bd2fbd64 00200200
bc80: 00100100 bd53cd54 bd9f1340 80eed380 bd2fbd34 bd2fbca0 800e8bc8 800e8278
bca0: bd2fbcc8 bd2fbcbc 8011c554 000000c1 804ebd2c 8011c554 00000002 00000003
bcc0: 0028de87 00000000 00000000 bd2fbcd8 80eed380 803a2f54 0028df40 00000000
bce0: 00001000 00000000 bd402ac0 8003b810 bd2fbcf0 bd2fbcf0 bd53ccb4 bd2fbd7c
bd00: bd53ccbc 00000002 bd2fbd24 8011a00c 00000004 00000004 00000000 0000007a
bd20: 00000000 00000004 bd2fbd44 bd2fbd38 8011a030 800e8b00 bd2fbdac bd2fbd48
bd40: 8007dd28 8011a018 bda54780 00000001 bd53cd54 00000004 bd53cd58 bd2fbd64
bd60: 800c23bc bd2fbd64 bd2fbd64 91827364 bd8d5de8 bd8d5de8 bd2fbd78 bd2fbd78
bd80: 800add50 bd53cd54 bda54780 bda547c8 00000000 00000020 00000003 bd53cd54
bda0: bd2fbdec bd2fbdb0 8007e0e0 8007db44 00000003 bd11e470 bd95462c bdbe1540
bdc0: bd2fbddc bd53cd54 00000000 00000000 bd53cc98 00000001 00000000 bda54780
bde0: bd2fbe0c bd2fbdf0 8007e3b8 8007dfc4 00000000 00000001 00000000 bd53cd54
be00: bd2fbeac bd2fbe10 8007471c 8007e378 00000001 bd954b78 bd9545f8 bd9545f8
be20: 76f24000 76f25000 00000001 00080001 bd2fbeb8 bd2fbec0 ffffffff 00000000
be40: 00000000 bdbe1540 00000001 bd954608 00000001 00000fff bd2fa000 bda547c8
be60: 00000000 00000001 76f25000 00000000 00000000 00001000 76f24000 00000000
be80: 80097780 00000000 00000000 00001000 bd2fbf78 bda54780 bda0dc00 00020000
bea0: bd2fbf44 bd2fbeb0 800abf60 800741cc 00000000 00000000 76f24000 00001000
bec0: 00000001 bda54780 00000000 00000000 00000000 bda0dc00 00000000 00000000
bee0: 00000000 00000000 00000000 00000000 00001000 00000000 00001000 00000000
bf00: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
bf20: bda54780 76f24000 bd2fbf78 76f24000 00000000 00001000 bd2fbf74 bd2fbf48
bf40: 800ac69c 800abeec 00800007 00000022 00000000 00000000 bda54780 76f24000
bf60: 00000000 00001000 bd2fbfa4 bd2fbf78 800acd84 800ac608 00000000 00000000
bf80: 017f7278 76ec7c58 00000000 00000003 8000e604 bd2fa000 00000000 bd2fbfa8
bfa0: 8000e480 800acd4c 017f7278 76ec7c58 00000003 76f24000 00001000 00000000
bfc0: 017f7278 76ec7c58 00000000 00000003 7eac3ad0 7eac3ad4 76f29000 00000000
bfe0: 00000000 7eac3a64 76e389cf 76e6f21c 400e0010 00000003 00000000 00000000
Backtrace: 
[<800e826c>] (do_mpage_readpage+0x0/0x888) from [<800e8bc8>] (mpage_readpages+0xd4/0x130)
[<800e8af4>] (mpage_readpages+0x0/0x130) from [<8011a030>] (ext3_readpages+0x24/0x28)
[<8011a00c>] (ext3_readpages+0x0/0x28) from [<8007dd28>] (__do_page_cache_readahead+0x1f0/0x2d8)
[<8007db38>] (__do_page_cache_readahead+0x0/0x2d8) from [<8007e0e0>] (ondemand_readahead+0x128/0x238)
[<8007dfb8>] (ondemand_readahead+0x0/0x238) from [<8007e3b8>] (page_cache_sync_readahead+0x4c/0x6c)
[<8007e36c>] (page_cache_sync_readahead+0x0/0x6c) from [<8007471c>] (generic_file_aio_read+0x55c/0x7c0)
 r4:bd53cd54
[<800741c0>] (generic_file_aio_read+0x0/0x7c0) from [<800abf60>] (do_sync_read+0x80/0xa8)
[<800abee0>] (do_sync_read+0x0/0xa8) from [<800ac69c>] (vfs_read+0xa0/0x148)
 r9:00001000 r8:00000000 r7:76f24000 r6:bd2fbf78 r5:76f24000
r4:bda54780
[<800ac5fc>] (vfs_read+0x0/0x148) from [<800acd84>] (SyS_read+0x44/0x80)
 r9:00001000 r8:00000000 r7:76f24000 r6:bda54780 r5:00000000
r4:00000000
[<800acd40>] (SyS_read+0x0/0x80) from [<8000e480>] (ret_fast_syscall+0x0/0x30)
 r9:bd2fa000 r8:8000e604 r7:00000003 r6:00000000 r5:76ec7c58
r4:017f7278
Code: e0854184 e51b0084 e14424d8 e51b40a0 (e1c420f0) 
---[ end trace e23d6b4d1dcd7a83 ]---
------------[ cut here ]------------
WARNING: CPU: 0 PID: 731 at /home/jef/kernel/kernel/exit.c:703 do_exit+0x54/0x900()
Modules linked in: arc4 p54usb p54common crc_ccitt fbcon bitblit mac80211 softcursor font cfg80211 dove_drm tda998x drm_kms_helper drm clk_si5351 snd_soc_simple_dt_card snd_soc_spdif_tx mv_cesa snd_soc_kirkwood
CPU: 0 PID: 731 Comm: usb-db Tainted: G      D      3.11.0-rc3-00004-g36f571e-dirty #1
Backtrace: 
[<800112c4>] (dump_backtrace+0x0/0x110) from [<800114dc>] (show_stack+0x18/0x1c)
 r6:000002bf r5:00000009 r4:00000000 r3:00000000
[<800114c4>] (show_stack+0x0/0x1c) from [<803a25b0>] (dump_stack+0x24/0x28)
[<803a258c>] (dump_stack+0x0/0x28) from [<8001ad28>] (warn_slowpath_common+0x74/0x8c)
[<8001acb4>] (warn_slowpath_common+0x0/0x8c) from [<8001ade4>] (warn_slowpath_null+0x24/0x2c)
 r8:00000811 r7:bd2fa000 r6:80439cc4 r5:0000000b r4:804cb598
[<8001adc0>] (warn_slowpath_null+0x0/0x2c) from [<8001f248>] (do_exit+0x54/0x900)
[<8001f1f4>] (do_exit+0x0/0x900) from [<80011664>] (die+0x184/0x238)
 r7:bd2fa000
[<800114e0>] (die+0x0/0x238) from [<803a07dc>] (__do_kernel_fault.part.10+0x6c/0x7c)
[<803a0770>] (__do_kernel_fault.part.10+0x0/0x7c) from [<8001420c>] (do_sect_fault+0x0/0x18)
 r7:bdbe1540 r3:bd2fbc28
[<8001417c>] (do_bad_area+0x0/0x90) from [<80015d10>] (do_alignment+0xd0/0x844)
 r7:00000003 r6:800e89c0 r5:804ec85c r4:bd2fbc28
[<80015c40>] (do_alignment+0x0/0x844) from [<80008460>] (do_DataAbort+0x40/0xa0)
[<80008420>] (do_DataAbort+0x0/0xa0) from [<80011fb8>] (__dabt_svc+0x38/0x60)
Exception stack(0xbd2fbc28 to 0xbd2fbc70)
bc20:                   bd2fbc9c 00000000 00000003 00001000 00000003 bd2fbc70
bc40: 800e8ca4 00000001 00000004 00000000 00000003 bd2fbc9c bd2fbcc8 bd2fbc74
bc60: 800e05e4 800e89c0 600e0013 ffffffff
 r8:00000004 r7:bd2fbc5c r6:ffffffff r5:600e0013 r4:800e89c0
[<800e826c>] (do_mpage_readpage+0x0/0x888) from [<800e8bc8>] (mpage_readpages+0xd4/0x130)
[<800e8af4>] (mpage_readpages+0x0/0x130) from [<8011a030>] (ext3_readpages+0x24/0x28)
[<8011a00c>] (ext3_readpages+0x0/0x28) from [<8007dd28>] (__do_page_cache_readahead+0x1f0/0x2d8)
[<8007db38>] (__do_page_cache_readahead+0x0/0x2d8) from [<8007e0e0>] (ondemand_readahead+0x128/0x238)
[<8007dfb8>] (ondemand_readahead+0x0/0x238) from [<8007e3b8>] (page_cache_sync_readahead+0x4c/0x6c)
[<8007e36c>] (page_cache_sync_readahead+0x0/0x6c) from [<8007471c>] (generic_file_aio_read+0x55c/0x7c0)
 r4:bd53cd54
[<800741c0>] (generic_file_aio_read+0x0/0x7c0) from [<800abf60>] (do_sync_read+0x80/0xa8)
[<800abee0>] (do_sync_read+0x0/0xa8) from [<800ac69c>] (vfs_read+0xa0/0x148)
 r9:00001000 r8:00000000 r7:76f24000 r6:bd2fbf78 r5:76f24000
r4:bda54780
[<800ac5fc>] (vfs_read+0x0/0x148) from [<800acd84>] (SyS_read+0x44/0x80)
 r9:00001000 r8:00000000 r7:76f24000 r6:bda54780 r5:00000000
r4:00000000
[<800acd40>] (SyS_read+0x0/0x80) from [<8000e480>] (ret_fast_syscall+0x0/0x30)
 r9:bd2fa000 r8:8000e604 r7:00000003 r6:00000000 r5:76ec7c58
r4:017f7278
---[ end trace e23d6b4d1dcd7a84 ]---
EXT3-fs (sda7): using internal journal
IPv6: ADDRCONF(NETDEV_UP): wlan1: link is not ready
wlan1: authenticate with 00:24:d4:9c:29:68
wlan1: send auth to 00:24:d4:9c:29:68 (try 1/3)
wlan1: authenticated
p54usb 2-1.4.2:1.0 wlan1: disabling HT/VHT due to WEP/TKIP use
wlan1: associate with 00:24:d4:9c:29:68 (try 1/3)
wlan1: RX AssocResp from 00:24:d4:9c:29:68 (capab=0x411 status=0 aid=1)
IPv6: ADDRCONF(NETDEV_CHANGE): wlan1: link becomes ready
wlan1: associated

-- 
Ken ar c'henta?	|	      ** Breizh ha Linux atav! **
Jef		|		http://moinejf.free.fr/

Re: [PATCH] ARM: Fix r7/r11 confusion when CONFIG_THUMB2_KERNEL=y [OT]

[Will Deacon]

[Adding Gregory, as this is a Marvell CPU]

On Wed, Jul 31, 2013 at 10:03:09AM +0100, Jean-Francois Moine wrote:
> I compiled the 3.11.0-rc3 with gcc-4.8.1 and I still get oops in ext3
> (no problem when compiled with gcc-4.6). Here is the dmesg.

There were some recent errata fixes from Gregory and I don't think they all
made it into mainline yet. Gregory -- does the panic below look like
something that could be related to the problems you were seeing with DMA?

Cheers,

Will

> Booting Linux on physical CPU 0x0
> Linux version 3.11.0-rc3-00004-g36f571e-dirty (jef@armhf) (gcc version 4.8.1 (Debian 4.8.1-8) ) #1 PREEMPT Wed Jul 31 09:22:30 CEST 2013
> CPU: ARMv7 Processor [560f5815] revision 5 (ARMv7), cr=10c53c7d
> CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
> Machine: Marvell Dove (Flattened Device Tree), model: SolidRun CuBox
> cma: CMA: reserved 32 MiB at 3e000000
> Memory policy: ECC disabled, Data cache writeback
> On node 0 totalpages: 262144
> free_area_init_node: node 0, pgdat 804ebd2c, node_mem_map 8075b000
>   Normal zone: 2048 pages used for memmap
>   Normal zone: 0 pages reserved
>   Normal zone: 262144 pages, LIFO batch:31
> CPU: All CPU(s) started in SVC mode.
> pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
> pcpu-alloc: [0] 0
> Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 260096
> Kernel command line: console=ttyS0,115200n8 console=tty1,115200 root=/dev/sda7 rootwait video=HDMI-A-1:1920x1080-32@60
> PID hash table entries: 4096 (order: 2, 16384 bytes)
> Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
> Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
> Memory: 1001516K/1048576K available (3715K kernel code, 177K rwdata, 980K rodata, 135K init, 129K bss, 47060K reserved)
> Virtual kernel memory layout:
>     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
>     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
>     vmalloc : 0xc0800000 - 0xff000000   (1000 MB)
>     lowmem  : 0x80000000 - 0xc0000000   (1024 MB)
>     modules : 0x7f000000 - 0x80000000   (  16 MB)
>       .text : 0x80008000 - 0x8049df34   (4696 kB)
>       .init : 0x8049e000 - 0x804bfe68   ( 136 kB)
>       .data : 0x804c0000 - 0x804ec5c0   ( 178 kB)
>        .bss : 0x804ec5c0 - 0x8050cad0   ( 130 kB)
> Preemptible hierarchical RCU implementation.
>         Dump stacks of tasks blocking RCU-preempt GP.
> NR_IRQS:135
> sched_clock: 32 bits at 166MHz, resolution 5ns, wraps every 25769ms
> Console: colour dummy device 80x30
> console [tty1] enabled
> Calibrating delay loop... 789.70 BogoMIPS (lpj=3948544)
> pid_max: default: 32768 minimum: 301
> Mount-cache hash table entries: 512
> CPU: Testing write buffer coherency: ok
> Setting up static identity map for 0x803a6620 - 0x803a6654
> devtmpfs: initialized
> pinctrl core: initialized pinctrl subsystem
> regulator-dummy: no parameters
> NET: Registered protocol family 16
> DMA: preallocated 256 KiB pool for atomic coherent allocations
> Dove 88AP510 SoC
> Tauros2: Disabling L2 prefetch.
> Tauros2: Disabling line fill burt8.
> Tauros2: Enabling L2 cache.
> Tauros2: L2 cache support initialised in ARMv7 mode.
> bio: create slab <bio-0> at 0
> USB Power: Failed to request enable GPIO1: -517
> reg-fixed-voltage 1.regulator: Failed to register regulator: -517
> platform 1.regulator: Driver reg-fixed-voltage requests probe deferral
> SCSI subsystem initialized
> libata version 3.00 loaded.
> usbcore: registered new interface driver usbfs
> usbcore: registered new interface driver hub
> usbcore: registered new device driver usb
> Linux video capture interface: v2.00
> Advanced Linux Sound Architecture Driver Initialized.
> Switched to clocksource orion_clocksource
> NET: Registered protocol family 2
> TCP established hash table entries: 8192 (order: 4, 65536 bytes)
> TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
> TCP: Hash tables configured (established 8192 bind 8192)
> TCP: reno registered
> UDP hash table entries: 512 (order: 1, 8192 bytes)
> UDP-Lite hash table entries: 512 (order: 1, 8192 bytes)
> NET: Registered protocol family 1
> audit: initializing netlink socket (disabled)
> type=2000 audit(0.070:1): initialized
> msgmni has been set to 2020
> io scheduler noop registered
> io scheduler deadline registered
> io scheduler cfq registered (default)
> dove-pinctrl f10d0200.pinctrl: registered pinctrl driver
> mv_xor f1060800.dma-engine: Marvell shared XOR driver
> mv_xor f1060800.dma-engine: Marvell XOR: ( xor cpy )
> mv_xor f1060800.dma-engine: Marvell XOR: ( xor cpy )
> mv_xor f1060900.dma-engine: Marvell shared XOR driver
> mv_xor f1060900.dma-engine: Marvell XOR: ( xor cpy )
> mv_xor f1060900.dma-engine: Marvell XOR: ( xor cpy )
> Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled
> f1012000.serial: ttyS0 at MMIO 0xf1012000 (irq = 7) is a 16550A
> console [ttyS0] enabled
> brd: module loaded
> sata_mv f10a0000.sata: version 1.28
> sata_mv f10a0000.sata: slots 32 ports 1
> scsi0 : sata_mv
> ata1: SATA max UDMA/133 irq 62
> libphy: orion_mdio_bus: probed
> mv643xx_eth: MV-643xx 10/100/1000 ethernet driver version 1.4
> libphy: PHY orion-mdio-mii:08 not found
> libphy: PHY orion-mdio-mii:09 not found
> libphy: PHY orion-mdio-mii:0a not found
> libphy: PHY orion-mdio-mii:0b not found
> libphy: PHY orion-mdio-mii:0c not found
> libphy: PHY orion-mdio-mii:0d not found
> libphy: PHY orion-mdio-mii:0e not found
> libphy: PHY orion-mdio-mii:0f not found
> libphy: PHY orion-mdio-mii:10 not found
> libphy: PHY orion-mdio-mii:11 not found
> libphy: PHY orion-mdio-mii:12 not found
> libphy: PHY orion-mdio-mii:13 not found
> libphy: PHY orion-mdio-mii:14 not found
> libphy: PHY orion-mdio-mii:15 not found
> libphy: PHY orion-mdio-mii:16 not found
> libphy: PHY orion-mdio-mii:17 not found
> libphy: PHY orion-mdio-mii:18 not found
> libphy: PHY orion-mdio-mii:19 not found
> libphy: PHY orion-mdio-mii:1a not found
> libphy: PHY orion-mdio-mii:1b not found
> libphy: PHY orion-mdio-mii:1c not found
> libphy: PHY orion-mdio-mii:1d not found
> libphy: PHY orion-mdio-mii:1e not found
> libphy: PHY orion-mdio-mii:1f not found
> libphy: PHY orion-mdio-mii:00 not found
> mv643xx_eth_port mv643xx_eth_port.0 eth0: port 0 with MAC address 00:50:43:b6:3b:10
> ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
> ehci-orion: EHCI orion driver
> orion-ehci f1050000.usb-host: EHCI Host Controller
> orion-ehci f1050000.usb-host: new USB bus registered, assigned bus number 1
> orion-ehci f1050000.usb-host: irq 24, io mem 0xf1050000
> orion-ehci f1050000.usb-host: USB 2.0 started, EHCI 1.00
> hub 1-0:1.0: USB hub found
> hub 1-0:1.0: 1 port detected
> orion-ehci f1051000.usb-host: EHCI Host Controller
> orion-ehci f1051000.usb-host: new USB bus registered, assigned bus number 2
> orion-ehci f1051000.usb-host: irq 25, io mem 0xf1051000
> orion-ehci f1051000.usb-host: USB 2.0 started, EHCI 1.00
> hub 2-0:1.0: USB hub found
> hub 2-0:1.0: 1 port detected
> usbcore: registered new interface driver usb-storage
> mousedev: PS/2 mouse device common for all mice
> rtc-mv f10d8500.rtc: rtc core: registered f10d8500.rtc as rtc0
> sdhci: Secure Digital Host Controller Interface driver
> sdhci: Copyright(c) Pierre Ossman
> sdhci-pltfm: SDHCI platform and OF driver helper
> mmc0: no vqmmc regulator found
> mmc0: no vmmc regulator found
> mmc0: SDHCI controller on f1092000.sdio [f1092000.sdio] using DMA
> usbcore: registered new interface driver usbhid
> usbhid: USB HID core driver
> TCP: cubic registered
> NET: Registered protocol family 10
> NET: Registered protocol family 17
> VFP support v0.3: implementor 56 architecture 2 part 20 variant 9 rev 5
> ThumbEE CPU extension supported.
> PJ4 iWMMXt coprocessor enabled.
> USB Power: 5000 mV
> rtc-mv f10d8500.rtc: setting system clock to 2013-07-31 08:15:22 UTC (1375258522)
> ALSA device list:
>   No soundcards found.
> ata1: SATA link down (SStatus 0 SControl F300)
> mmc0: new high speed SDHC card at address e624
> mmcblk0: mmc0:e624 SU16G 14.8 GiB
>  mmcblk0: p1 p2 p3
> Waiting for root device /dev/sda7...
> usb 1-1: new high-speed USB device number 2 using orion-ehci
> usb-storage 1-1:1.0: USB Mass Storage device detected
> scsi1 : usb-storage 1-1:1.0
> usb 2-1: new high-speed USB device number 2 using orion-ehci
> hub 2-1:1.0: USB hub found
> hub 2-1:1.0: 4 ports detected
> usb 2-1.4: new high-speed USB device number 3 using orion-ehci
> hub 2-1.4:1.0: USB hub found
> hub 2-1.4:1.0: 4 ports detected
> usb 2-1.4.2: new high-speed USB device number 4 using orion-ehci
> scsi 1:0:0:0: Direct-Access     WDC WD25 00JB-55REA0      20.0 PQ: 0 ANSI: 0
> sd 1:0:0:0: [sda] 488397168 512-byte logical blocks: (250 GB/232 GiB)
> sd 1:0:0:0: [sda] Write Protect is off
> sd 1:0:0:0: [sda] Mode Sense: 03 00 00 00
> sd 1:0:0:0: [sda] No Caching mode page present
> sd 1:0:0:0: [sda] Assuming drive cache: write through
> sd 1:0:0:0: [sda] No Caching mode page present
> sd 1:0:0:0: [sda] Assuming drive cache: write through
>  sda: sda1 sda2 sda3 sda4 < sda5 sda6 sda7 >
> sd 1:0:0:0: [sda] No Caching mode page present
> sd 1:0:0:0: [sda] Assuming drive cache: write through
> sd 1:0:0:0: [sda] Attached SCSI disk
> EXT3-fs (sda7): mounted filesystem with ordered data mode
> kjournald starting.  Commit interval 5 seconds
> usb 2-1.4.3: new low-speed USB device number 5 using orion-ehci
> VFS: Mounted root (ext3 filesystem) readonly on device 8:7.
> devtmpfs: mounted
> Freeing unused kernel memory: 132K (8049e000 - 804bf000)
> input: Generic USB K/B as /devices/soc.0/f1051000.usb-host/usb2/2-1/2-1.4/2-1.4.3/2-1.4.3:1.0/input/input0
> hid-generic 0003:13BA:0017.0001: input: USB HID v1.10 Keyboard [Generic USB K/B] on usb-f1051000.usb-host-1.4.3/input0
> input: Generic USB K/B as /devices/soc.0/f1051000.usb-host/usb2/2-1/2-1.4/2-1.4.3/2-1.4.3:1.1/input/input1
> hid-generic 0003:13BA:0017.0002: input: USB HID v1.10 Mouse [Generic USB K/B] on usb-f1051000.usb-host-1.4.3/input1
> udevd[583]: starting version 175
> [drm] Initialized drm 1.1.0 20060810
> cfg80211: Calling CRDA to update world regulatory domain
> simple-dt-audio sound.5:  dit-hifi <-> f10b4000.audio-controller mapping ok
> tda998x 0-0070: found TDA19988
> [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
> [drm] No driver support for vblank timestamp query.
> usb 2-1.4.2: reset high-speed USB device number 4 using orion-ehci
> usb 2-1.4.2: Loading firmware file isl3887usb
> usbcore: registered new interface driver p54usb
> ieee80211 phy0: p54 detected a LM87 firmware
> p54: rx_mtu reduced from 3240 to 2384
> ieee80211 phy0: FW rev 2.13.25.0 - Softmac protocol 5.9
> ieee80211 phy0: cryptographic accelerator WEP:YES, TKIP:YES, CCMP:YES
> Console: switching to colour frame buffer device 240x67
> dove-drm video.6: fb0:  frame buffer device
> dove-drm video.6: registered panic notifier
> [drm] Initialized dove-drm 1.0.0 20130516 on minor 0
> ieee80211 phy0: hwaddr 00:12:bf:1e:9c:e4, MAC:isl3887 RF:Frisbee
> ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
> usb 2-1.4.2: is registered as 'phy0'
> Unable to handle kernel NULL pointer dereference at virtual address 00000003
> pgd = bd374000
> [00000003] *pgd=3d3af831, *pte=00000000, *ppte=00000000
> Internal error: Oops: 811 [#1] PREEMPT ARM
> Modules linked in: arc4 p54usb p54common crc_ccitt fbcon bitblit mac80211 softcursor font cfg80211 dove_drm tda998x drm_kms_helper drm clk_si5351 snd_soc_simple_dt_card snd_soc_spdif_tx mv_cesa snd_soc_kirkwood
> CPU: 0 PID: 731 Comm: usb-db Not tainted 3.11.0-rc3-00004-g36f571e-dirty #1
> task: bda0dc00 ti: bd2fa000 task.ti: bd2fa000
> PC is at do_mpage_readpage+0x754/0x888
> LR is at bio_add_page+0x44/0x4c
> pc : [<800e89c0>]    lr : [<800e05e4>]    psr: 600e0013
> sp : bd2fbc74  ip : bd2fbcc8  fp : bd2fbc9c
> r10: 00000003  r9 : 00000000  r8 : 00000004
> r7 : 00000001  r6 : 800e8ca4  r5 : bd2fbc70  r4 : 00000003
> r3 : 00001000  r2 : 00000003  r1 : 00000000  r0 : bd2fbc9c
> Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
> Control: 10c5387d  Table: 3d374019  DAC: 00000015
> Process usb-db (pid: 731, stack limit = 0xbd2fa240)
> Stack: (0xbd2fbc74 to 0xbd2fc000)
> bc60:                                              00000001 bd2fbd64 00200200
> bc80: 00100100 bd53cd54 bd9f1340 80eed380 bd2fbd34 bd2fbca0 800e8bc8 800e8278
> bca0: bd2fbcc8 bd2fbcbc 8011c554 000000c1 804ebd2c 8011c554 00000002 00000003
> bcc0: 0028de87 00000000 00000000 bd2fbcd8 80eed380 803a2f54 0028df40 00000000
> bce0: 00001000 00000000 bd402ac0 8003b810 bd2fbcf0 bd2fbcf0 bd53ccb4 bd2fbd7c
> bd00: bd53ccbc 00000002 bd2fbd24 8011a00c 00000004 00000004 00000000 0000007a
> bd20: 00000000 00000004 bd2fbd44 bd2fbd38 8011a030 800e8b00 bd2fbdac bd2fbd48
> bd40: 8007dd28 8011a018 bda54780 00000001 bd53cd54 00000004 bd53cd58 bd2fbd64
> bd60: 800c23bc bd2fbd64 bd2fbd64 91827364 bd8d5de8 bd8d5de8 bd2fbd78 bd2fbd78
> bd80: 800add50 bd53cd54 bda54780 bda547c8 00000000 00000020 00000003 bd53cd54
> bda0: bd2fbdec bd2fbdb0 8007e0e0 8007db44 00000003 bd11e470 bd95462c bdbe1540
> bdc0: bd2fbddc bd53cd54 00000000 00000000 bd53cc98 00000001 00000000 bda54780
> bde0: bd2fbe0c bd2fbdf0 8007e3b8 8007dfc4 00000000 00000001 00000000 bd53cd54
> be00: bd2fbeac bd2fbe10 8007471c 8007e378 00000001 bd954b78 bd9545f8 bd9545f8
> be20: 76f24000 76f25000 00000001 00080001 bd2fbeb8 bd2fbec0 ffffffff 00000000
> be40: 00000000 bdbe1540 00000001 bd954608 00000001 00000fff bd2fa000 bda547c8
> be60: 00000000 00000001 76f25000 00000000 00000000 00001000 76f24000 00000000
> be80: 80097780 00000000 00000000 00001000 bd2fbf78 bda54780 bda0dc00 00020000
> bea0: bd2fbf44 bd2fbeb0 800abf60 800741cc 00000000 00000000 76f24000 00001000
> bec0: 00000001 bda54780 00000000 00000000 00000000 bda0dc00 00000000 00000000
> bee0: 00000000 00000000 00000000 00000000 00001000 00000000 00001000 00000000
> bf00: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> bf20: bda54780 76f24000 bd2fbf78 76f24000 00000000 00001000 bd2fbf74 bd2fbf48
> bf40: 800ac69c 800abeec 00800007 00000022 00000000 00000000 bda54780 76f24000
> bf60: 00000000 00001000 bd2fbfa4 bd2fbf78 800acd84 800ac608 00000000 00000000
> bf80: 017f7278 76ec7c58 00000000 00000003 8000e604 bd2fa000 00000000 bd2fbfa8
> bfa0: 8000e480 800acd4c 017f7278 76ec7c58 00000003 76f24000 00001000 00000000
> bfc0: 017f7278 76ec7c58 00000000 00000003 7eac3ad0 7eac3ad4 76f29000 00000000
> bfe0: 00000000 7eac3a64 76e389cf 76e6f21c 400e0010 00000003 00000000 00000000
> Backtrace:
> [<800e826c>] (do_mpage_readpage+0x0/0x888) from [<800e8bc8>] (mpage_readpages+0xd4/0x130)
> [<800e8af4>] (mpage_readpages+0x0/0x130) from [<8011a030>] (ext3_readpages+0x24/0x28)
> [<8011a00c>] (ext3_readpages+0x0/0x28) from [<8007dd28>] (__do_page_cache_readahead+0x1f0/0x2d8)
> [<8007db38>] (__do_page_cache_readahead+0x0/0x2d8) from [<8007e0e0>] (ondemand_readahead+0x128/0x238)
> [<8007dfb8>] (ondemand_readahead+0x0/0x238) from [<8007e3b8>] (page_cache_sync_readahead+0x4c/0x6c)
> [<8007e36c>] (page_cache_sync_readahead+0x0/0x6c) from [<8007471c>] (generic_file_aio_read+0x55c/0x7c0)
>  r4:bd53cd54
> [<800741c0>] (generic_file_aio_read+0x0/0x7c0) from [<800abf60>] (do_sync_read+0x80/0xa8)
> [<800abee0>] (do_sync_read+0x0/0xa8) from [<800ac69c>] (vfs_read+0xa0/0x148)
>  r9:00001000 r8:00000000 r7:76f24000 r6:bd2fbf78 r5:76f24000
> r4:bda54780
> [<800ac5fc>] (vfs_read+0x0/0x148) from [<800acd84>] (SyS_read+0x44/0x80)
>  r9:00001000 r8:00000000 r7:76f24000 r6:bda54780 r5:00000000
> r4:00000000
> [<800acd40>] (SyS_read+0x0/0x80) from [<8000e480>] (ret_fast_syscall+0x0/0x30)
>  r9:bd2fa000 r8:8000e604 r7:00000003 r6:00000000 r5:76ec7c58
> r4:017f7278
> Code: e0854184 e51b0084 e14424d8 e51b40a0 (e1c420f0)
> ---[ end trace e23d6b4d1dcd7a83 ]---
> ------------[ cut here ]------------
> WARNING: CPU: 0 PID: 731 at /home/jef/kernel/kernel/exit.c:703 do_exit+0x54/0x900()
> Modules linked in: arc4 p54usb p54common crc_ccitt fbcon bitblit mac80211 softcursor font cfg80211 dove_drm tda998x drm_kms_helper drm clk_si5351 snd_soc_simple_dt_card snd_soc_spdif_tx mv_cesa snd_soc_kirkwood
> CPU: 0 PID: 731 Comm: usb-db Tainted: G      D      3.11.0-rc3-00004-g36f571e-dirty #1
> Backtrace:
> [<800112c4>] (dump_backtrace+0x0/0x110) from [<800114dc>] (show_stack+0x18/0x1c)
>  r6:000002bf r5:00000009 r4:00000000 r3:00000000
> [<800114c4>] (show_stack+0x0/0x1c) from [<803a25b0>] (dump_stack+0x24/0x28)
> [<803a258c>] (dump_stack+0x0/0x28) from [<8001ad28>] (warn_slowpath_common+0x74/0x8c)
> [<8001acb4>] (warn_slowpath_common+0x0/0x8c) from [<8001ade4>] (warn_slowpath_null+0x24/0x2c)
>  r8:00000811 r7:bd2fa000 r6:80439cc4 r5:0000000b r4:804cb598
> [<8001adc0>] (warn_slowpath_null+0x0/0x2c) from [<8001f248>] (do_exit+0x54/0x900)
> [<8001f1f4>] (do_exit+0x0/0x900) from [<80011664>] (die+0x184/0x238)
>  r7:bd2fa000
> [<800114e0>] (die+0x0/0x238) from [<803a07dc>] (__do_kernel_fault.part.10+0x6c/0x7c)
> [<803a0770>] (__do_kernel_fault.part.10+0x0/0x7c) from [<8001420c>] (do_sect_fault+0x0/0x18)
>  r7:bdbe1540 r3:bd2fbc28
> [<8001417c>] (do_bad_area+0x0/0x90) from [<80015d10>] (do_alignment+0xd0/0x844)
>  r7:00000003 r6:800e89c0 r5:804ec85c r4:bd2fbc28
> [<80015c40>] (do_alignment+0x0/0x844) from [<80008460>] (do_DataAbort+0x40/0xa0)
> [<80008420>] (do_DataAbort+0x0/0xa0) from [<80011fb8>] (__dabt_svc+0x38/0x60)
> Exception stack(0xbd2fbc28 to 0xbd2fbc70)
> bc20:                   bd2fbc9c 00000000 00000003 00001000 00000003 bd2fbc70
> bc40: 800e8ca4 00000001 00000004 00000000 00000003 bd2fbc9c bd2fbcc8 bd2fbc74
> bc60: 800e05e4 800e89c0 600e0013 ffffffff
>  r8:00000004 r7:bd2fbc5c r6:ffffffff r5:600e0013 r4:800e89c0
> [<800e826c>] (do_mpage_readpage+0x0/0x888) from [<800e8bc8>] (mpage_readpages+0xd4/0x130)
> [<800e8af4>] (mpage_readpages+0x0/0x130) from [<8011a030>] (ext3_readpages+0x24/0x28)
> [<8011a00c>] (ext3_readpages+0x0/0x28) from [<8007dd28>] (__do_page_cache_readahead+0x1f0/0x2d8)
> [<8007db38>] (__do_page_cache_readahead+0x0/0x2d8) from [<8007e0e0>] (ondemand_readahead+0x128/0x238)
> [<8007dfb8>] (ondemand_readahead+0x0/0x238) from [<8007e3b8>] (page_cache_sync_readahead+0x4c/0x6c)
> [<8007e36c>] (page_cache_sync_readahead+0x0/0x6c) from [<8007471c>] (generic_file_aio_read+0x55c/0x7c0)
>  r4:bd53cd54
> [<800741c0>] (generic_file_aio_read+0x0/0x7c0) from [<800abf60>] (do_sync_read+0x80/0xa8)
> [<800abee0>] (do_sync_read+0x0/0xa8) from [<800ac69c>] (vfs_read+0xa0/0x148)
>  r9:00001000 r8:00000000 r7:76f24000 r6:bd2fbf78 r5:76f24000
> r4:bda54780
> [<800ac5fc>] (vfs_read+0x0/0x148) from [<800acd84>] (SyS_read+0x44/0x80)
>  r9:00001000 r8:00000000 r7:76f24000 r6:bda54780 r5:00000000
> r4:00000000
> [<800acd40>] (SyS_read+0x0/0x80) from [<8000e480>] (ret_fast_syscall+0x0/0x30)
>  r9:bd2fa000 r8:8000e604 r7:00000003 r6:00000000 r5:76ec7c58
> r4:017f7278
> ---[ end trace e23d6b4d1dcd7a84 ]---
> EXT3-fs (sda7): using internal journal
> IPv6: ADDRCONF(NETDEV_UP): wlan1: link is not ready
> wlan1: authenticate with 00:24:d4:9c:29:68
> wlan1: send auth to 00:24:d4:9c:29:68 (try 1/3)
> wlan1: authenticated
> p54usb 2-1.4.2:1.0 wlan1: disabling HT/VHT due to WEP/TKIP use
> wlan1: associate with 00:24:d4:9c:29:68 (try 1/3)
> wlan1: RX AssocResp from 00:24:d4:9c:29:68 (capab=0x411 status=0 aid=1)
> IPv6: ADDRCONF(NETDEV_CHANGE): wlan1: link becomes ready
> wlan1: associated
> 
> --
> Ken ar c'hentañ |             ** Breizh ha Linux atav! **
> Jef             |               http://moinejf.free.fr/
> 

[PATCH] ARM: Fix r7/r11 confusion when CONFIG_THUMB2_KERNEL=y [OT]

[Will Deacon]

[Adding Gregory, as this is a Marvell CPU]

On Wed, Jul 31, 2013 at 10:03:09AM +0100, Jean-Francois Moine wrote:
> I compiled the 3.11.0-rc3 with gcc-4.8.1 and I still get oops in ext3
> (no problem when compiled with gcc-4.6). Here is the dmesg.

There were some recent errata fixes from Gregory and I don't think they all
made it into mainline yet. Gregory -- does the panic below look like
something that could be related to the problems you were seeing with DMA?

Cheers,

Will

> Booting Linux on physical CPU 0x0
> Linux version 3.11.0-rc3-00004-g36f571e-dirty (jef at armhf) (gcc version 4.8.1 (Debian 4.8.1-8) ) #1 PREEMPT Wed Jul 31 09:22:30 CEST 2013
> CPU: ARMv7 Processor [560f5815] revision 5 (ARMv7), cr=10c53c7d
> CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
> Machine: Marvell Dove (Flattened Device Tree), model: SolidRun CuBox
> cma: CMA: reserved 32 MiB at 3e000000
> Memory policy: ECC disabled, Data cache writeback
> On node 0 totalpages: 262144
> free_area_init_node: node 0, pgdat 804ebd2c, node_mem_map 8075b000
>   Normal zone: 2048 pages used for memmap
>   Normal zone: 0 pages reserved
>   Normal zone: 262144 pages, LIFO batch:31
> CPU: All CPU(s) started in SVC mode.
> pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
> pcpu-alloc: [0] 0
> Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 260096
> Kernel command line: console=ttyS0,115200n8 console=tty1,115200 root=/dev/sda7 rootwait video=HDMI-A-1:1920x1080-32 at 60
> PID hash table entries: 4096 (order: 2, 16384 bytes)
> Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
> Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
> Memory: 1001516K/1048576K available (3715K kernel code, 177K rwdata, 980K rodata, 135K init, 129K bss, 47060K reserved)
> Virtual kernel memory layout:
>     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
>     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
>     vmalloc : 0xc0800000 - 0xff000000   (1000 MB)
>     lowmem  : 0x80000000 - 0xc0000000   (1024 MB)
>     modules : 0x7f000000 - 0x80000000   (  16 MB)
>       .text : 0x80008000 - 0x8049df34   (4696 kB)
>       .init : 0x8049e000 - 0x804bfe68   ( 136 kB)
>       .data : 0x804c0000 - 0x804ec5c0   ( 178 kB)
>        .bss : 0x804ec5c0 - 0x8050cad0   ( 130 kB)
> Preemptible hierarchical RCU implementation.
>         Dump stacks of tasks blocking RCU-preempt GP.
> NR_IRQS:135
> sched_clock: 32 bits at 166MHz, resolution 5ns, wraps every 25769ms
> Console: colour dummy device 80x30
> console [tty1] enabled
> Calibrating delay loop... 789.70 BogoMIPS (lpj=3948544)
> pid_max: default: 32768 minimum: 301
> Mount-cache hash table entries: 512
> CPU: Testing write buffer coherency: ok
> Setting up static identity map for 0x803a6620 - 0x803a6654
> devtmpfs: initialized
> pinctrl core: initialized pinctrl subsystem
> regulator-dummy: no parameters
> NET: Registered protocol family 16
> DMA: preallocated 256 KiB pool for atomic coherent allocations
> Dove 88AP510 SoC
> Tauros2: Disabling L2 prefetch.
> Tauros2: Disabling line fill burt8.
> Tauros2: Enabling L2 cache.
> Tauros2: L2 cache support initialised in ARMv7 mode.
> bio: create slab <bio-0> at 0
> USB Power: Failed to request enable GPIO1: -517
> reg-fixed-voltage 1.regulator: Failed to register regulator: -517
> platform 1.regulator: Driver reg-fixed-voltage requests probe deferral
> SCSI subsystem initialized
> libata version 3.00 loaded.
> usbcore: registered new interface driver usbfs
> usbcore: registered new interface driver hub
> usbcore: registered new device driver usb
> Linux video capture interface: v2.00
> Advanced Linux Sound Architecture Driver Initialized.
> Switched to clocksource orion_clocksource
> NET: Registered protocol family 2
> TCP established hash table entries: 8192 (order: 4, 65536 bytes)
> TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
> TCP: Hash tables configured (established 8192 bind 8192)
> TCP: reno registered
> UDP hash table entries: 512 (order: 1, 8192 bytes)
> UDP-Lite hash table entries: 512 (order: 1, 8192 bytes)
> NET: Registered protocol family 1
> audit: initializing netlink socket (disabled)
> type=2000 audit(0.070:1): initialized
> msgmni has been set to 2020
> io scheduler noop registered
> io scheduler deadline registered
> io scheduler cfq registered (default)
> dove-pinctrl f10d0200.pinctrl: registered pinctrl driver
> mv_xor f1060800.dma-engine: Marvell shared XOR driver
> mv_xor f1060800.dma-engine: Marvell XOR: ( xor cpy )
> mv_xor f1060800.dma-engine: Marvell XOR: ( xor cpy )
> mv_xor f1060900.dma-engine: Marvell shared XOR driver
> mv_xor f1060900.dma-engine: Marvell XOR: ( xor cpy )
> mv_xor f1060900.dma-engine: Marvell XOR: ( xor cpy )
> Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled
> f1012000.serial: ttyS0 at MMIO 0xf1012000 (irq = 7) is a 16550A
> console [ttyS0] enabled
> brd: module loaded
> sata_mv f10a0000.sata: version 1.28
> sata_mv f10a0000.sata: slots 32 ports 1
> scsi0 : sata_mv
> ata1: SATA max UDMA/133 irq 62
> libphy: orion_mdio_bus: probed
> mv643xx_eth: MV-643xx 10/100/1000 ethernet driver version 1.4
> libphy: PHY orion-mdio-mii:08 not found
> libphy: PHY orion-mdio-mii:09 not found
> libphy: PHY orion-mdio-mii:0a not found
> libphy: PHY orion-mdio-mii:0b not found
> libphy: PHY orion-mdio-mii:0c not found
> libphy: PHY orion-mdio-mii:0d not found
> libphy: PHY orion-mdio-mii:0e not found
> libphy: PHY orion-mdio-mii:0f not found
> libphy: PHY orion-mdio-mii:10 not found
> libphy: PHY orion-mdio-mii:11 not found
> libphy: PHY orion-mdio-mii:12 not found
> libphy: PHY orion-mdio-mii:13 not found
> libphy: PHY orion-mdio-mii:14 not found
> libphy: PHY orion-mdio-mii:15 not found
> libphy: PHY orion-mdio-mii:16 not found
> libphy: PHY orion-mdio-mii:17 not found
> libphy: PHY orion-mdio-mii:18 not found
> libphy: PHY orion-mdio-mii:19 not found
> libphy: PHY orion-mdio-mii:1a not found
> libphy: PHY orion-mdio-mii:1b not found
> libphy: PHY orion-mdio-mii:1c not found
> libphy: PHY orion-mdio-mii:1d not found
> libphy: PHY orion-mdio-mii:1e not found
> libphy: PHY orion-mdio-mii:1f not found
> libphy: PHY orion-mdio-mii:00 not found
> mv643xx_eth_port mv643xx_eth_port.0 eth0: port 0 with MAC address 00:50:43:b6:3b:10
> ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
> ehci-orion: EHCI orion driver
> orion-ehci f1050000.usb-host: EHCI Host Controller
> orion-ehci f1050000.usb-host: new USB bus registered, assigned bus number 1
> orion-ehci f1050000.usb-host: irq 24, io mem 0xf1050000
> orion-ehci f1050000.usb-host: USB 2.0 started, EHCI 1.00
> hub 1-0:1.0: USB hub found
> hub 1-0:1.0: 1 port detected
> orion-ehci f1051000.usb-host: EHCI Host Controller
> orion-ehci f1051000.usb-host: new USB bus registered, assigned bus number 2
> orion-ehci f1051000.usb-host: irq 25, io mem 0xf1051000
> orion-ehci f1051000.usb-host: USB 2.0 started, EHCI 1.00
> hub 2-0:1.0: USB hub found
> hub 2-0:1.0: 1 port detected
> usbcore: registered new interface driver usb-storage
> mousedev: PS/2 mouse device common for all mice
> rtc-mv f10d8500.rtc: rtc core: registered f10d8500.rtc as rtc0
> sdhci: Secure Digital Host Controller Interface driver
> sdhci: Copyright(c) Pierre Ossman
> sdhci-pltfm: SDHCI platform and OF driver helper
> mmc0: no vqmmc regulator found
> mmc0: no vmmc regulator found
> mmc0: SDHCI controller on f1092000.sdio [f1092000.sdio] using DMA
> usbcore: registered new interface driver usbhid
> usbhid: USB HID core driver
> TCP: cubic registered
> NET: Registered protocol family 10
> NET: Registered protocol family 17
> VFP support v0.3: implementor 56 architecture 2 part 20 variant 9 rev 5
> ThumbEE CPU extension supported.
> PJ4 iWMMXt coprocessor enabled.
> USB Power: 5000 mV
> rtc-mv f10d8500.rtc: setting system clock to 2013-07-31 08:15:22 UTC (1375258522)
> ALSA device list:
>   No soundcards found.
> ata1: SATA link down (SStatus 0 SControl F300)
> mmc0: new high speed SDHC card at address e624
> mmcblk0: mmc0:e624 SU16G 14.8 GiB
>  mmcblk0: p1 p2 p3
> Waiting for root device /dev/sda7...
> usb 1-1: new high-speed USB device number 2 using orion-ehci
> usb-storage 1-1:1.0: USB Mass Storage device detected
> scsi1 : usb-storage 1-1:1.0
> usb 2-1: new high-speed USB device number 2 using orion-ehci
> hub 2-1:1.0: USB hub found
> hub 2-1:1.0: 4 ports detected
> usb 2-1.4: new high-speed USB device number 3 using orion-ehci
> hub 2-1.4:1.0: USB hub found
> hub 2-1.4:1.0: 4 ports detected
> usb 2-1.4.2: new high-speed USB device number 4 using orion-ehci
> scsi 1:0:0:0: Direct-Access     WDC WD25 00JB-55REA0      20.0 PQ: 0 ANSI: 0
> sd 1:0:0:0: [sda] 488397168 512-byte logical blocks: (250 GB/232 GiB)
> sd 1:0:0:0: [sda] Write Protect is off
> sd 1:0:0:0: [sda] Mode Sense: 03 00 00 00
> sd 1:0:0:0: [sda] No Caching mode page present
> sd 1:0:0:0: [sda] Assuming drive cache: write through
> sd 1:0:0:0: [sda] No Caching mode page present
> sd 1:0:0:0: [sda] Assuming drive cache: write through
>  sda: sda1 sda2 sda3 sda4 < sda5 sda6 sda7 >
> sd 1:0:0:0: [sda] No Caching mode page present
> sd 1:0:0:0: [sda] Assuming drive cache: write through
> sd 1:0:0:0: [sda] Attached SCSI disk
> EXT3-fs (sda7): mounted filesystem with ordered data mode
> kjournald starting.  Commit interval 5 seconds
> usb 2-1.4.3: new low-speed USB device number 5 using orion-ehci
> VFS: Mounted root (ext3 filesystem) readonly on device 8:7.
> devtmpfs: mounted
> Freeing unused kernel memory: 132K (8049e000 - 804bf000)
> input: Generic USB K/B as /devices/soc.0/f1051000.usb-host/usb2/2-1/2-1.4/2-1.4.3/2-1.4.3:1.0/input/input0
> hid-generic 0003:13BA:0017.0001: input: USB HID v1.10 Keyboard [Generic USB K/B] on usb-f1051000.usb-host-1.4.3/input0
> input: Generic USB K/B as /devices/soc.0/f1051000.usb-host/usb2/2-1/2-1.4/2-1.4.3/2-1.4.3:1.1/input/input1
> hid-generic 0003:13BA:0017.0002: input: USB HID v1.10 Mouse [Generic USB K/B] on usb-f1051000.usb-host-1.4.3/input1
> udevd[583]: starting version 175
> [drm] Initialized drm 1.1.0 20060810
> cfg80211: Calling CRDA to update world regulatory domain
> simple-dt-audio sound.5:  dit-hifi <-> f10b4000.audio-controller mapping ok
> tda998x 0-0070: found TDA19988
> [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
> [drm] No driver support for vblank timestamp query.
> usb 2-1.4.2: reset high-speed USB device number 4 using orion-ehci
> usb 2-1.4.2: Loading firmware file isl3887usb
> usbcore: registered new interface driver p54usb
> ieee80211 phy0: p54 detected a LM87 firmware
> p54: rx_mtu reduced from 3240 to 2384
> ieee80211 phy0: FW rev 2.13.25.0 - Softmac protocol 5.9
> ieee80211 phy0: cryptographic accelerator WEP:YES, TKIP:YES, CCMP:YES
> Console: switching to colour frame buffer device 240x67
> dove-drm video.6: fb0:  frame buffer device
> dove-drm video.6: registered panic notifier
> [drm] Initialized dove-drm 1.0.0 20130516 on minor 0
> ieee80211 phy0: hwaddr 00:12:bf:1e:9c:e4, MAC:isl3887 RF:Frisbee
> ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
> usb 2-1.4.2: is registered as 'phy0'
> Unable to handle kernel NULL pointer dereference at virtual address 00000003
> pgd = bd374000
> [00000003] *pgd=3d3af831, *pte=00000000, *ppte=00000000
> Internal error: Oops: 811 [#1] PREEMPT ARM
> Modules linked in: arc4 p54usb p54common crc_ccitt fbcon bitblit mac80211 softcursor font cfg80211 dove_drm tda998x drm_kms_helper drm clk_si5351 snd_soc_simple_dt_card snd_soc_spdif_tx mv_cesa snd_soc_kirkwood
> CPU: 0 PID: 731 Comm: usb-db Not tainted 3.11.0-rc3-00004-g36f571e-dirty #1
> task: bda0dc00 ti: bd2fa000 task.ti: bd2fa000
> PC is at do_mpage_readpage+0x754/0x888
> LR is at bio_add_page+0x44/0x4c
> pc : [<800e89c0>]    lr : [<800e05e4>]    psr: 600e0013
> sp : bd2fbc74  ip : bd2fbcc8  fp : bd2fbc9c
> r10: 00000003  r9 : 00000000  r8 : 00000004
> r7 : 00000001  r6 : 800e8ca4  r5 : bd2fbc70  r4 : 00000003
> r3 : 00001000  r2 : 00000003  r1 : 00000000  r0 : bd2fbc9c
> Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
> Control: 10c5387d  Table: 3d374019  DAC: 00000015
> Process usb-db (pid: 731, stack limit = 0xbd2fa240)
> Stack: (0xbd2fbc74 to 0xbd2fc000)
> bc60:                                              00000001 bd2fbd64 00200200
> bc80: 00100100 bd53cd54 bd9f1340 80eed380 bd2fbd34 bd2fbca0 800e8bc8 800e8278
> bca0: bd2fbcc8 bd2fbcbc 8011c554 000000c1 804ebd2c 8011c554 00000002 00000003
> bcc0: 0028de87 00000000 00000000 bd2fbcd8 80eed380 803a2f54 0028df40 00000000
> bce0: 00001000 00000000 bd402ac0 8003b810 bd2fbcf0 bd2fbcf0 bd53ccb4 bd2fbd7c
> bd00: bd53ccbc 00000002 bd2fbd24 8011a00c 00000004 00000004 00000000 0000007a
> bd20: 00000000 00000004 bd2fbd44 bd2fbd38 8011a030 800e8b00 bd2fbdac bd2fbd48
> bd40: 8007dd28 8011a018 bda54780 00000001 bd53cd54 00000004 bd53cd58 bd2fbd64
> bd60: 800c23bc bd2fbd64 bd2fbd64 91827364 bd8d5de8 bd8d5de8 bd2fbd78 bd2fbd78
> bd80: 800add50 bd53cd54 bda54780 bda547c8 00000000 00000020 00000003 bd53cd54
> bda0: bd2fbdec bd2fbdb0 8007e0e0 8007db44 00000003 bd11e470 bd95462c bdbe1540
> bdc0: bd2fbddc bd53cd54 00000000 00000000 bd53cc98 00000001 00000000 bda54780
> bde0: bd2fbe0c bd2fbdf0 8007e3b8 8007dfc4 00000000 00000001 00000000 bd53cd54
> be00: bd2fbeac bd2fbe10 8007471c 8007e378 00000001 bd954b78 bd9545f8 bd9545f8
> be20: 76f24000 76f25000 00000001 00080001 bd2fbeb8 bd2fbec0 ffffffff 00000000
> be40: 00000000 bdbe1540 00000001 bd954608 00000001 00000fff bd2fa000 bda547c8
> be60: 00000000 00000001 76f25000 00000000 00000000 00001000 76f24000 00000000
> be80: 80097780 00000000 00000000 00001000 bd2fbf78 bda54780 bda0dc00 00020000
> bea0: bd2fbf44 bd2fbeb0 800abf60 800741cc 00000000 00000000 76f24000 00001000
> bec0: 00000001 bda54780 00000000 00000000 00000000 bda0dc00 00000000 00000000
> bee0: 00000000 00000000 00000000 00000000 00001000 00000000 00001000 00000000
> bf00: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> bf20: bda54780 76f24000 bd2fbf78 76f24000 00000000 00001000 bd2fbf74 bd2fbf48
> bf40: 800ac69c 800abeec 00800007 00000022 00000000 00000000 bda54780 76f24000
> bf60: 00000000 00001000 bd2fbfa4 bd2fbf78 800acd84 800ac608 00000000 00000000
> bf80: 017f7278 76ec7c58 00000000 00000003 8000e604 bd2fa000 00000000 bd2fbfa8
> bfa0: 8000e480 800acd4c 017f7278 76ec7c58 00000003 76f24000 00001000 00000000
> bfc0: 017f7278 76ec7c58 00000000 00000003 7eac3ad0 7eac3ad4 76f29000 00000000
> bfe0: 00000000 7eac3a64 76e389cf 76e6f21c 400e0010 00000003 00000000 00000000
> Backtrace:
> [<800e826c>] (do_mpage_readpage+0x0/0x888) from [<800e8bc8>] (mpage_readpages+0xd4/0x130)
> [<800e8af4>] (mpage_readpages+0x0/0x130) from [<8011a030>] (ext3_readpages+0x24/0x28)
> [<8011a00c>] (ext3_readpages+0x0/0x28) from [<8007dd28>] (__do_page_cache_readahead+0x1f0/0x2d8)
> [<8007db38>] (__do_page_cache_readahead+0x0/0x2d8) from [<8007e0e0>] (ondemand_readahead+0x128/0x238)
> [<8007dfb8>] (ondemand_readahead+0x0/0x238) from [<8007e3b8>] (page_cache_sync_readahead+0x4c/0x6c)
> [<8007e36c>] (page_cache_sync_readahead+0x0/0x6c) from [<8007471c>] (generic_file_aio_read+0x55c/0x7c0)
>  r4:bd53cd54
> [<800741c0>] (generic_file_aio_read+0x0/0x7c0) from [<800abf60>] (do_sync_read+0x80/0xa8)
> [<800abee0>] (do_sync_read+0x0/0xa8) from [<800ac69c>] (vfs_read+0xa0/0x148)
>  r9:00001000 r8:00000000 r7:76f24000 r6:bd2fbf78 r5:76f24000
> r4:bda54780
> [<800ac5fc>] (vfs_read+0x0/0x148) from [<800acd84>] (SyS_read+0x44/0x80)
>  r9:00001000 r8:00000000 r7:76f24000 r6:bda54780 r5:00000000
> r4:00000000
> [<800acd40>] (SyS_read+0x0/0x80) from [<8000e480>] (ret_fast_syscall+0x0/0x30)
>  r9:bd2fa000 r8:8000e604 r7:00000003 r6:00000000 r5:76ec7c58
> r4:017f7278
> Code: e0854184 e51b0084 e14424d8 e51b40a0 (e1c420f0)
> ---[ end trace e23d6b4d1dcd7a83 ]---
> ------------[ cut here ]------------
> WARNING: CPU: 0 PID: 731 at /home/jef/kernel/kernel/exit.c:703 do_exit+0x54/0x900()
> Modules linked in: arc4 p54usb p54common crc_ccitt fbcon bitblit mac80211 softcursor font cfg80211 dove_drm tda998x drm_kms_helper drm clk_si5351 snd_soc_simple_dt_card snd_soc_spdif_tx mv_cesa snd_soc_kirkwood
> CPU: 0 PID: 731 Comm: usb-db Tainted: G      D      3.11.0-rc3-00004-g36f571e-dirty #1
> Backtrace:
> [<800112c4>] (dump_backtrace+0x0/0x110) from [<800114dc>] (show_stack+0x18/0x1c)
>  r6:000002bf r5:00000009 r4:00000000 r3:00000000
> [<800114c4>] (show_stack+0x0/0x1c) from [<803a25b0>] (dump_stack+0x24/0x28)
> [<803a258c>] (dump_stack+0x0/0x28) from [<8001ad28>] (warn_slowpath_common+0x74/0x8c)
> [<8001acb4>] (warn_slowpath_common+0x0/0x8c) from [<8001ade4>] (warn_slowpath_null+0x24/0x2c)
>  r8:00000811 r7:bd2fa000 r6:80439cc4 r5:0000000b r4:804cb598
> [<8001adc0>] (warn_slowpath_null+0x0/0x2c) from [<8001f248>] (do_exit+0x54/0x900)
> [<8001f1f4>] (do_exit+0x0/0x900) from [<80011664>] (die+0x184/0x238)
>  r7:bd2fa000
> [<800114e0>] (die+0x0/0x238) from [<803a07dc>] (__do_kernel_fault.part.10+0x6c/0x7c)
> [<803a0770>] (__do_kernel_fault.part.10+0x0/0x7c) from [<8001420c>] (do_sect_fault+0x0/0x18)
>  r7:bdbe1540 r3:bd2fbc28
> [<8001417c>] (do_bad_area+0x0/0x90) from [<80015d10>] (do_alignment+0xd0/0x844)
>  r7:00000003 r6:800e89c0 r5:804ec85c r4:bd2fbc28
> [<80015c40>] (do_alignment+0x0/0x844) from [<80008460>] (do_DataAbort+0x40/0xa0)
> [<80008420>] (do_DataAbort+0x0/0xa0) from [<80011fb8>] (__dabt_svc+0x38/0x60)
> Exception stack(0xbd2fbc28 to 0xbd2fbc70)
> bc20:                   bd2fbc9c 00000000 00000003 00001000 00000003 bd2fbc70
> bc40: 800e8ca4 00000001 00000004 00000000 00000003 bd2fbc9c bd2fbcc8 bd2fbc74
> bc60: 800e05e4 800e89c0 600e0013 ffffffff
>  r8:00000004 r7:bd2fbc5c r6:ffffffff r5:600e0013 r4:800e89c0
> [<800e826c>] (do_mpage_readpage+0x0/0x888) from [<800e8bc8>] (mpage_readpages+0xd4/0x130)
> [<800e8af4>] (mpage_readpages+0x0/0x130) from [<8011a030>] (ext3_readpages+0x24/0x28)
> [<8011a00c>] (ext3_readpages+0x0/0x28) from [<8007dd28>] (__do_page_cache_readahead+0x1f0/0x2d8)
> [<8007db38>] (__do_page_cache_readahead+0x0/0x2d8) from [<8007e0e0>] (ondemand_readahead+0x128/0x238)
> [<8007dfb8>] (ondemand_readahead+0x0/0x238) from [<8007e3b8>] (page_cache_sync_readahead+0x4c/0x6c)
> [<8007e36c>] (page_cache_sync_readahead+0x0/0x6c) from [<8007471c>] (generic_file_aio_read+0x55c/0x7c0)
>  r4:bd53cd54
> [<800741c0>] (generic_file_aio_read+0x0/0x7c0) from [<800abf60>] (do_sync_read+0x80/0xa8)
> [<800abee0>] (do_sync_read+0x0/0xa8) from [<800ac69c>] (vfs_read+0xa0/0x148)
>  r9:00001000 r8:00000000 r7:76f24000 r6:bd2fbf78 r5:76f24000
> r4:bda54780
> [<800ac5fc>] (vfs_read+0x0/0x148) from [<800acd84>] (SyS_read+0x44/0x80)
>  r9:00001000 r8:00000000 r7:76f24000 r6:bda54780 r5:00000000
> r4:00000000
> [<800acd40>] (SyS_read+0x0/0x80) from [<8000e480>] (ret_fast_syscall+0x0/0x30)
>  r9:bd2fa000 r8:8000e604 r7:00000003 r6:00000000 r5:76ec7c58
> r4:017f7278
> ---[ end trace e23d6b4d1dcd7a84 ]---
> EXT3-fs (sda7): using internal journal
> IPv6: ADDRCONF(NETDEV_UP): wlan1: link is not ready
> wlan1: authenticate with 00:24:d4:9c:29:68
> wlan1: send auth to 00:24:d4:9c:29:68 (try 1/3)
> wlan1: authenticated
> p54usb 2-1.4.2:1.0 wlan1: disabling HT/VHT due to WEP/TKIP use
> wlan1: associate with 00:24:d4:9c:29:68 (try 1/3)
> wlan1: RX AssocResp from 00:24:d4:9c:29:68 (capab=0x411 status=0 aid=1)
> IPv6: ADDRCONF(NETDEV_CHANGE): wlan1: link becomes ready
> wlan1: associated
> 
> --
> Ken ar c'henta? |             ** Breizh ha Linux atav! **
> Jef             |               http://moinejf.free.fr/
> 

Re: [PATCH] ARM: Fix r7/r11 confusion when CONFIG_THUMB2_KERNEL=y [OT]

[walimis]

On Wed, Jul 31, 2013 at 11:03:09AM +0200, Jean-Francois Moine wrote:
>On Tue, 30 Jul 2013 10:49:04 +0100
>Will Deacon <will.deacon@arm.com> wrote:
>
>> On Tue, Jul 30, 2013 at 10:38:53AM +0100, Jean-Francois Moine wrote:
>> > BTW, kernels compiled with gcc-4.8 don't work.  
>> 
>> Erm. Can you elaborate please? There was an issue where SLUB would get
>> miscompiled with 4.8 due to some per-cpu variable reordering across
>> barrier(), but I fixed that for ARM in 3.10.
>
>I compiled the 3.11.0-rc3 with gcc-4.8.1 and I still get oops in ext3
>(no problem when compiled with gcc-4.6). Here is the dmesg.
Hi, all

I also encounterd the same problem and I think it's an severe issue for the arm arch.
The issue only exists when building the kernel with gcc 4.8.x and CONFIG_FRAME_POINTER=y

There was also a mail to describe the similar issue:
https://lkml.org/lkml/2013/6/13/529
http://www.spinics.net/lists/linux-ext4/msg38685.html

It can be easyly triggered when doing some ext3/ext4 operation and I got the following
backtrace:

------------[ cut here ]------------
kernel BUG at linux/fs/buffer.c:2958!
Internal error: Oops - BUG: 0 [#3] PREEMPT SMP ARM
Modules linked in: tun ext4 crc16 jbd2 loop
CPU: 0 PID: 707 Comm: dd Tainted: G      D      3.10.19-WR6.0.0.0_standard #1
task: dcf78900 ti: d7968000 task.ti: d7968000
PC is at _submit_bh+0x3c/0x24c
LR is at submit_bh+0x1c/0x20
pc : [<c013e4c4>]    lr : [<c013e6f0>]    psr: 60000013
sp : d7969b20  ip : d7969b48  fp : d7969b44
r10: ddf7ec68  r9 : 00000000  r8 : ddd24600
r7 : 00000000  r6 : 00000060  r5 : 00000000  r4 : 00020041
r3 : 00700004  r2 : 00000000  r1 : ddd24600  r0 : 00000060
Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
Control: 30c5387d  Table: 18dbae40  DAC: fffffffd
Process dd (pid: 707, stack limit = 0xd7968238)
Stack: (0xd7969b20 to 0xd796a000)
9b20: 00020041 00000000 00020042 00000000 ddd24600 dcd99400 d7969b54 d7969b48
9b40: c013e6f0 c013e494 d7969bbc d7969b58 bf0391fc c013e6e0 00000400 c0596f48
9b60: ddf7ec60 ddf7ec60 00000000 00020021 00020041 00000000 00020021 00000000
9b80: 00020023 00000000 ffff0000 d7969bfc d7969bac d7969bfc d4e8b980 ddf7ec68
9ba0: d4e8b980 bf040128 ddf7ed44 d7968028 d7969bcc d7969bc0 bf03ae98 bf039054
9bc0: d7969bec d7969bd0 bf03cb3c bf03ae80 ddf7ec68 d4e8b980 dcd98400 c08c8b60
9be0: d7969c2c d7969bf0 bf03cc64 bf03cb1c bf060f7c bf0086c8 000013d3 00000000
9c00: 00000180 00000010 ddf7ec68 d4e8b980 ddf7ec68 c08c8b60 dcd99400 ddf7ed44
9c20: d7969c44 d7969c30 bf040128 bf03cba4 ddf7ec68 00000007 d7969c6c d7969c48
9c40: c0135c08 bf0400f4 00000001 00000000 ddf7ec68 c0a83e00 00000400 ddf7ed44
9c60: d7969ca4 d7969c70 c013d610 c0135b44 00000400 00000400 c0a83e00 00000000
9c80: 00000000 ddf7ec68 00000400 c0a83e00 00000000 d4e8b980 d7969cfc d7969ca8
9ca0: bf03f2f0 c013d53c 00000400 00000400 c0a83e00 00000000 d7968020 de17fc00
9cc0: 03550000 00000000 0354fc00 00000000 d7969cfc 00000000 ddf7ed44 00000400
9ce0: 00000000 de17fc00 bf0781c8 00000400 d7969d6c d7969d00 c00c802c bf03f0d4
9d00: 00000400 00000400 c0a83e00 00000000 00000000 d7968000 00000400 00000c00
9d20: 0354fc00 00000000 c0a83e00 00000000 d7969eb8 00000001 00000000 00000400
9d40: 5292f392 0354fc00 00000000 00000400 d7969eb8 00000000 00000000 de17fc00
9d60: d7969ddc d7969d70 c00c92dc c00c7ec8 0354fc00 00000000 d7969ee0 00000400
9d80: 00000000 d7968000 d7969e14 00000000 c0594e28 c00ac43c ddf7ed44 d7969ee0
9da0: d7969ec0 00000001 0353bc00 00000400 d7969eb8 0354fc00 00000000 d7969eb8
9dc0: ddf7ece0 de17fc00 d7969ec0 00000001 d7969e14 d7969de0 c00c9390 c00c8f84
9de0: 00000400 00000000 c0092dac 0354fc00 00000000 00000001 de17fc00 de17fc00
9e00: d7969ec0 00000000 d7969eac d7969e18 bf0353bc c00c9334 0354fc00 00000000
9e20: d7968000 00000002 d7969e54 d7969e38 c0597018 c00ac708 00000000 d7968000
9e40: 60000013 d7969eb8 c0047f00 60000013 ffffffff d7969ea4 c0594e24 d7968000
9e60: d7969edc c0047e9c c0594e28 00000001 d7968018 c03074a0 c0d98448 00000000
9e80: 00000001 0354fc00 00000000 00000400 d7969f78 de17fc00 00000400 00000000
9ea0: d7969f44 d7969eb0 c0110434 bf03505c 0354fc00 00000000 0001f000 00000400
9ec0: 00000001 de17fc00 00000000 00000000 00000000 dcf78900 00000000 00000000
9ee0: 0354fc00 00000000 00000000 00000000 00000400 00000000 00000400 00000000
9f00: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
9f20: de17fc00 de17fc00 0001f000 d7969f78 00000400 0001f000 d7969f74 d7969f48
9f40: c0110ba4 c01103bc 00000000 00000000 0354fc00 00000000 de17fc00 00000000
9f60: 0001f000 00000400 d7969fa4 d7969f78 c01110b8 c0110acc 0354fc00 00000000
9f80: 00000000 0001d2e8 00000400 00000004 c000dd68 d7968000 00000000 d7969fa8
9fa0: c000dae0 c0111078 00000000 0001d2e8 00000001 0001f000 00000400 00000000
9fc0: 00000000 0001d2e8 00000400 00000004 00000000 0001f400 00000001 00000000
9fe0: 00000000 bed83a9c 0000ca6c 4f7fa426 40000030 00000001 00000000 00000000
[<c013e4c4>] (_submit_bh+0x3c/0x24c) from [<c013e6f0>] (submit_bh+0x1c/0x20)
[<c013e6f0>] (submit_bh+0x1c/0x20) from [<bf0391fc>] (__ext4_get_inode_loc+0x1b4/0x48c [ext4])
[<bf0391fc>] (__ext4_get_inode_loc+0x1b4/0x48c [ext4]) from [<bf03ae98>] (ext4_get_inode_loc+0x24/0x28 [ext4])
[<bf03ae98>] (ext4_get_inode_loc+0x24/0x28 [ext4]) from [<bf03cb3c>] (ext4_reserve_inode_write+0x2c/0x88 [ext4])
[<bf03cb3c>] (ext4_reserve_inode_write+0x2c/0x88 [ext4]) from [<bf03cc64>] (ext4_mark_inode_dirty+0xcc/0x224 [ext4])
[<bf03cc64>] (ext4_mark_inode_dirty+0xcc/0x224 [ext4]) from [<bf040128>] (ext4_dirty_inode+0x40/0x58 [ext4])
[<bf040128>] (ext4_dirty_inode+0x40/0x58 [ext4]) from [<c0135c08>] (__mark_inode_dirty+0xd0/0x2f0)
[<c0135c08>] (__mark_inode_dirty+0xd0/0x2f0) from [<c013d610>] (generic_write_end+0xe0/0xec)
[<c013d610>] (generic_write_end+0xe0/0xec) from [<bf03f2f0>] (ext4_da_write_end+0x228/0x26c [ext4])
[<bf03f2f0>] (ext4_da_write_end+0x228/0x26c [ext4]) from [<c00c802c>] (generic_file_buffered_write+0x170/0x240)
[<c00c802c>] (generic_file_buffered_write+0x170/0x240) from [<c00c92dc>] (__generic_file_aio_write+0x364/0x3b0)
[<c00c92dc>] (__generic_file_aio_write+0x364/0x3b0) from [<c00c9390>] (generic_file_aio_write+0x68/0xc8)
[<c00c9390>] (generic_file_aio_write+0x68/0xc8) from [<bf0353bc>] (ext4_file_write+0x36c/0x454 [ext4])
[<bf0353bc>] (ext4_file_write+0x36c/0x454 [ext4]) from [<c0110434>] (do_sync_write+0x84/0xa8)
[<c0110434>] (do_sync_write+0x84/0xa8) from [<c0110ba4>] (vfs_write+0xe4/0x194)
[<c0110ba4>] (vfs_write+0xe4/0x194) from [<c01110b8>] (SyS_write+0x4c/0x7c)
[<c01110b8>] (SyS_write+0x4c/0x7c) from [<c000dae0>] (ret_fast_syscall+0x0/0x48)
Code: e7f001f2 e5913000 e3130020 1a000000 (e7f001f2) 
---[ end trace 9b74153243e868ff ]---


The BUG() is called in fs/buffer.c:
int _submit_bh(int rw, struct buffer_head *bh, unsigned long bio_flags)
{
...
        BUG_ON(!buffer_mapped(bh));
...
}

Has anyone resolved the problem? 

Best Regard.
walimis

>
>Booting Linux on physical CPU 0x0
>Linux version 3.11.0-rc3-00004-g36f571e-dirty (jef@armhf) (gcc version 4.8.1 (Debian 4.8.1-8) ) #1 PREEMPT Wed Jul 31 09:22:30 CEST 2013
>CPU: ARMv7 Processor [560f5815] revision 5 (ARMv7), cr=10c53c7d
>CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
>Machine: Marvell Dove (Flattened Device Tree), model: SolidRun CuBox
>cma: CMA: reserved 32 MiB at 3e000000
>Memory policy: ECC disabled, Data cache writeback
>On node 0 totalpages: 262144
>free_area_init_node: node 0, pgdat 804ebd2c, node_mem_map 8075b000
>  Normal zone: 2048 pages used for memmap
>  Normal zone: 0 pages reserved
>  Normal zone: 262144 pages, LIFO batch:31
>CPU: All CPU(s) started in SVC mode.
>pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
>pcpu-alloc: [0] 0 
>Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 260096
>Kernel command line: console=ttyS0,115200n8 console=tty1,115200 root=/dev/sda7 rootwait video=HDMI-A-1:1920x1080-32@60
>PID hash table entries: 4096 (order: 2, 16384 bytes)
>Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
>Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
>Memory: 1001516K/1048576K available (3715K kernel code, 177K rwdata, 980K rodata, 135K init, 129K bss, 47060K reserved)
>Virtual kernel memory layout:
>    vector  : 0xffff0000 - 0xffff1000   (   4 kB)
>    fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
>    vmalloc : 0xc0800000 - 0xff000000   (1000 MB)
>    lowmem  : 0x80000000 - 0xc0000000   (1024 MB)
>    modules : 0x7f000000 - 0x80000000   (  16 MB)
>      .text : 0x80008000 - 0x8049df34   (4696 kB)
>      .init : 0x8049e000 - 0x804bfe68   ( 136 kB)
>      .data : 0x804c0000 - 0x804ec5c0   ( 178 kB)
>       .bss : 0x804ec5c0 - 0x8050cad0   ( 130 kB)
>Preemptible hierarchical RCU implementation.
>	Dump stacks of tasks blocking RCU-preempt GP.
>NR_IRQS:135
>sched_clock: 32 bits at 166MHz, resolution 5ns, wraps every 25769ms
>Console: colour dummy device 80x30
>console [tty1] enabled
>Calibrating delay loop... 789.70 BogoMIPS (lpj=3948544)
>pid_max: default: 32768 minimum: 301
>Mount-cache hash table entries: 512
>CPU: Testing write buffer coherency: ok
>Setting up static identity map for 0x803a6620 - 0x803a6654
>devtmpfs: initialized
>pinctrl core: initialized pinctrl subsystem
>regulator-dummy: no parameters
>NET: Registered protocol family 16
>DMA: preallocated 256 KiB pool for atomic coherent allocations
>Dove 88AP510 SoC
>Tauros2: Disabling L2 prefetch.
>Tauros2: Disabling line fill burt8.
>Tauros2: Enabling L2 cache.
>Tauros2: L2 cache support initialised in ARMv7 mode.
>bio: create slab <bio-0> at 0
>USB Power: Failed to request enable GPIO1: -517
>reg-fixed-voltage 1.regulator: Failed to register regulator: -517
>platform 1.regulator: Driver reg-fixed-voltage requests probe deferral
>SCSI subsystem initialized
>libata version 3.00 loaded.
>usbcore: registered new interface driver usbfs
>usbcore: registered new interface driver hub
>usbcore: registered new device driver usb
>Linux video capture interface: v2.00
>Advanced Linux Sound Architecture Driver Initialized.
>Switched to clocksource orion_clocksource
>NET: Registered protocol family 2
>TCP established hash table entries: 8192 (order: 4, 65536 bytes)
>TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
>TCP: Hash tables configured (established 8192 bind 8192)
>TCP: reno registered
>UDP hash table entries: 512 (order: 1, 8192 bytes)
>UDP-Lite hash table entries: 512 (order: 1, 8192 bytes)
>NET: Registered protocol family 1
>audit: initializing netlink socket (disabled)
>type=2000 audit(0.070:1): initialized
>msgmni has been set to 2020
>io scheduler noop registered
>io scheduler deadline registered
>io scheduler cfq registered (default)
>dove-pinctrl f10d0200.pinctrl: registered pinctrl driver
>mv_xor f1060800.dma-engine: Marvell shared XOR driver
>mv_xor f1060800.dma-engine: Marvell XOR: ( xor cpy )
>mv_xor f1060800.dma-engine: Marvell XOR: ( xor cpy )
>mv_xor f1060900.dma-engine: Marvell shared XOR driver
>mv_xor f1060900.dma-engine: Marvell XOR: ( xor cpy )
>mv_xor f1060900.dma-engine: Marvell XOR: ( xor cpy )
>Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled
>f1012000.serial: ttyS0 at MMIO 0xf1012000 (irq = 7) is a 16550A
>console [ttyS0] enabled
>brd: module loaded
>sata_mv f10a0000.sata: version 1.28
>sata_mv f10a0000.sata: slots 32 ports 1
>scsi0 : sata_mv
>ata1: SATA max UDMA/133 irq 62
>libphy: orion_mdio_bus: probed
>mv643xx_eth: MV-643xx 10/100/1000 ethernet driver version 1.4
>libphy: PHY orion-mdio-mii:08 not found
>libphy: PHY orion-mdio-mii:09 not found
>libphy: PHY orion-mdio-mii:0a not found
>libphy: PHY orion-mdio-mii:0b not found
>libphy: PHY orion-mdio-mii:0c not found
>libphy: PHY orion-mdio-mii:0d not found
>libphy: PHY orion-mdio-mii:0e not found
>libphy: PHY orion-mdio-mii:0f not found
>libphy: PHY orion-mdio-mii:10 not found
>libphy: PHY orion-mdio-mii:11 not found
>libphy: PHY orion-mdio-mii:12 not found
>libphy: PHY orion-mdio-mii:13 not found
>libphy: PHY orion-mdio-mii:14 not found
>libphy: PHY orion-mdio-mii:15 not found
>libphy: PHY orion-mdio-mii:16 not found
>libphy: PHY orion-mdio-mii:17 not found
>libphy: PHY orion-mdio-mii:18 not found
>libphy: PHY orion-mdio-mii:19 not found
>libphy: PHY orion-mdio-mii:1a not found
>libphy: PHY orion-mdio-mii:1b not found
>libphy: PHY orion-mdio-mii:1c not found
>libphy: PHY orion-mdio-mii:1d not found
>libphy: PHY orion-mdio-mii:1e not found
>libphy: PHY orion-mdio-mii:1f not found
>libphy: PHY orion-mdio-mii:00 not found
>mv643xx_eth_port mv643xx_eth_port.0 eth0: port 0 with MAC address 00:50:43:b6:3b:10
>ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
>ehci-orion: EHCI orion driver
>orion-ehci f1050000.usb-host: EHCI Host Controller
>orion-ehci f1050000.usb-host: new USB bus registered, assigned bus number 1
>orion-ehci f1050000.usb-host: irq 24, io mem 0xf1050000
>orion-ehci f1050000.usb-host: USB 2.0 started, EHCI 1.00
>hub 1-0:1.0: USB hub found
>hub 1-0:1.0: 1 port detected
>orion-ehci f1051000.usb-host: EHCI Host Controller
>orion-ehci f1051000.usb-host: new USB bus registered, assigned bus number 2
>orion-ehci f1051000.usb-host: irq 25, io mem 0xf1051000
>orion-ehci f1051000.usb-host: USB 2.0 started, EHCI 1.00
>hub 2-0:1.0: USB hub found
>hub 2-0:1.0: 1 port detected
>usbcore: registered new interface driver usb-storage
>mousedev: PS/2 mouse device common for all mice
>rtc-mv f10d8500.rtc: rtc core: registered f10d8500.rtc as rtc0
>sdhci: Secure Digital Host Controller Interface driver
>sdhci: Copyright(c) Pierre Ossman
>sdhci-pltfm: SDHCI platform and OF driver helper
>mmc0: no vqmmc regulator found
>mmc0: no vmmc regulator found
>mmc0: SDHCI controller on f1092000.sdio [f1092000.sdio] using DMA
>usbcore: registered new interface driver usbhid
>usbhid: USB HID core driver
>TCP: cubic registered
>NET: Registered protocol family 10
>NET: Registered protocol family 17
>VFP support v0.3: implementor 56 architecture 2 part 20 variant 9 rev 5
>ThumbEE CPU extension supported.
>PJ4 iWMMXt coprocessor enabled.
>USB Power: 5000 mV 
>rtc-mv f10d8500.rtc: setting system clock to 2013-07-31 08:15:22 UTC (1375258522)
>ALSA device list:
>  No soundcards found.
>ata1: SATA link down (SStatus 0 SControl F300)
>mmc0: new high speed SDHC card at address e624
>mmcblk0: mmc0:e624 SU16G 14.8 GiB 
> mmcblk0: p1 p2 p3
>Waiting for root device /dev/sda7...
>usb 1-1: new high-speed USB device number 2 using orion-ehci
>usb-storage 1-1:1.0: USB Mass Storage device detected
>scsi1 : usb-storage 1-1:1.0
>usb 2-1: new high-speed USB device number 2 using orion-ehci
>hub 2-1:1.0: USB hub found
>hub 2-1:1.0: 4 ports detected
>usb 2-1.4: new high-speed USB device number 3 using orion-ehci
>hub 2-1.4:1.0: USB hub found
>hub 2-1.4:1.0: 4 ports detected
>usb 2-1.4.2: new high-speed USB device number 4 using orion-ehci
>scsi 1:0:0:0: Direct-Access     WDC WD25 00JB-55REA0      20.0 PQ: 0 ANSI: 0
>sd 1:0:0:0: [sda] 488397168 512-byte logical blocks: (250 GB/232 GiB)
>sd 1:0:0:0: [sda] Write Protect is off
>sd 1:0:0:0: [sda] Mode Sense: 03 00 00 00
>sd 1:0:0:0: [sda] No Caching mode page present
>sd 1:0:0:0: [sda] Assuming drive cache: write through
>sd 1:0:0:0: [sda] No Caching mode page present
>sd 1:0:0:0: [sda] Assuming drive cache: write through
> sda: sda1 sda2 sda3 sda4 < sda5 sda6 sda7 >
>sd 1:0:0:0: [sda] No Caching mode page present
>sd 1:0:0:0: [sda] Assuming drive cache: write through
>sd 1:0:0:0: [sda] Attached SCSI disk
>EXT3-fs (sda7): mounted filesystem with ordered data mode
>kjournald starting.  Commit interval 5 seconds
>usb 2-1.4.3: new low-speed USB device number 5 using orion-ehci
>VFS: Mounted root (ext3 filesystem) readonly on device 8:7.
>devtmpfs: mounted
>Freeing unused kernel memory: 132K (8049e000 - 804bf000)
>input: Generic USB K/B as /devices/soc.0/f1051000.usb-host/usb2/2-1/2-1.4/2-1.4.3/2-1.4.3:1.0/input/input0
>hid-generic 0003:13BA:0017.0001: input: USB HID v1.10 Keyboard [Generic USB K/B] on usb-f1051000.usb-host-1.4.3/input0
>input: Generic USB K/B as /devices/soc.0/f1051000.usb-host/usb2/2-1/2-1.4/2-1.4.3/2-1.4.3:1.1/input/input1
>hid-generic 0003:13BA:0017.0002: input: USB HID v1.10 Mouse [Generic USB K/B] on usb-f1051000.usb-host-1.4.3/input1
>udevd[583]: starting version 175
>[drm] Initialized drm 1.1.0 20060810
>cfg80211: Calling CRDA to update world regulatory domain
>simple-dt-audio sound.5:  dit-hifi <-> f10b4000.audio-controller mapping ok
>tda998x 0-0070: found TDA19988
>[drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
>[drm] No driver support for vblank timestamp query.
>usb 2-1.4.2: reset high-speed USB device number 4 using orion-ehci
>usb 2-1.4.2: Loading firmware file isl3887usb
>usbcore: registered new interface driver p54usb
>ieee80211 phy0: p54 detected a LM87 firmware
>p54: rx_mtu reduced from 3240 to 2384
>ieee80211 phy0: FW rev 2.13.25.0 - Softmac protocol 5.9
>ieee80211 phy0: cryptographic accelerator WEP:YES, TKIP:YES, CCMP:YES
>Console: switching to colour frame buffer device 240x67
>dove-drm video.6: fb0:  frame buffer device
>dove-drm video.6: registered panic notifier
>[drm] Initialized dove-drm 1.0.0 20130516 on minor 0
>ieee80211 phy0: hwaddr 00:12:bf:1e:9c:e4, MAC:isl3887 RF:Frisbee
>ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
>usb 2-1.4.2: is registered as 'phy0'
>Unable to handle kernel NULL pointer dereference at virtual address 00000003
>pgd = bd374000
>[00000003] *pgd=3d3af831, *pte=00000000, *ppte=00000000
>Internal error: Oops: 811 [#1] PREEMPT ARM
>Modules linked in: arc4 p54usb p54common crc_ccitt fbcon bitblit mac80211 softcursor font cfg80211 dove_drm tda998x drm_kms_helper drm clk_si5351 snd_soc_simple_dt_card snd_soc_spdif_tx mv_cesa snd_soc_kirkwood
>CPU: 0 PID: 731 Comm: usb-db Not tainted 3.11.0-rc3-00004-g36f571e-dirty #1
>task: bda0dc00 ti: bd2fa000 task.ti: bd2fa000
>PC is at do_mpage_readpage+0x754/0x888
>LR is at bio_add_page+0x44/0x4c
>pc : [<800e89c0>]    lr : [<800e05e4>]    psr: 600e0013
>sp : bd2fbc74  ip : bd2fbcc8  fp : bd2fbc9c
>r10: 00000003  r9 : 00000000  r8 : 00000004
>r7 : 00000001  r6 : 800e8ca4  r5 : bd2fbc70  r4 : 00000003
>r3 : 00001000  r2 : 00000003  r1 : 00000000  r0 : bd2fbc9c
>Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
>Control: 10c5387d  Table: 3d374019  DAC: 00000015
>Process usb-db (pid: 731, stack limit = 0xbd2fa240)
>Stack: (0xbd2fbc74 to 0xbd2fc000)
>bc60:                                              00000001 bd2fbd64 00200200
>bc80: 00100100 bd53cd54 bd9f1340 80eed380 bd2fbd34 bd2fbca0 800e8bc8 800e8278
>bca0: bd2fbcc8 bd2fbcbc 8011c554 000000c1 804ebd2c 8011c554 00000002 00000003
>bcc0: 0028de87 00000000 00000000 bd2fbcd8 80eed380 803a2f54 0028df40 00000000
>bce0: 00001000 00000000 bd402ac0 8003b810 bd2fbcf0 bd2fbcf0 bd53ccb4 bd2fbd7c
>bd00: bd53ccbc 00000002 bd2fbd24 8011a00c 00000004 00000004 00000000 0000007a
>bd20: 00000000 00000004 bd2fbd44 bd2fbd38 8011a030 800e8b00 bd2fbdac bd2fbd48
>bd40: 8007dd28 8011a018 bda54780 00000001 bd53cd54 00000004 bd53cd58 bd2fbd64
>bd60: 800c23bc bd2fbd64 bd2fbd64 91827364 bd8d5de8 bd8d5de8 bd2fbd78 bd2fbd78
>bd80: 800add50 bd53cd54 bda54780 bda547c8 00000000 00000020 00000003 bd53cd54
>bda0: bd2fbdec bd2fbdb0 8007e0e0 8007db44 00000003 bd11e470 bd95462c bdbe1540
>bdc0: bd2fbddc bd53cd54 00000000 00000000 bd53cc98 00000001 00000000 bda54780
>bde0: bd2fbe0c bd2fbdf0 8007e3b8 8007dfc4 00000000 00000001 00000000 bd53cd54
>be00: bd2fbeac bd2fbe10 8007471c 8007e378 00000001 bd954b78 bd9545f8 bd9545f8
>be20: 76f24000 76f25000 00000001 00080001 bd2fbeb8 bd2fbec0 ffffffff 00000000
>be40: 00000000 bdbe1540 00000001 bd954608 00000001 00000fff bd2fa000 bda547c8
>be60: 00000000 00000001 76f25000 00000000 00000000 00001000 76f24000 00000000
>be80: 80097780 00000000 00000000 00001000 bd2fbf78 bda54780 bda0dc00 00020000
>bea0: bd2fbf44 bd2fbeb0 800abf60 800741cc 00000000 00000000 76f24000 00001000
>bec0: 00000001 bda54780 00000000 00000000 00000000 bda0dc00 00000000 00000000
>bee0: 00000000 00000000 00000000 00000000 00001000 00000000 00001000 00000000
>bf00: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
>bf20: bda54780 76f24000 bd2fbf78 76f24000 00000000 00001000 bd2fbf74 bd2fbf48
>bf40: 800ac69c 800abeec 00800007 00000022 00000000 00000000 bda54780 76f24000
>bf60: 00000000 00001000 bd2fbfa4 bd2fbf78 800acd84 800ac608 00000000 00000000
>bf80: 017f7278 76ec7c58 00000000 00000003 8000e604 bd2fa000 00000000 bd2fbfa8
>bfa0: 8000e480 800acd4c 017f7278 76ec7c58 00000003 76f24000 00001000 00000000
>bfc0: 017f7278 76ec7c58 00000000 00000003 7eac3ad0 7eac3ad4 76f29000 00000000
>bfe0: 00000000 7eac3a64 76e389cf 76e6f21c 400e0010 00000003 00000000 00000000
>Backtrace: 
>[<800e826c>] (do_mpage_readpage+0x0/0x888) from [<800e8bc8>] (mpage_readpages+0xd4/0x130)
>[<800e8af4>] (mpage_readpages+0x0/0x130) from [<8011a030>] (ext3_readpages+0x24/0x28)
>[<8011a00c>] (ext3_readpages+0x0/0x28) from [<8007dd28>] (__do_page_cache_readahead+0x1f0/0x2d8)
>[<8007db38>] (__do_page_cache_readahead+0x0/0x2d8) from [<8007e0e0>] (ondemand_readahead+0x128/0x238)
>[<8007dfb8>] (ondemand_readahead+0x0/0x238) from [<8007e3b8>] (page_cache_sync_readahead+0x4c/0x6c)
>[<8007e36c>] (page_cache_sync_readahead+0x0/0x6c) from [<8007471c>] (generic_file_aio_read+0x55c/0x7c0)
> r4:bd53cd54
>[<800741c0>] (generic_file_aio_read+0x0/0x7c0) from [<800abf60>] (do_sync_read+0x80/0xa8)
>[<800abee0>] (do_sync_read+0x0/0xa8) from [<800ac69c>] (vfs_read+0xa0/0x148)
> r9:00001000 r8:00000000 r7:76f24000 r6:bd2fbf78 r5:76f24000
>r4:bda54780
>[<800ac5fc>] (vfs_read+0x0/0x148) from [<800acd84>] (SyS_read+0x44/0x80)
> r9:00001000 r8:00000000 r7:76f24000 r6:bda54780 r5:00000000
>r4:00000000
>[<800acd40>] (SyS_read+0x0/0x80) from [<8000e480>] (ret_fast_syscall+0x0/0x30)
> r9:bd2fa000 r8:8000e604 r7:00000003 r6:00000000 r5:76ec7c58
>r4:017f7278
>Code: e0854184 e51b0084 e14424d8 e51b40a0 (e1c420f0) 
>---[ end trace e23d6b4d1dcd7a83 ]---
>------------[ cut here ]------------
>WARNING: CPU: 0 PID: 731 at /home/jef/kernel/kernel/exit.c:703 do_exit+0x54/0x900()
>Modules linked in: arc4 p54usb p54common crc_ccitt fbcon bitblit mac80211 softcursor font cfg80211 dove_drm tda998x drm_kms_helper drm clk_si5351 snd_soc_simple_dt_card snd_soc_spdif_tx mv_cesa snd_soc_kirkwood
>CPU: 0 PID: 731 Comm: usb-db Tainted: G      D      3.11.0-rc3-00004-g36f571e-dirty #1
>Backtrace: 
>[<800112c4>] (dump_backtrace+0x0/0x110) from [<800114dc>] (show_stack+0x18/0x1c)
> r6:000002bf r5:00000009 r4:00000000 r3:00000000
>[<800114c4>] (show_stack+0x0/0x1c) from [<803a25b0>] (dump_stack+0x24/0x28)
>[<803a258c>] (dump_stack+0x0/0x28) from [<8001ad28>] (warn_slowpath_common+0x74/0x8c)
>[<8001acb4>] (warn_slowpath_common+0x0/0x8c) from [<8001ade4>] (warn_slowpath_null+0x24/0x2c)
> r8:00000811 r7:bd2fa000 r6:80439cc4 r5:0000000b r4:804cb598
>[<8001adc0>] (warn_slowpath_null+0x0/0x2c) from [<8001f248>] (do_exit+0x54/0x900)
>[<8001f1f4>] (do_exit+0x0/0x900) from [<80011664>] (die+0x184/0x238)
> r7:bd2fa000
>[<800114e0>] (die+0x0/0x238) from [<803a07dc>] (__do_kernel_fault.part.10+0x6c/0x7c)
>[<803a0770>] (__do_kernel_fault.part.10+0x0/0x7c) from [<8001420c>] (do_sect_fault+0x0/0x18)
> r7:bdbe1540 r3:bd2fbc28
>[<8001417c>] (do_bad_area+0x0/0x90) from [<80015d10>] (do_alignment+0xd0/0x844)
> r7:00000003 r6:800e89c0 r5:804ec85c r4:bd2fbc28
>[<80015c40>] (do_alignment+0x0/0x844) from [<80008460>] (do_DataAbort+0x40/0xa0)
>[<80008420>] (do_DataAbort+0x0/0xa0) from [<80011fb8>] (__dabt_svc+0x38/0x60)
>Exception stack(0xbd2fbc28 to 0xbd2fbc70)
>bc20:                   bd2fbc9c 00000000 00000003 00001000 00000003 bd2fbc70
>bc40: 800e8ca4 00000001 00000004 00000000 00000003 bd2fbc9c bd2fbcc8 bd2fbc74
>bc60: 800e05e4 800e89c0 600e0013 ffffffff
> r8:00000004 r7:bd2fbc5c r6:ffffffff r5:600e0013 r4:800e89c0
>[<800e826c>] (do_mpage_readpage+0x0/0x888) from [<800e8bc8>] (mpage_readpages+0xd4/0x130)
>[<800e8af4>] (mpage_readpages+0x0/0x130) from [<8011a030>] (ext3_readpages+0x24/0x28)
>[<8011a00c>] (ext3_readpages+0x0/0x28) from [<8007dd28>] (__do_page_cache_readahead+0x1f0/0x2d8)
>[<8007db38>] (__do_page_cache_readahead+0x0/0x2d8) from [<8007e0e0>] (ondemand_readahead+0x128/0x238)
>[<8007dfb8>] (ondemand_readahead+0x0/0x238) from [<8007e3b8>] (page_cache_sync_readahead+0x4c/0x6c)
>[<8007e36c>] (page_cache_sync_readahead+0x0/0x6c) from [<8007471c>] (generic_file_aio_read+0x55c/0x7c0)
> r4:bd53cd54
>[<800741c0>] (generic_file_aio_read+0x0/0x7c0) from [<800abf60>] (do_sync_read+0x80/0xa8)
>[<800abee0>] (do_sync_read+0x0/0xa8) from [<800ac69c>] (vfs_read+0xa0/0x148)
> r9:00001000 r8:00000000 r7:76f24000 r6:bd2fbf78 r5:76f24000
>r4:bda54780
>[<800ac5fc>] (vfs_read+0x0/0x148) from [<800acd84>] (SyS_read+0x44/0x80)
> r9:00001000 r8:00000000 r7:76f24000 r6:bda54780 r5:00000000
>r4:00000000
>[<800acd40>] (SyS_read+0x0/0x80) from [<8000e480>] (ret_fast_syscall+0x0/0x30)
> r9:bd2fa000 r8:8000e604 r7:00000003 r6:00000000 r5:76ec7c58
>r4:017f7278
>---[ end trace e23d6b4d1dcd7a84 ]---
>EXT3-fs (sda7): using internal journal
>IPv6: ADDRCONF(NETDEV_UP): wlan1: link is not ready
>wlan1: authenticate with 00:24:d4:9c:29:68
>wlan1: send auth to 00:24:d4:9c:29:68 (try 1/3)
>wlan1: authenticated
>p54usb 2-1.4.2:1.0 wlan1: disabling HT/VHT due to WEP/TKIP use
>wlan1: associate with 00:24:d4:9c:29:68 (try 1/3)
>wlan1: RX AssocResp from 00:24:d4:9c:29:68 (capab=0x411 status=0 aid=1)
>IPv6: ADDRCONF(NETDEV_CHANGE): wlan1: link becomes ready
>wlan1: associated
>
>-- 
>Ken ar c'hentañ	|	      ** Breizh ha Linux atav! **
>Jef		|		http://moinejf.free.fr/
>--
>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/

[PATCH] ARM: Fix r7/r11 confusion when CONFIG_THUMB2_KERNEL=y [OT]

[walimis]

On Wed, Jul 31, 2013 at 11:03:09AM +0200, Jean-Francois Moine wrote:
>On Tue, 30 Jul 2013 10:49:04 +0100
>Will Deacon <will.deacon@arm.com> wrote:
>
>> On Tue, Jul 30, 2013 at 10:38:53AM +0100, Jean-Francois Moine wrote:
>> > BTW, kernels compiled with gcc-4.8 don't work.  
>> 
>> Erm. Can you elaborate please? There was an issue where SLUB would get
>> miscompiled with 4.8 due to some per-cpu variable reordering across
>> barrier(), but I fixed that for ARM in 3.10.
>
>I compiled the 3.11.0-rc3 with gcc-4.8.1 and I still get oops in ext3
>(no problem when compiled with gcc-4.6). Here is the dmesg.
Hi, all

I also encounterd the same problem and I think it's an severe issue for the arm arch.
The issue only exists when building the kernel with gcc 4.8.x and CONFIG_FRAME_POINTER=y

There was also a mail to describe the similar issue:
https://lkml.org/lkml/2013/6/13/529
http://www.spinics.net/lists/linux-ext4/msg38685.html

It can be easyly triggered when doing some ext3/ext4 operation and I got the following
backtrace:

------------[ cut here ]------------
kernel BUG at linux/fs/buffer.c:2958!
Internal error: Oops - BUG: 0 [#3] PREEMPT SMP ARM
Modules linked in: tun ext4 crc16 jbd2 loop
CPU: 0 PID: 707 Comm: dd Tainted: G      D      3.10.19-WR6.0.0.0_standard #1
task: dcf78900 ti: d7968000 task.ti: d7968000
PC is at _submit_bh+0x3c/0x24c
LR is at submit_bh+0x1c/0x20
pc : [<c013e4c4>]    lr : [<c013e6f0>]    psr: 60000013
sp : d7969b20  ip : d7969b48  fp : d7969b44
r10: ddf7ec68  r9 : 00000000  r8 : ddd24600
r7 : 00000000  r6 : 00000060  r5 : 00000000  r4 : 00020041
r3 : 00700004  r2 : 00000000  r1 : ddd24600  r0 : 00000060
Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
Control: 30c5387d  Table: 18dbae40  DAC: fffffffd
Process dd (pid: 707, stack limit = 0xd7968238)
Stack: (0xd7969b20 to 0xd796a000)
9b20: 00020041 00000000 00020042 00000000 ddd24600 dcd99400 d7969b54 d7969b48
9b40: c013e6f0 c013e494 d7969bbc d7969b58 bf0391fc c013e6e0 00000400 c0596f48
9b60: ddf7ec60 ddf7ec60 00000000 00020021 00020041 00000000 00020021 00000000
9b80: 00020023 00000000 ffff0000 d7969bfc d7969bac d7969bfc d4e8b980 ddf7ec68
9ba0: d4e8b980 bf040128 ddf7ed44 d7968028 d7969bcc d7969bc0 bf03ae98 bf039054
9bc0: d7969bec d7969bd0 bf03cb3c bf03ae80 ddf7ec68 d4e8b980 dcd98400 c08c8b60
9be0: d7969c2c d7969bf0 bf03cc64 bf03cb1c bf060f7c bf0086c8 000013d3 00000000
9c00: 00000180 00000010 ddf7ec68 d4e8b980 ddf7ec68 c08c8b60 dcd99400 ddf7ed44
9c20: d7969c44 d7969c30 bf040128 bf03cba4 ddf7ec68 00000007 d7969c6c d7969c48
9c40: c0135c08 bf0400f4 00000001 00000000 ddf7ec68 c0a83e00 00000400 ddf7ed44
9c60: d7969ca4 d7969c70 c013d610 c0135b44 00000400 00000400 c0a83e00 00000000
9c80: 00000000 ddf7ec68 00000400 c0a83e00 00000000 d4e8b980 d7969cfc d7969ca8
9ca0: bf03f2f0 c013d53c 00000400 00000400 c0a83e00 00000000 d7968020 de17fc00
9cc0: 03550000 00000000 0354fc00 00000000 d7969cfc 00000000 ddf7ed44 00000400
9ce0: 00000000 de17fc00 bf0781c8 00000400 d7969d6c d7969d00 c00c802c bf03f0d4
9d00: 00000400 00000400 c0a83e00 00000000 00000000 d7968000 00000400 00000c00
9d20: 0354fc00 00000000 c0a83e00 00000000 d7969eb8 00000001 00000000 00000400
9d40: 5292f392 0354fc00 00000000 00000400 d7969eb8 00000000 00000000 de17fc00
9d60: d7969ddc d7969d70 c00c92dc c00c7ec8 0354fc00 00000000 d7969ee0 00000400
9d80: 00000000 d7968000 d7969e14 00000000 c0594e28 c00ac43c ddf7ed44 d7969ee0
9da0: d7969ec0 00000001 0353bc00 00000400 d7969eb8 0354fc00 00000000 d7969eb8
9dc0: ddf7ece0 de17fc00 d7969ec0 00000001 d7969e14 d7969de0 c00c9390 c00c8f84
9de0: 00000400 00000000 c0092dac 0354fc00 00000000 00000001 de17fc00 de17fc00
9e00: d7969ec0 00000000 d7969eac d7969e18 bf0353bc c00c9334 0354fc00 00000000
9e20: d7968000 00000002 d7969e54 d7969e38 c0597018 c00ac708 00000000 d7968000
9e40: 60000013 d7969eb8 c0047f00 60000013 ffffffff d7969ea4 c0594e24 d7968000
9e60: d7969edc c0047e9c c0594e28 00000001 d7968018 c03074a0 c0d98448 00000000
9e80: 00000001 0354fc00 00000000 00000400 d7969f78 de17fc00 00000400 00000000
9ea0: d7969f44 d7969eb0 c0110434 bf03505c 0354fc00 00000000 0001f000 00000400
9ec0: 00000001 de17fc00 00000000 00000000 00000000 dcf78900 00000000 00000000
9ee0: 0354fc00 00000000 00000000 00000000 00000400 00000000 00000400 00000000
9f00: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
9f20: de17fc00 de17fc00 0001f000 d7969f78 00000400 0001f000 d7969f74 d7969f48
9f40: c0110ba4 c01103bc 00000000 00000000 0354fc00 00000000 de17fc00 00000000
9f60: 0001f000 00000400 d7969fa4 d7969f78 c01110b8 c0110acc 0354fc00 00000000
9f80: 00000000 0001d2e8 00000400 00000004 c000dd68 d7968000 00000000 d7969fa8
9fa0: c000dae0 c0111078 00000000 0001d2e8 00000001 0001f000 00000400 00000000
9fc0: 00000000 0001d2e8 00000400 00000004 00000000 0001f400 00000001 00000000
9fe0: 00000000 bed83a9c 0000ca6c 4f7fa426 40000030 00000001 00000000 00000000
[<c013e4c4>] (_submit_bh+0x3c/0x24c) from [<c013e6f0>] (submit_bh+0x1c/0x20)
[<c013e6f0>] (submit_bh+0x1c/0x20) from [<bf0391fc>] (__ext4_get_inode_loc+0x1b4/0x48c [ext4])
[<bf0391fc>] (__ext4_get_inode_loc+0x1b4/0x48c [ext4]) from [<bf03ae98>] (ext4_get_inode_loc+0x24/0x28 [ext4])
[<bf03ae98>] (ext4_get_inode_loc+0x24/0x28 [ext4]) from [<bf03cb3c>] (ext4_reserve_inode_write+0x2c/0x88 [ext4])
[<bf03cb3c>] (ext4_reserve_inode_write+0x2c/0x88 [ext4]) from [<bf03cc64>] (ext4_mark_inode_dirty+0xcc/0x224 [ext4])
[<bf03cc64>] (ext4_mark_inode_dirty+0xcc/0x224 [ext4]) from [<bf040128>] (ext4_dirty_inode+0x40/0x58 [ext4])
[<bf040128>] (ext4_dirty_inode+0x40/0x58 [ext4]) from [<c0135c08>] (__mark_inode_dirty+0xd0/0x2f0)
[<c0135c08>] (__mark_inode_dirty+0xd0/0x2f0) from [<c013d610>] (generic_write_end+0xe0/0xec)
[<c013d610>] (generic_write_end+0xe0/0xec) from [<bf03f2f0>] (ext4_da_write_end+0x228/0x26c [ext4])
[<bf03f2f0>] (ext4_da_write_end+0x228/0x26c [ext4]) from [<c00c802c>] (generic_file_buffered_write+0x170/0x240)
[<c00c802c>] (generic_file_buffered_write+0x170/0x240) from [<c00c92dc>] (__generic_file_aio_write+0x364/0x3b0)
[<c00c92dc>] (__generic_file_aio_write+0x364/0x3b0) from [<c00c9390>] (generic_file_aio_write+0x68/0xc8)
[<c00c9390>] (generic_file_aio_write+0x68/0xc8) from [<bf0353bc>] (ext4_file_write+0x36c/0x454 [ext4])
[<bf0353bc>] (ext4_file_write+0x36c/0x454 [ext4]) from [<c0110434>] (do_sync_write+0x84/0xa8)
[<c0110434>] (do_sync_write+0x84/0xa8) from [<c0110ba4>] (vfs_write+0xe4/0x194)
[<c0110ba4>] (vfs_write+0xe4/0x194) from [<c01110b8>] (SyS_write+0x4c/0x7c)
[<c01110b8>] (SyS_write+0x4c/0x7c) from [<c000dae0>] (ret_fast_syscall+0x0/0x48)
Code: e7f001f2 e5913000 e3130020 1a000000 (e7f001f2) 
---[ end trace 9b74153243e868ff ]---


The BUG() is called in fs/buffer.c:
int _submit_bh(int rw, struct buffer_head *bh, unsigned long bio_flags)
{
...
        BUG_ON(!buffer_mapped(bh));
...
}

Has anyone resolved the problem? 

Best Regard.
walimis

>
>Booting Linux on physical CPU 0x0
>Linux version 3.11.0-rc3-00004-g36f571e-dirty (jef at armhf) (gcc version 4.8.1 (Debian 4.8.1-8) ) #1 PREEMPT Wed Jul 31 09:22:30 CEST 2013
>CPU: ARMv7 Processor [560f5815] revision 5 (ARMv7), cr=10c53c7d
>CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
>Machine: Marvell Dove (Flattened Device Tree), model: SolidRun CuBox
>cma: CMA: reserved 32 MiB at 3e000000
>Memory policy: ECC disabled, Data cache writeback
>On node 0 totalpages: 262144
>free_area_init_node: node 0, pgdat 804ebd2c, node_mem_map 8075b000
>  Normal zone: 2048 pages used for memmap
>  Normal zone: 0 pages reserved
>  Normal zone: 262144 pages, LIFO batch:31
>CPU: All CPU(s) started in SVC mode.
>pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
>pcpu-alloc: [0] 0 
>Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 260096
>Kernel command line: console=ttyS0,115200n8 console=tty1,115200 root=/dev/sda7 rootwait video=HDMI-A-1:1920x1080-32 at 60
>PID hash table entries: 4096 (order: 2, 16384 bytes)
>Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
>Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
>Memory: 1001516K/1048576K available (3715K kernel code, 177K rwdata, 980K rodata, 135K init, 129K bss, 47060K reserved)
>Virtual kernel memory layout:
>    vector  : 0xffff0000 - 0xffff1000   (   4 kB)
>    fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
>    vmalloc : 0xc0800000 - 0xff000000   (1000 MB)
>    lowmem  : 0x80000000 - 0xc0000000   (1024 MB)
>    modules : 0x7f000000 - 0x80000000   (  16 MB)
>      .text : 0x80008000 - 0x8049df34   (4696 kB)
>      .init : 0x8049e000 - 0x804bfe68   ( 136 kB)
>      .data : 0x804c0000 - 0x804ec5c0   ( 178 kB)
>       .bss : 0x804ec5c0 - 0x8050cad0   ( 130 kB)
>Preemptible hierarchical RCU implementation.
>	Dump stacks of tasks blocking RCU-preempt GP.
>NR_IRQS:135
>sched_clock: 32 bits at 166MHz, resolution 5ns, wraps every 25769ms
>Console: colour dummy device 80x30
>console [tty1] enabled
>Calibrating delay loop... 789.70 BogoMIPS (lpj=3948544)
>pid_max: default: 32768 minimum: 301
>Mount-cache hash table entries: 512
>CPU: Testing write buffer coherency: ok
>Setting up static identity map for 0x803a6620 - 0x803a6654
>devtmpfs: initialized
>pinctrl core: initialized pinctrl subsystem
>regulator-dummy: no parameters
>NET: Registered protocol family 16
>DMA: preallocated 256 KiB pool for atomic coherent allocations
>Dove 88AP510 SoC
>Tauros2: Disabling L2 prefetch.
>Tauros2: Disabling line fill burt8.
>Tauros2: Enabling L2 cache.
>Tauros2: L2 cache support initialised in ARMv7 mode.
>bio: create slab <bio-0> at 0
>USB Power: Failed to request enable GPIO1: -517
>reg-fixed-voltage 1.regulator: Failed to register regulator: -517
>platform 1.regulator: Driver reg-fixed-voltage requests probe deferral
>SCSI subsystem initialized
>libata version 3.00 loaded.
>usbcore: registered new interface driver usbfs
>usbcore: registered new interface driver hub
>usbcore: registered new device driver usb
>Linux video capture interface: v2.00
>Advanced Linux Sound Architecture Driver Initialized.
>Switched to clocksource orion_clocksource
>NET: Registered protocol family 2
>TCP established hash table entries: 8192 (order: 4, 65536 bytes)
>TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
>TCP: Hash tables configured (established 8192 bind 8192)
>TCP: reno registered
>UDP hash table entries: 512 (order: 1, 8192 bytes)
>UDP-Lite hash table entries: 512 (order: 1, 8192 bytes)
>NET: Registered protocol family 1
>audit: initializing netlink socket (disabled)
>type=2000 audit(0.070:1): initialized
>msgmni has been set to 2020
>io scheduler noop registered
>io scheduler deadline registered
>io scheduler cfq registered (default)
>dove-pinctrl f10d0200.pinctrl: registered pinctrl driver
>mv_xor f1060800.dma-engine: Marvell shared XOR driver
>mv_xor f1060800.dma-engine: Marvell XOR: ( xor cpy )
>mv_xor f1060800.dma-engine: Marvell XOR: ( xor cpy )
>mv_xor f1060900.dma-engine: Marvell shared XOR driver
>mv_xor f1060900.dma-engine: Marvell XOR: ( xor cpy )
>mv_xor f1060900.dma-engine: Marvell XOR: ( xor cpy )
>Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled
>f1012000.serial: ttyS0 at MMIO 0xf1012000 (irq = 7) is a 16550A
>console [ttyS0] enabled
>brd: module loaded
>sata_mv f10a0000.sata: version 1.28
>sata_mv f10a0000.sata: slots 32 ports 1
>scsi0 : sata_mv
>ata1: SATA max UDMA/133 irq 62
>libphy: orion_mdio_bus: probed
>mv643xx_eth: MV-643xx 10/100/1000 ethernet driver version 1.4
>libphy: PHY orion-mdio-mii:08 not found
>libphy: PHY orion-mdio-mii:09 not found
>libphy: PHY orion-mdio-mii:0a not found
>libphy: PHY orion-mdio-mii:0b not found
>libphy: PHY orion-mdio-mii:0c not found
>libphy: PHY orion-mdio-mii:0d not found
>libphy: PHY orion-mdio-mii:0e not found
>libphy: PHY orion-mdio-mii:0f not found
>libphy: PHY orion-mdio-mii:10 not found
>libphy: PHY orion-mdio-mii:11 not found
>libphy: PHY orion-mdio-mii:12 not found
>libphy: PHY orion-mdio-mii:13 not found
>libphy: PHY orion-mdio-mii:14 not found
>libphy: PHY orion-mdio-mii:15 not found
>libphy: PHY orion-mdio-mii:16 not found
>libphy: PHY orion-mdio-mii:17 not found
>libphy: PHY orion-mdio-mii:18 not found
>libphy: PHY orion-mdio-mii:19 not found
>libphy: PHY orion-mdio-mii:1a not found
>libphy: PHY orion-mdio-mii:1b not found
>libphy: PHY orion-mdio-mii:1c not found
>libphy: PHY orion-mdio-mii:1d not found
>libphy: PHY orion-mdio-mii:1e not found
>libphy: PHY orion-mdio-mii:1f not found
>libphy: PHY orion-mdio-mii:00 not found
>mv643xx_eth_port mv643xx_eth_port.0 eth0: port 0 with MAC address 00:50:43:b6:3b:10
>ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
>ehci-orion: EHCI orion driver
>orion-ehci f1050000.usb-host: EHCI Host Controller
>orion-ehci f1050000.usb-host: new USB bus registered, assigned bus number 1
>orion-ehci f1050000.usb-host: irq 24, io mem 0xf1050000
>orion-ehci f1050000.usb-host: USB 2.0 started, EHCI 1.00
>hub 1-0:1.0: USB hub found
>hub 1-0:1.0: 1 port detected
>orion-ehci f1051000.usb-host: EHCI Host Controller
>orion-ehci f1051000.usb-host: new USB bus registered, assigned bus number 2
>orion-ehci f1051000.usb-host: irq 25, io mem 0xf1051000
>orion-ehci f1051000.usb-host: USB 2.0 started, EHCI 1.00
>hub 2-0:1.0: USB hub found
>hub 2-0:1.0: 1 port detected
>usbcore: registered new interface driver usb-storage
>mousedev: PS/2 mouse device common for all mice
>rtc-mv f10d8500.rtc: rtc core: registered f10d8500.rtc as rtc0
>sdhci: Secure Digital Host Controller Interface driver
>sdhci: Copyright(c) Pierre Ossman
>sdhci-pltfm: SDHCI platform and OF driver helper
>mmc0: no vqmmc regulator found
>mmc0: no vmmc regulator found
>mmc0: SDHCI controller on f1092000.sdio [f1092000.sdio] using DMA
>usbcore: registered new interface driver usbhid
>usbhid: USB HID core driver
>TCP: cubic registered
>NET: Registered protocol family 10
>NET: Registered protocol family 17
>VFP support v0.3: implementor 56 architecture 2 part 20 variant 9 rev 5
>ThumbEE CPU extension supported.
>PJ4 iWMMXt coprocessor enabled.
>USB Power: 5000 mV 
>rtc-mv f10d8500.rtc: setting system clock to 2013-07-31 08:15:22 UTC (1375258522)
>ALSA device list:
>  No soundcards found.
>ata1: SATA link down (SStatus 0 SControl F300)
>mmc0: new high speed SDHC card at address e624
>mmcblk0: mmc0:e624 SU16G 14.8 GiB 
> mmcblk0: p1 p2 p3
>Waiting for root device /dev/sda7...
>usb 1-1: new high-speed USB device number 2 using orion-ehci
>usb-storage 1-1:1.0: USB Mass Storage device detected
>scsi1 : usb-storage 1-1:1.0
>usb 2-1: new high-speed USB device number 2 using orion-ehci
>hub 2-1:1.0: USB hub found
>hub 2-1:1.0: 4 ports detected
>usb 2-1.4: new high-speed USB device number 3 using orion-ehci
>hub 2-1.4:1.0: USB hub found
>hub 2-1.4:1.0: 4 ports detected
>usb 2-1.4.2: new high-speed USB device number 4 using orion-ehci
>scsi 1:0:0:0: Direct-Access     WDC WD25 00JB-55REA0      20.0 PQ: 0 ANSI: 0
>sd 1:0:0:0: [sda] 488397168 512-byte logical blocks: (250 GB/232 GiB)
>sd 1:0:0:0: [sda] Write Protect is off
>sd 1:0:0:0: [sda] Mode Sense: 03 00 00 00
>sd 1:0:0:0: [sda] No Caching mode page present
>sd 1:0:0:0: [sda] Assuming drive cache: write through
>sd 1:0:0:0: [sda] No Caching mode page present
>sd 1:0:0:0: [sda] Assuming drive cache: write through
> sda: sda1 sda2 sda3 sda4 < sda5 sda6 sda7 >
>sd 1:0:0:0: [sda] No Caching mode page present
>sd 1:0:0:0: [sda] Assuming drive cache: write through
>sd 1:0:0:0: [sda] Attached SCSI disk
>EXT3-fs (sda7): mounted filesystem with ordered data mode
>kjournald starting.  Commit interval 5 seconds
>usb 2-1.4.3: new low-speed USB device number 5 using orion-ehci
>VFS: Mounted root (ext3 filesystem) readonly on device 8:7.
>devtmpfs: mounted
>Freeing unused kernel memory: 132K (8049e000 - 804bf000)
>input: Generic USB K/B as /devices/soc.0/f1051000.usb-host/usb2/2-1/2-1.4/2-1.4.3/2-1.4.3:1.0/input/input0
>hid-generic 0003:13BA:0017.0001: input: USB HID v1.10 Keyboard [Generic USB K/B] on usb-f1051000.usb-host-1.4.3/input0
>input: Generic USB K/B as /devices/soc.0/f1051000.usb-host/usb2/2-1/2-1.4/2-1.4.3/2-1.4.3:1.1/input/input1
>hid-generic 0003:13BA:0017.0002: input: USB HID v1.10 Mouse [Generic USB K/B] on usb-f1051000.usb-host-1.4.3/input1
>udevd[583]: starting version 175
>[drm] Initialized drm 1.1.0 20060810
>cfg80211: Calling CRDA to update world regulatory domain
>simple-dt-audio sound.5:  dit-hifi <-> f10b4000.audio-controller mapping ok
>tda998x 0-0070: found TDA19988
>[drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
>[drm] No driver support for vblank timestamp query.
>usb 2-1.4.2: reset high-speed USB device number 4 using orion-ehci
>usb 2-1.4.2: Loading firmware file isl3887usb
>usbcore: registered new interface driver p54usb
>ieee80211 phy0: p54 detected a LM87 firmware
>p54: rx_mtu reduced from 3240 to 2384
>ieee80211 phy0: FW rev 2.13.25.0 - Softmac protocol 5.9
>ieee80211 phy0: cryptographic accelerator WEP:YES, TKIP:YES, CCMP:YES
>Console: switching to colour frame buffer device 240x67
>dove-drm video.6: fb0:  frame buffer device
>dove-drm video.6: registered panic notifier
>[drm] Initialized dove-drm 1.0.0 20130516 on minor 0
>ieee80211 phy0: hwaddr 00:12:bf:1e:9c:e4, MAC:isl3887 RF:Frisbee
>ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
>usb 2-1.4.2: is registered as 'phy0'
>Unable to handle kernel NULL pointer dereference at virtual address 00000003
>pgd = bd374000
>[00000003] *pgd=3d3af831, *pte=00000000, *ppte=00000000
>Internal error: Oops: 811 [#1] PREEMPT ARM
>Modules linked in: arc4 p54usb p54common crc_ccitt fbcon bitblit mac80211 softcursor font cfg80211 dove_drm tda998x drm_kms_helper drm clk_si5351 snd_soc_simple_dt_card snd_soc_spdif_tx mv_cesa snd_soc_kirkwood
>CPU: 0 PID: 731 Comm: usb-db Not tainted 3.11.0-rc3-00004-g36f571e-dirty #1
>task: bda0dc00 ti: bd2fa000 task.ti: bd2fa000
>PC is at do_mpage_readpage+0x754/0x888
>LR is at bio_add_page+0x44/0x4c
>pc : [<800e89c0>]    lr : [<800e05e4>]    psr: 600e0013
>sp : bd2fbc74  ip : bd2fbcc8  fp : bd2fbc9c
>r10: 00000003  r9 : 00000000  r8 : 00000004
>r7 : 00000001  r6 : 800e8ca4  r5 : bd2fbc70  r4 : 00000003
>r3 : 00001000  r2 : 00000003  r1 : 00000000  r0 : bd2fbc9c
>Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
>Control: 10c5387d  Table: 3d374019  DAC: 00000015
>Process usb-db (pid: 731, stack limit = 0xbd2fa240)
>Stack: (0xbd2fbc74 to 0xbd2fc000)
>bc60:                                              00000001 bd2fbd64 00200200
>bc80: 00100100 bd53cd54 bd9f1340 80eed380 bd2fbd34 bd2fbca0 800e8bc8 800e8278
>bca0: bd2fbcc8 bd2fbcbc 8011c554 000000c1 804ebd2c 8011c554 00000002 00000003
>bcc0: 0028de87 00000000 00000000 bd2fbcd8 80eed380 803a2f54 0028df40 00000000
>bce0: 00001000 00000000 bd402ac0 8003b810 bd2fbcf0 bd2fbcf0 bd53ccb4 bd2fbd7c
>bd00: bd53ccbc 00000002 bd2fbd24 8011a00c 00000004 00000004 00000000 0000007a
>bd20: 00000000 00000004 bd2fbd44 bd2fbd38 8011a030 800e8b00 bd2fbdac bd2fbd48
>bd40: 8007dd28 8011a018 bda54780 00000001 bd53cd54 00000004 bd53cd58 bd2fbd64
>bd60: 800c23bc bd2fbd64 bd2fbd64 91827364 bd8d5de8 bd8d5de8 bd2fbd78 bd2fbd78
>bd80: 800add50 bd53cd54 bda54780 bda547c8 00000000 00000020 00000003 bd53cd54
>bda0: bd2fbdec bd2fbdb0 8007e0e0 8007db44 00000003 bd11e470 bd95462c bdbe1540
>bdc0: bd2fbddc bd53cd54 00000000 00000000 bd53cc98 00000001 00000000 bda54780
>bde0: bd2fbe0c bd2fbdf0 8007e3b8 8007dfc4 00000000 00000001 00000000 bd53cd54
>be00: bd2fbeac bd2fbe10 8007471c 8007e378 00000001 bd954b78 bd9545f8 bd9545f8
>be20: 76f24000 76f25000 00000001 00080001 bd2fbeb8 bd2fbec0 ffffffff 00000000
>be40: 00000000 bdbe1540 00000001 bd954608 00000001 00000fff bd2fa000 bda547c8
>be60: 00000000 00000001 76f25000 00000000 00000000 00001000 76f24000 00000000
>be80: 80097780 00000000 00000000 00001000 bd2fbf78 bda54780 bda0dc00 00020000
>bea0: bd2fbf44 bd2fbeb0 800abf60 800741cc 00000000 00000000 76f24000 00001000
>bec0: 00000001 bda54780 00000000 00000000 00000000 bda0dc00 00000000 00000000
>bee0: 00000000 00000000 00000000 00000000 00001000 00000000 00001000 00000000
>bf00: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
>bf20: bda54780 76f24000 bd2fbf78 76f24000 00000000 00001000 bd2fbf74 bd2fbf48
>bf40: 800ac69c 800abeec 00800007 00000022 00000000 00000000 bda54780 76f24000
>bf60: 00000000 00001000 bd2fbfa4 bd2fbf78 800acd84 800ac608 00000000 00000000
>bf80: 017f7278 76ec7c58 00000000 00000003 8000e604 bd2fa000 00000000 bd2fbfa8
>bfa0: 8000e480 800acd4c 017f7278 76ec7c58 00000003 76f24000 00001000 00000000
>bfc0: 017f7278 76ec7c58 00000000 00000003 7eac3ad0 7eac3ad4 76f29000 00000000
>bfe0: 00000000 7eac3a64 76e389cf 76e6f21c 400e0010 00000003 00000000 00000000
>Backtrace: 
>[<800e826c>] (do_mpage_readpage+0x0/0x888) from [<800e8bc8>] (mpage_readpages+0xd4/0x130)
>[<800e8af4>] (mpage_readpages+0x0/0x130) from [<8011a030>] (ext3_readpages+0x24/0x28)
>[<8011a00c>] (ext3_readpages+0x0/0x28) from [<8007dd28>] (__do_page_cache_readahead+0x1f0/0x2d8)
>[<8007db38>] (__do_page_cache_readahead+0x0/0x2d8) from [<8007e0e0>] (ondemand_readahead+0x128/0x238)
>[<8007dfb8>] (ondemand_readahead+0x0/0x238) from [<8007e3b8>] (page_cache_sync_readahead+0x4c/0x6c)
>[<8007e36c>] (page_cache_sync_readahead+0x0/0x6c) from [<8007471c>] (generic_file_aio_read+0x55c/0x7c0)
> r4:bd53cd54
>[<800741c0>] (generic_file_aio_read+0x0/0x7c0) from [<800abf60>] (do_sync_read+0x80/0xa8)
>[<800abee0>] (do_sync_read+0x0/0xa8) from [<800ac69c>] (vfs_read+0xa0/0x148)
> r9:00001000 r8:00000000 r7:76f24000 r6:bd2fbf78 r5:76f24000
>r4:bda54780
>[<800ac5fc>] (vfs_read+0x0/0x148) from [<800acd84>] (SyS_read+0x44/0x80)
> r9:00001000 r8:00000000 r7:76f24000 r6:bda54780 r5:00000000
>r4:00000000
>[<800acd40>] (SyS_read+0x0/0x80) from [<8000e480>] (ret_fast_syscall+0x0/0x30)
> r9:bd2fa000 r8:8000e604 r7:00000003 r6:00000000 r5:76ec7c58
>r4:017f7278
>Code: e0854184 e51b0084 e14424d8 e51b40a0 (e1c420f0) 
>---[ end trace e23d6b4d1dcd7a83 ]---
>------------[ cut here ]------------
>WARNING: CPU: 0 PID: 731 at /home/jef/kernel/kernel/exit.c:703 do_exit+0x54/0x900()
>Modules linked in: arc4 p54usb p54common crc_ccitt fbcon bitblit mac80211 softcursor font cfg80211 dove_drm tda998x drm_kms_helper drm clk_si5351 snd_soc_simple_dt_card snd_soc_spdif_tx mv_cesa snd_soc_kirkwood
>CPU: 0 PID: 731 Comm: usb-db Tainted: G      D      3.11.0-rc3-00004-g36f571e-dirty #1
>Backtrace: 
>[<800112c4>] (dump_backtrace+0x0/0x110) from [<800114dc>] (show_stack+0x18/0x1c)
> r6:000002bf r5:00000009 r4:00000000 r3:00000000
>[<800114c4>] (show_stack+0x0/0x1c) from [<803a25b0>] (dump_stack+0x24/0x28)
>[<803a258c>] (dump_stack+0x0/0x28) from [<8001ad28>] (warn_slowpath_common+0x74/0x8c)
>[<8001acb4>] (warn_slowpath_common+0x0/0x8c) from [<8001ade4>] (warn_slowpath_null+0x24/0x2c)
> r8:00000811 r7:bd2fa000 r6:80439cc4 r5:0000000b r4:804cb598
>[<8001adc0>] (warn_slowpath_null+0x0/0x2c) from [<8001f248>] (do_exit+0x54/0x900)
>[<8001f1f4>] (do_exit+0x0/0x900) from [<80011664>] (die+0x184/0x238)
> r7:bd2fa000
>[<800114e0>] (die+0x0/0x238) from [<803a07dc>] (__do_kernel_fault.part.10+0x6c/0x7c)
>[<803a0770>] (__do_kernel_fault.part.10+0x0/0x7c) from [<8001420c>] (do_sect_fault+0x0/0x18)
> r7:bdbe1540 r3:bd2fbc28
>[<8001417c>] (do_bad_area+0x0/0x90) from [<80015d10>] (do_alignment+0xd0/0x844)
> r7:00000003 r6:800e89c0 r5:804ec85c r4:bd2fbc28
>[<80015c40>] (do_alignment+0x0/0x844) from [<80008460>] (do_DataAbort+0x40/0xa0)
>[<80008420>] (do_DataAbort+0x0/0xa0) from [<80011fb8>] (__dabt_svc+0x38/0x60)
>Exception stack(0xbd2fbc28 to 0xbd2fbc70)
>bc20:                   bd2fbc9c 00000000 00000003 00001000 00000003 bd2fbc70
>bc40: 800e8ca4 00000001 00000004 00000000 00000003 bd2fbc9c bd2fbcc8 bd2fbc74
>bc60: 800e05e4 800e89c0 600e0013 ffffffff
> r8:00000004 r7:bd2fbc5c r6:ffffffff r5:600e0013 r4:800e89c0
>[<800e826c>] (do_mpage_readpage+0x0/0x888) from [<800e8bc8>] (mpage_readpages+0xd4/0x130)
>[<800e8af4>] (mpage_readpages+0x0/0x130) from [<8011a030>] (ext3_readpages+0x24/0x28)
>[<8011a00c>] (ext3_readpages+0x0/0x28) from [<8007dd28>] (__do_page_cache_readahead+0x1f0/0x2d8)
>[<8007db38>] (__do_page_cache_readahead+0x0/0x2d8) from [<8007e0e0>] (ondemand_readahead+0x128/0x238)
>[<8007dfb8>] (ondemand_readahead+0x0/0x238) from [<8007e3b8>] (page_cache_sync_readahead+0x4c/0x6c)
>[<8007e36c>] (page_cache_sync_readahead+0x0/0x6c) from [<8007471c>] (generic_file_aio_read+0x55c/0x7c0)
> r4:bd53cd54
>[<800741c0>] (generic_file_aio_read+0x0/0x7c0) from [<800abf60>] (do_sync_read+0x80/0xa8)
>[<800abee0>] (do_sync_read+0x0/0xa8) from [<800ac69c>] (vfs_read+0xa0/0x148)
> r9:00001000 r8:00000000 r7:76f24000 r6:bd2fbf78 r5:76f24000
>r4:bda54780
>[<800ac5fc>] (vfs_read+0x0/0x148) from [<800acd84>] (SyS_read+0x44/0x80)
> r9:00001000 r8:00000000 r7:76f24000 r6:bda54780 r5:00000000
>r4:00000000
>[<800acd40>] (SyS_read+0x0/0x80) from [<8000e480>] (ret_fast_syscall+0x0/0x30)
> r9:bd2fa000 r8:8000e604 r7:00000003 r6:00000000 r5:76ec7c58
>r4:017f7278
>---[ end trace e23d6b4d1dcd7a84 ]---
>EXT3-fs (sda7): using internal journal
>IPv6: ADDRCONF(NETDEV_UP): wlan1: link is not ready
>wlan1: authenticate with 00:24:d4:9c:29:68
>wlan1: send auth to 00:24:d4:9c:29:68 (try 1/3)
>wlan1: authenticated
>p54usb 2-1.4.2:1.0 wlan1: disabling HT/VHT due to WEP/TKIP use
>wlan1: associate with 00:24:d4:9c:29:68 (try 1/3)
>wlan1: RX AssocResp from 00:24:d4:9c:29:68 (capab=0x411 status=0 aid=1)
>IPv6: ADDRCONF(NETDEV_CHANGE): wlan1: link becomes ready
>wlan1: associated
>
>-- 
>Ken ar c'henta?	|	      ** Breizh ha Linux atav! **
>Jef		|		http://moinejf.free.fr/
>--
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo at vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/