Messages in this thread |  | | | Date | Mon, 14 May 2012 07:40:05 -0500 | | From | Robin Holt <> | | Subject | Re: Commit cb83b62 fails to boot with a divide by zero error. |
| |
On Mon, May 14, 2012 at 12:48:29PM +0200, Ingo Molnar wrote: > > * Robin Holt <holt@sgi.com> wrote: > > > On Fri, May 11, 2012 at 05:36:13PM +0200, Peter Zijlstra wrote: > > > On Fri, 2012-05-11 at 10:05 -0500, Robin Holt wrote: > > > > On Fri, May 11, 2012 at 04:33:10PM +0200, Peter Zijlstra wrote: > > > > > On Fri, 2012-05-11 at 08:39 -0500, Robin Holt wrote: > > > > > > > > > > > We found that reverting the commit: > > > > > > cb83b62 (x86/sched/core) sched/numa: Rewrite the CONFIG_NUMA sched domain support > > > > > > > > > > > > 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. > > 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
|  |