Commit cb83b62 fails to boot with a divide by zero error.
Ingo, there is a breakage in the x86/master branch.
While testing some of our configurations, we found they would not boot. The following got things working:
kernel/sched/fair.c 2012-05-11 06:31:52.217156410 -0500 renamed from kernel/sched/fair.c 2012-05-11 06:29:44.000000000 -0500 +1 -1
@@ -3835,7 +3835,7 @@ static inline void update_sg_lb_stats(st } /* Adjust by relative CPU power of the group */ - sgs->avg_load = (sgs->group_load*SCHED_POWER_SCALE) / group->sgp->power; + sgs->avg_load = (sgs->group_load*SCHED_POWER_SCALE) / max(group->sgp->power, 1); /* * Consider the group unbalanced when the imbalance is larger
We found that reverting the commit:
cb83b62 (x86/sched/core) sched/numa: Rewrite the CONFIG_NUMA sched domain support
also got things working.
Thanks,
Robin Holt
Quoted 4 lines · Robin Holt
We found that reverting the commit:
cb83b62 (x86/sched/core) sched/numa: Rewrite theCONFIG_NUMAsched domain supportalso got things working.
there's a particularly stupid bug in that code
---
Subject: sched, numa: Fix the new NUMA topology bits
From: Peter Zijlstra <[email protected]>
Date: Fri May 11 00:56:20 CEST 2012
There's no need to convert a node number to a node number by pretending its a cpu number..
--- kernel/sched/core.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
kernel/sched/core.c +1 -2
@@ -6378,8 +6378,7 @@ static void sched_init_numa(void) sched_domains_numa_masks[i][j] = mask;for (k =0 ; k < nr_node_ids; k++) { -if (node_distance (cpu_to_node (j), k) > - sched_domains_numa_distance[i]) +if (node_distance (j, k) > sched_domains_numa_distance[i])continue ;cpumask_or (mask, mask,cpumask_of_node (k));
Quoted 8 lines · Peter Zijlstra
Quoted 4 lines · Robin Holt
We found that reverting the commit:
cb83b62 (x86/sched/core) sched/numa: Rewrite theCONFIG_NUMAsched domain supportalso got things working.
there's a particularly stupid bug in that code
Even with that applied, I still get the divide by zero.
Robin
Quoted 30 lines
---
Subject: sched, numa: Fix the new NUMA topology bits
From: Peter Zijlstra <[email protected]>
Date: Fri May 11 00:56:20 CEST 2012There's no need to convert a node number to a node number by pretending its a cpu number..
Reported-by Yinghai Lu <[email protected]>Reported-and-Tested-by Greg Pearson <[email protected]>Signed-off-by Peter Zijlstra <[email protected]>--- kernel/sched/core.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)kernel/sched/core.c +1
-2@@ -6378,8 +6378,7 @@ static void sched_init_numa(void) sched_domains_numa_masks[i][j] = mask;for (k =0 ; k < nr_node_ids; k++) { -if (node_distance (cpu_to_node (j), k) > - sched_domains_numa_distance[i]) +if (node_distance (j, k) > sched_domains_numa_distance[i])continue ;cpumask_or (mask, mask,cpumask_of_node (k));
Quoted 11 lines · Robin Holt
Quoted 8 lines · Peter Zijlstra
Quoted 4 lines · Robin Holt
We found that reverting the commit:
cb83b62 (x86/sched/core) sched/numa: Rewrite theCONFIG_NUMAsched domain supportalso got things working.
there's a particularly stupid bug in that code
Even with that applied, I still get the divide by zero.
Humm.. what kind of machine is this? And how far along does it get in booting? ->power isn't supposed to get to 0.
Quoted 7 lines · Peter Zijlstra
Quoted 6 lines · Robin Holt
Quoted 5 lines · Peter Zijlstra
Quoted 3 lines · Robin Holt
We found that reverting the commit:
cb83b62 (x86/sched/core) sched/numa: Rewrite theCONFIG_NUMAsched domain support
Quoted 8 lines
Quoted 5 lines
Quoted 3 lines
Quoted 1 line
also got things working.
there's a particularly stupid bug in that code
Even with that applied, I still get the divide by zero.
Humm.. what kind of machine is this? And how far along does it get in booting? ->power isn't supposed to get to 0.
It is a four blade (8 socket 80 core 160 hyper-thread machine) with 40 GB of RAM.
Looking at the earlier kernel messages, I am wondering if I don't have a BIOS that is giving me crud. I have messages about hyperthreads being on different nodes. That had not been happening in the past. I don't have access to the machine now, but the BIOS string that had printed out is from a developer's debug version.
When I get access to the machine again (likely not until Monday), I will flash a release BIOS and retest. Until then, please feel free to ignore me.
Thanks,
Robin
Quoted 3 lines · Robin Holt
It is a four blade (8 socket 80 core 160 hyper-thread machine) with 40 GB of RAM.
Ok, big but not ridiculously so.. I'll try and see if I can find anything.
Quoted 9 lines
Looking at the earlier kernel messages, I am wondering if I don't have a BIOS that is giving me crud. I have messages about hyperthreads being on different nodes. That had not been happening in the past. I don't have access to the machine now, but the BIOS string that had printed out is from a developer's debug version.
When I get access to the machine again (likely not until Monday), I will flash a release BIOS and retest. Until then, please feel free to ignore me.
No need, that's another (known) bug..
Quoted 27 lines · Robin Holt
Quoted 7 lines · Peter Zijlstra
Quoted 6 lines · Robin Holt
Quoted 5 lines · Peter Zijlstra
Quoted 3 lines · Robin Holt
We found that reverting the commit:
cb83b62 (x86/sched/core) sched/numa: Rewrite theCONFIG_NUMAsched domain supportQuoted 8 lines
Quoted 5 lines
Quoted 3 lines
Quoted 1 line
also got things working.
there's a particularly stupid bug in that code
Even with that applied, I still get the divide by zero.
Humm.. what kind of machine is this? And how far along does it get in booting? ->power isn't supposed to get to 0.
It is a four blade (8 socket 80 core 160 hyper-thread machine) with 40 GB of RAM.
Looking at the earlier kernel messages, I am wondering if I don't have a BIOS that is giving me crud. I have messages about hyperthreads being on different nodes. That had not been happening in the past. I don't have access to the machine now, but the BIOS string that had printed out is from a developer's debug version.
Quoted 3 lines
When I get access to the machine again (likely not until Monday), I will flash a release BIOS and retest. Until then, please feel free to ignore me.
Please don't re-flash the BIOS! We want to fix this bug - the kernel should never crash on whatever topology data the BIOS passes.
We can sanitize it or ignore it, but crashing is not an option. So lets figure this out, ok?
Thanks,
Ingo
Quoted 34 lines · Ingo Molnar
Quoted 27 lines · Robin Holt
Quoted 7 lines · Peter Zijlstra
Quoted 6 lines · Robin Holt
Quoted 5 lines · Peter Zijlstra
Quoted 3 lines · Robin Holt
We found that reverting the commit:
cb83b62 (x86/sched/core) sched/numa: Rewrite theCONFIG_NUMAsched domain supportQuoted 8 lines
Quoted 5 lines
Quoted 3 lines
Quoted 1 line
also got things working.
there's a particularly stupid bug in that code
Even with that applied, I still get the divide by zero.
Humm.. what kind of machine is this? And how far along does it get in booting? ->power isn't supposed to get to 0.
It is a four blade (8 socket 80 core 160 hyper-thread machine) with 40 GB of RAM.
Looking at the earlier kernel messages, I am wondering if I don't have a BIOS that is giving me crud. I have messages about hyperthreads being on different nodes. That had not been happening in the past. I don't have access to the machine now, but the BIOS string that had printed out is from a developer's debug version.
Quoted 3 lines
When I get access to the machine again (likely not until Monday), I will flash a release BIOS and retest. Until then, please feel free to ignore me.
Quoted 6 lines
Please don't re-flash the BIOS! We want to fix this bug - the kernel should never crash on whatever topology data the BIOS passes.
We can sanitize it or ignore it, but crashing is not an option. So lets figure this out, ok?
I have the old BIOS as well so I can flash back. Plus, I have the BIOS developer's description of his changes and he has saved his workarea. Toggling back and forth should not be a problem to help us determine the source and "correct" fix.
Robin