On Thu, 2013-11-21 at 00:09 -0500, Nicolas Pitre wrote:
I've been banging my head on this one for quite a while now. The problem is that there is very little debug out put available. Could you see if you get the same?
I get the same, with the same kernel version. If I disable cpufreq configs, then it get another (possibly different) crash, which has a backtrace.
Unable to handle kernel NULL pointer dereference at virtual address 00000010 pgd = ee4a8000 [00000010] *pgd=bfe9e831 Internal error: Oops: 17 [#1] SMP THUMB2 Modules linked in: CPU: 0 PID: 2112 Comm: test Tainted: G W 3.12.0+ #5 task: ef3e4180 ti: ee78e000 task.ti: ee78e000 PC is at trigger_load_balance+0xaa/0x1fc LR is at __lock_acquire+0x2b3/0x850 pc : [<c0042ae2>] lr : [<c004b8f3>] psr: 800f01b3 sp : ee78fc70 ip : ef3e4180 fp : 00000001 r10: c145b300 r9 : ffff924d r8 : c0679438 r7 : c145e180 r6 : c06877a0 r5 : 00000000 r4 : 00000000 r3 : eea23600 r2 : 00000004 r1 : 0000000e r0 : 00000001 Flags: Nzcv IRQs off FIQs on Mode SVC_32 ISA Thumb Segment user Control: 50c5387d Table: ae4a806a DAC: 00000015 Process test (pid: 2112, stack limit = 0xee78e240) [...] (trigger_load_balance+0xaa/0x1fc) from [<c00255c5>] (update_process_times+0x3d/0x48) (update_process_times+0x3d/0x48) from [<c0061589>] (tick_sched_handle+0x35/0x40) (tick_sched_handle+0x35/0x40) from [<c0061799>] (tick_sched_timer+0x31/0x54) (tick_sched_timer+0x31/0x54) from [<c00346d7>] (__run_hrtimer+0x4f/0x12c) (__run_hrtimer+0x4f/0x12c) from [<c0034f7f>] (hrtimer_interrupt+0xdb/0x210) (hrtimer_interrupt+0xdb/0x210) from [<c0327d11>] (arch_timer_handler_virt+0x25/0x28) (arch_timer_handler_virt+0x25/0x28) from [<c0054c83>] (handle_percpu_devid_irq+0x4f/0xb0) (handle_percpu_devid_irq+0x4f/0xb0) from [<c0052719>] (generic_handle_irq+0x19/0x24) (generic_handle_irq+0x19/0x24) from [<c000d78d>] (handle_IRQ+0x29/0x68) (handle_IRQ+0x29/0x68) from [<c0008453>] (gic_handle_irq+0x27/0x50) (gic_handle_irq+0x27/0x50) from [<c00103ff>] (__irq_svc+0x3f/0x64)
I've attached my kernel config and full serial log. I've also attached a disassembly of trigger_load_balance.
I tried running the same kernel again and got a different error:
Alignment trap: not handling instruction e8521f00 at [<c004294e>]
and that instruction is a "ldrex r1, [r2]" in set_cpu_sd_state_idle.
This whole thing looks a bit nasty.
I'm busy with other things, so won't be investigating further today...