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

    * Christoph Lameter <> 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

    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? ;-)


     \ /
      Last update: 2008-04-15 21:57    [W:0.043 / U:23.524 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site