On Tue, Jan 06, 2015 at 03:08:18PM -0800, Fengguang Wu wrote:
> [ 0.000000] Calgary: detecting Calgary via BIOS EBDA area
> [ 0.000000] Calgary: Unable to locate Rio Grande table in EBDA - bailing!
> [ 0.000000] Memory: 293508K/327280K available (9326K kernel code, 3522K
> rwdata, 2656K rodata, 1108K init, 5048K bss, 33772K reserved, 0K cma-reserved)
> [ 0.000000] BUG: unable to handle kernel NULL pointer dereference at
> 0000000000000068
> [ 0.000000] IP: [<ffffffff880bebe6>] do_set_cpus_allowed+0x18/0x51
> [ 0.000000] PGD 0
> [ 0.000000] Oops: 0000 [#1] SMP
> [ 0.000000] Modules linked in:
> [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 3.19.0-rc2-gbb82635 #49
> [ 0.000000] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
> [ 0.000000] task: ffffffff88e14e80 ti: ffffffff88e00000 task.ti:
> ffffffff88e00000
> [ 0.000000] RIP: 0010:[<ffffffff880bebe6>] [<ffffffff880bebe6>]
> do_set_cpus_allowed+0x18/0x51
> [ 0.000000] RSP: 0000:ffffffff88e03ec8 EFLAGS: 00010002
> [ 0.000000] RAX: 0000000000000000 RBX: ffffffff88e14e80 RCX:
> 0000000000000001
> [ 0.000000] RDX: 0000000000000000 RSI: ffffffff88a146c8 RDI:
> ffffffff88e14e80
> [ 0.000000] RBP: ffffffff88e03ed8 R08: ffffffff88e15000 R09:
> 0000000000000000
> [ 0.000000] R10: ffffffff8916a4e8 R11: 0000000000000000 R12:
> ffffffff88a146c8
> [ 0.000000] R13: 0000000000000008 R14: 0000000000000002 R15:
> 0000000000000000
> [ 0.000000] FS: 0000000000000000(0000) GS:ffff880013a00000(0000)
> knlGS:0000000000000000
> [ 0.000000] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> [ 0.000000] CR2: 0000000000000068 CR3: 0000000008e0e000 CR4:
> 00000000000006b0
> [ 0.000000] Stack:
> [ 0.000000] ffffffff88e14e80 ffff880013a11a00 ffffffff88e03f18
> ffffffff880bf136
> [ 0.000000] 00000000ffffffff ffff880013a11a00 0000000000000008
> 0000000000000008
> [ 0.000000] 0000000000011a00 0000000000014500 ffffffff88e03f48
> ffffffff891a8c10
> [ 0.000000] Call Trace:
> [ 0.000000] [<ffffffff880bf136>] init_idle+0x88/0x142
> [ 0.000000] [<ffffffff891a8c10>] sched_init+0x2c5/0x333
> [ 0.000000] [<ffffffff891861db>] start_kernel+0x32d/0x7f5
> [ 0.000000] [<ffffffff89185120>] ? early_idt_handlers+0x120/0x120
> [ 0.000000] [<ffffffff8918559c>] x86_64_start_reservations+0x46/0x4f
> [ 0.000000] [<ffffffff891856e7>] x86_64_start_kernel+0x142/0x158
> [ 0.000000] Code: 31 db 48 83 c4 18 89 d8 5b 41 5c 41 5d 41 5e 41 5f 5d c3
> 55 48 ff 05 7a 5b 25 01 48 89 e5 41 54 49 89 f4 53 48 89 fb 48 8b 47 60 <48>
> 8b 40 68 48 85 c0 74 09 48 ff 05 62 5b 25 01 ff d0 49 8b 04
> [ 0.000000] RIP [<ffffffff880bebe6>] do_set_cpus_allowed+0x18/0x51
> [ 0.000000] RSP <ffffffff88e03ec8>
> [ 0.000000] CR2: 0000000000000068
> [ 0.000000] ---[ end trace cfb024ef67550cb2 ]---
> [ 0.000000] Kernel panic - not syncing: Fatal exception
The below delta seems to fix this...
---
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -7254,6 +7254,11 @@ void __init sched_init(void)
enter_lazy_tlb(&init_mm, current);
/*
+ * During early bootup we pretend to be a normal task:
+ */
+ current->sched_class = &fair_sched_class;
+
+ /*
* Make us the idle thread. Technically, schedule() should not be
* called from this thread, however somewhere below it might be,
* but because we are the idle thread, we just pick up running again
@@ -7263,11 +7268,6 @@ void __init sched_init(void)
calc_load_update = jiffies + LOAD_FREQ;
- /*
- * During early bootup we pretend to be a normal task:
- */
- current->sched_class = &fair_sched_class;
-
#ifdef CONFIG_SMP
zalloc_cpumask_var(&sched_domains_tmpmask, GFP_NOWAIT);
/* May be allocated at isolcpus cmdline parse time */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
