ARM: Fix r7/r11 confusion when CONFIG_THUMB2_KERNEL=y
Subsystems (3)
PATCH 1/1 ARM: Fix r7/r11 confusion when CONFIG_THUMB2_KERNEL=y
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.
--- 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(-)
arch/arm/include/asm/stacktrace.h +4 -0
@@ -2,7 +2,11 @@#define __ASM_STACKTRACE_Hstruct stackframe { +#ifdef CONFIG_THUMB2_KERNEL +unsigned long r7; +#else unsigned long fp; +#endif unsigned long sp;unsigned long lr;unsigned long pc;
arch/arm/include/asm/thread_info.h +2 -0
@@ -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 *);
arch/arm/kernel/perf_event.c +4 -0
@@ -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;
arch/arm/kernel/process.c +4 -0
@@ -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);
arch/arm/kernel/time.c +4 -0
@@ -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;
arch/arm/kernel/unwind.c +26 -1
@@ -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
arch/arm/oprofile/common.c +4 -0
@@ -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;
Signature · 1 line
1.7.10.4
Hi Jed,
Quoted 13 lines · 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/Makefilein particular) is r11 on ARM and r7 on Thumb.Correspondingly,
arch/arm/include/uapi/arm/ptrace.hdefinesARM_fpto refer to r11, butarch/arm/kernel/unwind.cuses "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.
Quoted 8 lines
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
Quoted 1 line · Will Deacon
On Sat, Jul 13, 2013 at 04:18:20AM +0100, Jed Davis wrote:
[...]
Quoted 4 lines
Quoted 4 lines
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.
[...]
Quoted 4 lines
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
Hello Jed,
Thanks for the reply.
Quoted 13 lines · Jed Davis
Quoted 1 line · Will Deacon
On Sat, Jul 13, 2013 at 04:18:20AM +0100, Jed Davis wrote:
[...]
Quoted 4 lines
Quoted 4 lines
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.
[...]
Quoted 4 lines
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?
Quoted 8 lines
There is a real bug here, but my commit message wasn't very clear. This was breaking
PERF_COUNT_SW_CONTEXT_SWITCHESwithCONFIG_THUMB2_KERNEL=y(with my other recently posted patch applied), becausekernel/sched.cis built with -fno-omit-frame-pointer (which is wrong, but that's a problem for another patch) and so __schedule's EHABI entry uses0x97(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__schedulehappens 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
Quoted 5 lines · Will Deacon
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
Quoted 31 lines · Will Deacon
Hello Jed,
Thanks for the reply.
Quoted 13 lines · Jed Davis
Quoted 1 line · Will Deacon
On Sat, Jul 13, 2013 at 04:18:20AM +0100, Jed Davis wrote:
[...]
Quoted 4 lines
Quoted 4 lines
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.
[...]
Quoted 4 lines
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?
Quoted 8 lines
There is a real bug here, but my commit message wasn't very clear. This was breaking
PERF_COUNT_SW_CONTEXT_SWITCHESwithCONFIG_THUMB2_KERNEL=y(with my other recently posted patch applied), becausekernel/sched.cis built with -fno-omit-frame-pointer (which is wrong, but that's a problem for another patch) and so __schedule's EHABI entry uses0x97(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__schedulehappens 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:
Quoted 8 lines
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
Quoted 5 lines · Dave Martin
Quoted 4 lines · Will Deacon
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:
Quoted 8 lines
Quoted 8 lines
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?
Quoted 4 lines
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?
[...]
Quoted 6 lines
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"?
Quoted 2 lines
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
Quoted 29 lines · Jed Davis
Quoted 5 lines · Dave Martin
Quoted 4 lines · Will Deacon
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:
Quoted 8 lines
Quoted 8 lines
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 withCONFIG_FRAME_POINTER, but "APCS variants that require a frame pointer register are obsolete.")So... why not make
pt_regsand stackframe the same, and avoid the translations entirely?Quoted 4 lines
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?
Quoted 5 lines
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.cdoesn'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.
Quoted 10 lines
[...]
Quoted 6 lines
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.
Quoted 5 lines
Quoted 3 lines
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/armfinds 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]
Quoted 3 lines · On Tue, 30 Jul 2013 10:25:18 +0100 Dave Martin <[email protected]> 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?
Signature · 2 lines
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]
Quoted 8 lines · Jean-Francois Moine
Quoted 3 lines · On Tue, 30 Jul 2013 10:25:18 +0100 Dave Martin <[email protected]> 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?
Quoted 1 line
Did anybody succeed with clang?
Hmm, I've no idea. Is this possible?
Cheers
---Dave
Quoted 9 lines
Signature · 8 lines
-- 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]
Quoted 11 lines · On Tue, 30 Jul 2013 10:44:57 +0100 Dave Martin <[email protected]> wrote:
Quoted 8 lines · Jean-Francois Moine
Quoted 3 lines · On Tue, 30 Jul 2013 10:25:18 +0100 Dave Martin <[email protected]> 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.
Quoted 3 lines
Quoted 1 line
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 ]---
Signature · 2 lines
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]
Quoted 21 lines · Jean-Francois Moine
Quoted 11 lines · On Tue, 30 Jul 2013 10:44:57 +0100 Dave Martin <[email protected]> wrote:
Quoted 8 lines · Jean-Francois Moine
Quoted 3 lines · On Tue, 30 Jul 2013 10:25:18 +0100 Dave Martin <[email protected]> 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.
Quoted 6 lines
Quoted 3 lines
Quoted 1 line
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...
Quoted 3 lines
Otherwise, replacing gcc with clang in the main kernel
Makefilestops 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
Quoted 80 lines
------------------ 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: 600f0113sp :
bcf49c34ip :bcf49c88fp :bcf49c5c
r10: 00000003 r9 : 00000000 r8 : 00000043
r7 : 00000001 r6 :800e3f54r5 :bcf49c30r4 : 00000003 r3 : 00020000 r2 : 00000042 r1 : 00000000 r0 :bcf49c5c
Flags: nZCv IRQs on FIQs on ModeSVC_32ISA ARM Segment user
Control:10c5387dTable:3cf74019DAC: 00000015 Process iceweasel (pid: 2426, stack limit =0xbcf48240)Stack: (0xbcf49c34 to 0xbcf4a000)9c20: 00000020
bcf49d2400200200
9c40: 00100100bd580d940000000080de4260bcf49cf4bcf49c60800e3e78800e35289c60:bcf49c88bcf49c7c801164cc000000c1804d660c801164ccda0716b400000042 9c80: 00000000 00000000 00000020 0000000080de4260000000c100287ab600000000 9ca0: 00020000 80073500bd402c80804d667000100100 00000002 002002008039a2ac9cc0:804d660c00000002804d6ca080113f8400000020 00000020 00000042000000b49ce0: 00000000 00000020bcf49d04bcf49cf880113fa8800e3db0bcf49d6cbcf49d089d00:80079ef480113f90bcf00c0000000018bd580d9400000020bd580d98bcf49d249d20: 0000000180de439480de425491827364bcf49d30bcf49d30bcf49d38bcf49d389d40: 00000052 00000052bcf00c00bd580d94bd580d94bcf49df000000000bcf6c0d09d60:bcf49d84bcf49d708007a60080079d10000000087319d000bcf49ddcbcf49d889d80:800719f48007a5dc80076670 80075448 00000001000000c1bcf00c4800000002 9da0:3c5e818f00000000bcf48008bd580ce080013e40bcf6c0d0bdbc2e4000000000 9dc0:7319d00000000028 00000000bcf75cc0bcf49e2cbcf49de08008b0ac8007163c9de0:bdb247a800000000 00000000 00000200 00000028 000000527319d00000000000 9e00:8007b8d0bcf6c0d07319d0007319d000bdbc2e40bcf6c0d000000028 00000000 9e20:bcf49e7cbcf49e308008e5848008b04800000052 00000028 00000000000000b19e40:da538506000000b1804bb71800000004804bb708bcf74000000003987319d0009e60:bdbc2e40bcf6c0d000000028bcf75cc0bcf49eb4bcf49e808008ed148008e51c9e80:bcf75cc000000028da53850600000017bcf49fb0bdbc2e40bd92b7007319d2889ea0:bcf4803800000028bcf49efcbcf49eb880013c388008ec800000b53300000000 9ec0:0000b53300000200 00000000bdbc2e7800000000 0000001780013a64804b76f49ee0:7319d288bcf49fb000000ea100000000bcf49facbcf49f008000846080013a709f00:bcf00c0000000001000b45c0804bc488bcf48000000000000000001d00000000 9f20: 00000001 73098000bcf49f54804bc488bcf49f54bcf49f408006a2848006b5249f40:804bb900bcf4802800000000 000000000000001d00000000bcf49f7cbcf49f689f60: 800224248006db1800020000804c3c90bcf49f9cbcf49f808000ec2c800223a49f80: 0000062175253ff0200f003075238ed2200f0030ffffffff 0000000000000ea19fa0: 00000000bcf49fb08000e1188000842c7319d2ec7319d2927ee06c987319d2889fc0:7ee06c9873098000 00000000 0000000000000ea100000ea10000000073223be09fe0:752811fc7ee06b887523bd7575238ed2200f0030ffffffff 00000000 00000000Backtrace: [<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:
7319d2ec7319d2927ee06c987319d288
9fc0:7ee06c9873098000 00000000 0000000000000ea100000ea10000000073223be09fe0:752811fc7ee06b887523bd7575238ed2200f0030ffffffff
r8:00000ea1 r7:00000000 r6:ffffffff r5:200f0030 r4:75238ed2Code: e0854184 e51b0084 e14424d8 e51b40a0 (e1c420f0) ---[ end trace 838796f906351fb0 ]---Signature · 7 lines
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]
In reply to Jean-Francois MoineQuoted 8 lines · Jean-Francois Moine
Quoted 6 lines · On Tue, 30 Jul 2013 10:44:57 +0100 Dave Martin <[email protected]> wrote:
Quoted 5 lines · Jean-Francois Moine
Quoted 3 lines · On Tue, 30 Jul 2013 10:25:18 +0100 Dave Martin <[email protected]> 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.
[...]
Quoted 6 lines
Quoted 3 lines
Quoted 1 line
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
Signature · 3 lines
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]
In reply to Jean-Francois MoineQuoted 1 line · Jean-Francois Moine
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]
Quoted 6 lines · On Tue, 30 Jul 2013 10:49:04 +0100 Will Deacon <[email protected]> wrote:
Quoted 1 line · Jean-Francois Moine
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: 262144free_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:135sched_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 drivermv_xor f1060800.dma-engine: Marvell shared XOR drivermv_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 drivermv_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 loadedsata_mv f10a0000.sata: version 1.28sata_mv f10a0000.sata: slots 32 ports 1
scsi0 : sata_mv
ata1: SATA max UDMA/133 irq 62
libphy: orion_mdio_bus: probedmv643xx_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 foundmv643xx_eth_port mv643xx_eth_port.0 eth0: port 0 with MAC address 00:50:43:b6:3b:10ehci_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
Signature · 2 lines
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]
[Adding Gregory, as this is a Marvell CPU]
Quoted 2 lines · Jean-Francois Moine
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
Quoted 340 lines
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 at3e000000
Memory policy: ECC disabled, Data cache writeback
On node 0 totalpages: 262144free_area_init_node: node 0, pgdat804ebd2c,node_mem_map8075b000
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:135sched_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 for0x803a6620-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 clocksourceorion_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 drivermv_xorf1060800.dma-engine: Marvell shared XOR drivermv_xorf1060800.dma-engine: Marvell XOR: ( xor cpy )mv_xorf1060800.dma-engine: Marvell XOR: ( xor cpy )mv_xorf1060900.dma-engine: Marvell shared XOR drivermv_xorf1060900.dma-engine: Marvell XOR: ( xor cpy )mv_xorf1060900.dma-engine: Marvell XOR: ( xor cpy )
Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled
f1012000.serial: ttyS0 at MMIO0xf1012000(irq = 7) is a 16550A
console [ttyS0] enabled
brd: module loadedsata_mvf10a0000.sata: version 1.28sata_mvf10a0000.sata: slots 32 ports 1
scsi0 :sata_mv
ata1: SATA max UDMA/133 irq 62
libphy:orion_mdio_bus: probedmv643xx_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 foundmv643xx_eth_portmv643xx_eth_port.0 eth0: port 0 with MAC address 00:50:43:b6:3b:10ehci_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 mem0xf1050000
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 mem0xf1051000
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_mtureduced 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: 600e0013sp :
bd2fbc74ip :bd2fbcc8fp :bd2fbc9c
r10: 00000003 r9 : 00000000 r8 : 00000004
r7 : 00000001 r6 :800e8ca4r5 :bd2fbc70r4 : 00000003 r3 : 00001000 r2 : 00000003 r1 : 00000000 r0 :bd2fbc9c
Flags: nZCv IRQs on FIQs on ModeSVC_32ISA ARM Segment user
Control:10c5387dTable:3d374019DAC: 00000015 Process usb-db (pid: 731, stack limit =0xbd2fa240)Stack: (0xbd2fbc74 to 0xbd2fc000)bc60: 00000001
bd2fbd6400200200
bc80: 00100100bd53cd54bd9f134080eed380bd2fbd34bd2fbca0800e8bc8800e8278
bca0:bd2fbcc8bd2fbcbc8011c554000000c1804ebd2c8011c55400000002 00000003
bcc0:0028de8700000000 00000000bd2fbcd880eed380803a2f540028df4000000000
bce0: 00001000 00000000bd402ac08003b810bd2fbcf0bd2fbcf0bd53ccb4bd2fbd7c
bd00:bd53ccbc00000002bd2fbd248011a00c00000004 00000004 000000000000007a
bd20: 00000000 00000004bd2fbd44bd2fbd388011a030800e8b00bd2fbdacbd2fbd48
bd40:8007dd288011a018bda5478000000001bd53cd5400000004bd53cd58bd2fbd64
bd60:800c23bcbd2fbd64bd2fbd6491827364bd8d5de8bd8d5de8bd2fbd78bd2fbd78
bd80:800add50bd53cd54bda54780bda547c800000000 00000020 00000003bd53cd54
bda0:bd2fbdecbd2fbdb08007e0e08007db4400000003bd11e470bd95462cbdbe1540
bdc0:bd2fbddcbd53cd5400000000 00000000bd53cc9800000001 00000000bda54780
bde0:bd2fbe0cbd2fbdf08007e3b88007dfc400000000 00000001 00000000bd53cd54
be00:bd2fbeacbd2fbe108007471c8007e37800000001bd954b78bd9545f8bd9545f8
be20:76f2400076f2500000000001 00080001bd2fbeb8bd2fbec0ffffffff 00000000
be40: 00000000bdbe154000000001bd9546080000000100000fffbd2fa000bda547c8
be60: 00000000 0000000176f2500000000000 00000000 0000100076f2400000000000
be80: 80097780 00000000 00000000 00001000bd2fbf78bda54780bda0dc0000020000
bea0:bd2fbf44bd2fbeb0800abf60800741cc00000000 0000000076f2400000001000
bec0: 00000001bda5478000000000 00000000 00000000bda0dc0000000000 00000000
bee0: 00000000 00000000 00000000 00000000 00001000 00000000 00001000 00000000
bf00: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
bf20:bda5478076f24000bd2fbf7876f2400000000000 00001000bd2fbf74bd2fbf48
bf40:800ac69c800abeec00800007 00000022 00000000 00000000bda5478076f24000
bf60: 00000000 00001000bd2fbfa4bd2fbf78800acd84800ac60800000000 00000000
bf80:017f727876ec7c5800000000 000000038000e604bd2fa00000000000bd2fbfa8
bfa0:8000e480800acd4c017f727876ec7c580000000376f2400000001000 00000000
bfc0:017f727876ec7c5800000000 000000037eac3ad07eac3ad476f2900000000000
bfe0: 000000007eac3a6476e389cf76e6f21c400e001000000003 00000000 00000000Backtrace: [<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:76f24000r4: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:017f7278Code: 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:
bd2fbc9c00000000 00000003 00001000 00000003bd2fbc70
bc40:800e8ca400000001 00000004 00000000 00000003bd2fbc9cbd2fbcc8bd2fbc74
bc60:800e05e4800e89c0600e0013ffffffff
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]
In reply to Jean-Francois MoineQuoted 4 lines · Jean-Francois Moine
Quoted 1 line · On Tue, 30 Jul 2013 10:49:04 +0100 Will Deacon <[email protected]> wrote:
On Tue, Jul 30, 2013 at 10:38:53AM +0100, Jean-Francois Moine wrote:
Quoted 8 lines
Quoted 5 lines
Quoted 1 line
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
Quoted 345 lines
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 at3e000000
Memory policy: ECC disabled, Data cache writeback
On node 0 totalpages: 262144free_area_init_node: node 0, pgdat804ebd2c,node_mem_map8075b000
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:135sched_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 for0x803a6620-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 clocksourceorion_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 drivermv_xorf1060800.dma-engine: Marvell shared XOR drivermv_xorf1060800.dma-engine: Marvell XOR: ( xor cpy )mv_xorf1060800.dma-engine: Marvell XOR: ( xor cpy )mv_xorf1060900.dma-engine: Marvell shared XOR drivermv_xorf1060900.dma-engine: Marvell XOR: ( xor cpy )mv_xorf1060900.dma-engine: Marvell XOR: ( xor cpy )
Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled
f1012000.serial: ttyS0 at MMIO0xf1012000(irq = 7) is a 16550A
console [ttyS0] enabled
brd: module loadedsata_mvf10a0000.sata: version 1.28sata_mvf10a0000.sata: slots 32 ports 1
scsi0 :sata_mv
ata1: SATA max UDMA/133 irq 62
libphy:orion_mdio_bus: probedmv643xx_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 foundmv643xx_eth_portmv643xx_eth_port.0 eth0: port 0 with MAC address 00:50:43:b6:3b:10ehci_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 mem0xf1050000
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 mem0xf1051000
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_mtureduced 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: 600e0013sp :
bd2fbc74ip :bd2fbcc8fp :bd2fbc9c
r10: 00000003 r9 : 00000000 r8 : 00000004
r7 : 00000001 r6 :800e8ca4r5 :bd2fbc70r4 : 00000003 r3 : 00001000 r2 : 00000003 r1 : 00000000 r0 :bd2fbc9c
Flags: nZCv IRQs on FIQs on ModeSVC_32ISA ARM Segment user
Control:10c5387dTable:3d374019DAC: 00000015 Process usb-db (pid: 731, stack limit =0xbd2fa240)Stack: (0xbd2fbc74 to 0xbd2fc000)bc60: 00000001
bd2fbd6400200200
bc80: 00100100bd53cd54bd9f134080eed380bd2fbd34bd2fbca0800e8bc8800e8278
bca0:bd2fbcc8bd2fbcbc8011c554000000c1804ebd2c8011c55400000002 00000003
bcc0:0028de8700000000 00000000bd2fbcd880eed380803a2f540028df4000000000
bce0: 00001000 00000000bd402ac08003b810bd2fbcf0bd2fbcf0bd53ccb4bd2fbd7c
bd00:bd53ccbc00000002bd2fbd248011a00c00000004 00000004 000000000000007a
bd20: 00000000 00000004bd2fbd44bd2fbd388011a030800e8b00bd2fbdacbd2fbd48
bd40:8007dd288011a018bda5478000000001bd53cd5400000004bd53cd58bd2fbd64
bd60:800c23bcbd2fbd64bd2fbd6491827364bd8d5de8bd8d5de8bd2fbd78bd2fbd78
bd80:800add50bd53cd54bda54780bda547c800000000 00000020 00000003bd53cd54
bda0:bd2fbdecbd2fbdb08007e0e08007db4400000003bd11e470bd95462cbdbe1540
bdc0:bd2fbddcbd53cd5400000000 00000000bd53cc9800000001 00000000bda54780
bde0:bd2fbe0cbd2fbdf08007e3b88007dfc400000000 00000001 00000000bd53cd54
be00:bd2fbeacbd2fbe108007471c8007e37800000001bd954b78bd9545f8bd9545f8
be20:76f2400076f2500000000001 00080001bd2fbeb8bd2fbec0ffffffff 00000000
be40: 00000000bdbe154000000001bd9546080000000100000fffbd2fa000bda547c8
be60: 00000000 0000000176f2500000000000 00000000 0000100076f2400000000000
be80: 80097780 00000000 00000000 00001000bd2fbf78bda54780bda0dc0000020000
bea0:bd2fbf44bd2fbeb0800abf60800741cc00000000 0000000076f2400000001000
bec0: 00000001bda5478000000000 00000000 00000000bda0dc0000000000 00000000
bee0: 00000000 00000000 00000000 00000000 00001000 00000000 00001000 00000000
bf00: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
bf20:bda5478076f24000bd2fbf7876f2400000000000 00001000bd2fbf74bd2fbf48
bf40:800ac69c800abeec00800007 00000022 00000000 00000000bda5478076f24000
bf60: 00000000 00001000bd2fbfa4bd2fbf78800acd84800ac60800000000 00000000
bf80:017f727876ec7c5800000000 000000038000e604bd2fa00000000000bd2fbfa8
bfa0:8000e480800acd4c017f727876ec7c580000000376f2400000001000 00000000
bfc0:017f727876ec7c5800000000 000000037eac3ad07eac3ad476f2900000000000
bfe0: 000000007eac3a6476e389cf76e6f21c400e001000000003 00000000 00000000Backtrace: [<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:017f7278Code: 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:
bd2fbc9c00000000 00000003 00001000 00000003bd2fbc70
bc40:800e8ca400000001 00000004 00000000 00000003bd2fbc9cbd2fbcc8bd2fbc74
bc60:800e05e4800e89c0600e0013ffffffff
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: associatedSignature · 7 lines
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/