Re: Latest Linus tree oopses on Nehalem box

[Ingo Molnar <mingo@elte.hu>]

* Jes Sorensen <jes@sgi.com> wrote:

> Hi,
>
> I am seeing this one with the latest Linus' git tree as of this 
> morning on a Nehalem box. Using the defconfig + megaraid driver.
>
> Not sure if this is already fixed, or if someone already knows 
> whats wrong? Smells like a yet another BIOS bug - yes the BIOS on 
> this thing is rubbish.

my Nehalem (16 logical cpus) boots fine:

 aldebaran:~> uname -a
 Linux aldebaran 2.6.31-rc6-tip-01272-g9919e28-dirty #1518 SMP Fri 
 Aug 21 11:13:12 CEST 2009 x86_64 x86_64 x86_64 GNU/Linux

> [    6.664800] RIP: 0010:[<ffffffff810391e7>]  [<ffffffff810391e7>]  
> find_busiest_group+0x620/0x6fd 

Nothing similar is open at the moment.

There's only one open .31 scheduler regression bug at the moment: a 
rare division by zero bug that sometimes crashes boxes - the bigger 
the box the likelier the crash.

Your crash looks to be one of:

 1) a genuine scheduler bug tickled on your new hardware. Needs to 
    be bisected/debugged/fixed.

 2) a BIOS bug passing crappy ACPI tables which cause us to create a
    buggy sched-domains tree or so. We do treat ACPI data as 
    external untrusted data and try to use it in sane ways only, but 
    such bugs have happened in the past and could happen again.

The scheduler has sanity check for the sched-domains arch setup: if 
you enable CONFIG_SCHED_DEBUG=y then sched_domain_debug() will 
become noisy in your syslog if there's something wrong (but wont 
stop the bootup so you have to actively check your syslog).

Might be useful to see your full crashlog, if you are allowed to 
post that, plus your kernel .config would be useful to know too. 
Plus would be useful to know whether this is a regression relative 
to .30 or a yet unfixed bug triggering on your class of hardware.

Thanks,

	Ingo