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

quoted text
> 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
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/