lkml.org 
[lkml]   [2009]   [Aug]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Latest Linus tree oopses on Nehalem box

* 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


\
 
 \ /
  Last update: 2009-08-21 13:51    [from the cache]
©2003-2011 Jasper Spaans