schedtune OOPS with "isolcpus=" kernel parameter |
|
Issue descriptionI'm testing the "isolcpus=" kernel parameter on kernel 4.4, and this triggers an OOPS in the schedtune code. e.g., with isolcpus=5: [ 0.389894] schedtune: init normalization constants... [ 0.395536] schedtune: CLUSTER[0-3] min_pwr: 0 max_pwr: 54 [ 0.402699] schedtune: CPU[0] min_pwr: 0 max_pwr: 206 [ 0.409861] schedtune: CPU[1] min_pwr: 0 max_pwr: 206 [ 0.417023] schedtune: CPU[2] min_pwr: 0 max_pwr: 206 [ 0.424185] schedtune: CPU[3] min_pwr: 0 max_pwr: 206 [ 0.431346] schedtune: CLUSTER[4] min_pwr: 0 max_pwr: 78 [ 0.438508] schedtune: CPU[4] min_pwr: 0 max_pwr: 78 [ 0.445674] Unable to handle kernel NULL pointer dereference at virtual address 00000010 [ 0.454550] pgd = ffffffc00120e000 [ 0.458279] [00000010] *pgd=0000000000221003, *pud=0000000000221003, *pmd=0000000000222003, *pte=00e80000fee00707 [ 0.469566] Internal error: Oops: 96000005 [#1] PREEMPT SMP [ 0.475673] Modules linked in: [ 0.479020] CPU: 3 PID: 1 Comm: swapper/0 Not tainted 4.4.35 #729 [ 0.485698] Hardware name: Google Kevin (DT) [ 0.490375] task: ffffffc0eefe0000 ti: ffffffc0eef7c000 task.ti: ffffffc0eef7c000 [ 0.498579] PC is at schedtune_init+0x218/0x3c4 [ 0.503543] LR is at schedtune_init+0x208/0x3c4 [ 0.508505] pc : [<ffffffc00026d278>] lr : [<ffffffc00026d268>] pstate: 60000045 [ 0.516613] sp : ffffffc0eef7fcd0 [ 0.520239] x29: ffffffc0eef7fcd0 x28: ffffffc00108dbb0 [ 0.526063] x27: ffffffc00108d000 x26: ffffffc0ef0f6620 [ 0.531887] x25: ffffffc00108d000 x24: ffffffc000be8c3e [ 0.537711] x23: ffffffc0ef103400 x22: ffffffc001150000 [ 0.543535] x21: ffffffc00106a480 x20: ffffffc000be8000 [ 0.549359] x19: ffffffc0ef0f6600 x18: 0000000000000005 [ 0.555181] x17: 0000000000000078 x16: 000000000000000e [ 0.561005] x15: 0000000000000007 x14: 0fffffffffffffff [ 0.566828] x13: 0000000000000030 x12: 0101010101010101 [ 0.572652] x11: 7f7f7f7f7f7f7f7f x10: 59ff5c335a544f42 [ 0.578475] x9 : ffffffffffffffff x8 : 202020203a727770 [ 0.584299] x7 : ffffffc0ef103c00 x6 : ffffffc001151bc9 [ 0.590123] x5 : ffffffc000a2c3f8 x4 : 0000000000000004 [ 0.595946] x3 : 0000000000000000 x2 : cb88537fdc8ba623 [ 0.601769] x1 : 0000000000000010 x0 : 0000000000000000 [ 0.607594] ... [ 1.940893] [ 1.942519] Process swapper/0 (pid: 1, stack limit = 0xffffffc0eef7c040) [ 1.949865] Stack: (0xffffffc0eef7fcd0 to 0xffffffc0eef80000) [ 1.956163] fcc0: ffffffc0eef7fd90 ffffffc000200ecc [ 1.964750] fce0: ffffffc00026d060 ffffffc0010977a0 ffffffc0ee70e280 ffffffc00108c000 [ 1.973337] fd00: ffffffc0010977a0 0000000000000000 ffffffc001001100 ffffffc000e00280 [ 1.981923] fd20: ffffffc001001080 ffffffc00114e000 0000000000000004 ffffffc0ef103c00 [ 1.990509] fd40: 0000000000000000 000000000000004e ffffffc00108c000 ffffffc00108e000 [ 1.999096] fd60: ffffffc0ee70e280 5b005d345b555043 ffffff005d005d34 0000000000000000 [ 2.007682] fd80: ffffffc001001100 cb88537fdc8ba623 ffffffc0eef7fe20 ffffffc000e00bac [ 2.016269] fda0: 00000000000000bf ffffffc000cddd10 ffffffc00114e000 0000000000000002 [ 2.024855] fdc0: ffffffc00108c000 ffffffc001001090 ffffffc001001100 ffffffc000e00200 [ 2.033442] fde0: ffffffc001001080 ffffffc00114e000 ffffffc000be6904 ffffffc000bf3722 [ 2.042028] fe00: ffffffc000a2c1b0 0000000000000000 0000000200000002 cb88537fdc8ba623 [ 2.050615] fe20: ffffffc0eef7fea0 ffffffc00091d620 ffffffc00114e000 ffffffc00114e000 [ 2.059201] fe40: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 2.067787] fe60: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 2.076373] fe80: 0000000000000000 ffffffc001061ff0 0000000000000000 cb88537fdc8ba623 [ 2.084960] fea0: 0000000000000000 ffffffc000203dd0 ffffffc00091d600 0000000000000000 [ 2.093545] fec0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 2.102131] fee0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 2.110717] ff00: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 2.119303] ff20: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 2.127890] ff40: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 2.136476] ff60: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 2.145061] ff80: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 2.153647] ffa0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 2.162233] ffc0: 0000000000000000 0000000000000005 0000000000000000 0000000000000000 [ 2.170820] ffe0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 2.179404] Call trace: [ 2.182079] [<ffffffc00026d278>] schedtune_init+0x218/0x3c4 [ 2.188188] [<ffffffc000200ecc>] do_one_initcall+0x190/0x1ac [ 2.194392] [<ffffffc000e00bac>] kernel_init_freeable+0x1d4/0x28c [ 2.201074] [<ffffffc00091d620>] kernel_init+0x20/0xe4 [ 2.206706] [<ffffffc000203dd0>] ret_from_fork+0x10/0x40 [ 2.212528] Code: f94037a7 f9401261 f94033a4 f94000e0 (f9400800) [ 2.219352] ---[ end trace 7ac8da580d667bb2 ]--- [ 2.224416] Kernel panic - not syncing: Fatal exception ... which comes down to: /mnt/host/source/src/third_party/kernel/v4.4/kernel/sched/tune.c: 869 BUG_ON(!cpumask_equal( 0xffffffc00026d270 <+528>: ldr x4, [x29,#96] 0xffffffc00026d274 <+532>: ldr x0, [x7] /mnt/host/source/src/third_party/kernel/v4.4/include/linux/bitmap.h: 259 return ! ((*src1 ^ *src2) & BITMAP_LAST_WORD_MASK(nbits)); 0xffffffc00026d278 <+536>: ldr x0, [x0,#16] 0xffffffc00026d27c <+540>: ldr x0, [x0,#32] 0xffffffc00026d280 <+544>: eor x0, x1, x0 0xffffffc00026d284 <+548>: and x0, x0, #0xff So, it looks like we're incorrectly dereferencing a NULL value returned from sched_group_cpus(sg) for the isolated CPU. Should schedtune even be looking at the isolated CPUs?
,
Jan 11 2017
yeah I can take a look later today, if you need to work around it, I would recommend just removing schedtune from the kernel config and go back to using the interactive governor |
|
►
Sign in to add a comment |
|
Comment 1 by briannorris@chromium.org
, Jan 11 2017Huh, so I know much about CPU clusters and schedtune, but it seems like the following hack works: diff --git a/kernel/sched/tune.c b/kernel/sched/tune.c index 71394c57d26e..ae0b77f9268b 100644 --- a/kernel/sched/tune.c +++ b/kernel/sched/tune.c @@ -866,7 +866,7 @@ schedtune_add_cluster_nrg( * Assume we have EM data only at the CPU and * the upper CLUSTER level */ - BUG_ON(!cpumask_equal( + BUG_ON(sd2->parent && !cpumask_equal( sched_group_cpus(sg), sched_group_cpus(sd2->parent->groups) )); It looks like it's possible for these domains to not have a parent? Like if I isolate CPU5 of a 4x2, then CPU4 doesn't have sd2->parent. If I isolate CPU4 and CPU5, then CPU{0,1,2,3} all don't have sd2->parent. e.g., for isolcpus=4,5 + some debugging info + the above diff: [ 0.380767] schedtune: init normalization constants... [ 0.386409] schedtune: CLUSTER[0] min_pwr: 0 max_pwr: 206 [ 0.393573] schedtune: CPU[0] min_pwr: 0 max_pwr: 206 [ 0.400735] No parent at domain for cpu 0; skipping [ 0.406086] schedtune: CLUSTER[1] min_pwr: 0 max_pwr: 206 [ 0.413247] schedtune: CPU[1] min_pwr: 0 max_pwr: 206 [ 0.420408] No parent at domain for cpu 1; skipping [ 0.425759] schedtune: CLUSTER[2] min_pwr: 0 max_pwr: 206 [ 0.432921] schedtune: CPU[2] min_pwr: 0 max_pwr: 206 [ 0.440081] No parent at domain for cpu 2; skipping [ 0.445432] schedtune: CLUSTER[3] min_pwr: 0 max_pwr: 206 [ 0.452594] schedtune: CPU[3] min_pwr: 0 max_pwr: 206 [ 0.459754] No parent at domain for cpu 3; skipping [ 0.465104] schedtune: SYSTEM min_pwr: 0 max_pwr: 1648 [ 0.472266] schedtune: using normalization constants mul: 1042467791 sh1: 1 sh2: 10 Maybe that BUG_ON() is just completely bogus? Anyway, I'm going to play around using isolcpus= with the above diff for debugging some other things, but it'd be nice to see this fixed properly. Sonny, will you be able to take this?