lkml.org 
[lkml]   [2008]   [Apr]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [bug] SLUB + mm/slab.c boot crash in -rc9

* Christoph Lameter <clameter@sgi.com> wrote:

> On Tue, 15 Apr 2008, Linus Torvalds wrote:
>
> > On Tue, 15 Apr 2008, Ingo Molnar wrote:
> > >
> > > btw., now with a second full day spent on this regression, i have
> > > figured out a workaround the hard way: increasing SECTION_SIZE_BITS in
> > > include/asm-x86/sparsemem.h from 26 to 27 makes it go away.
> >
> > Interesting.
>
> Hmmmm. SECTION_SIZE_BITS == 26 means SECTIONS_SHIFT == 6. Increasing
> SECTION_SIZE_BITS to 27 reduces SECTION_SHIFT to 5. Thereby the number
> of sparsemem sections (NR_MEM_SECTIONS) is reduced to half (64 to 32).

yes, as i said in this thread already earlier today, the sparse chunking
goes from 64MB to 128MB. (and hence, by virtue of !PAE having a 4GB
physical address space, the # of sparse sections goes from 64 to 32 -
you can see the full sparse sections printout in my latest crashlog in
my previous mail, including the NR_MEM_SECTIONS printout.)

Pretty please, could you pay more than cursory attention to this bug i
already spent two full days on and which is blocking the v2.6.25
release?

Your commits are all over the place in this code, and you are one of the
maintainers as well. We've got 5000 lines of flux in mm/* in v2.6.25.
I'm just guessing my way around, but right now my impression is that the
current early memory setup code is unrobust, over-complex, occasionally
butt-ugly to read code in high need of cleanups, simplifications and
debug facilities, visibly plagued by hit-and-run changes with frequent
typos and everything else you normally dont want to see in the core
kernel. (Did i get your attention now? ;-)

Ingo


\
 
 \ /
  Last update: 2008-04-15 21:57    [from the cache]
©2003-2011 Jasper Spaans