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

    * Linus Torvalds <torvalds@linux-foundation.org> wrote:

    > On Tue, 15 Apr 2008, Ingo Molnar wrote:
    > >
    > > debug output is:
    > >
    > > http://redhat.com/~mingo/misc/log-Thu_Apr_10_10_41_16_CEST_2008.bad.rc9
    > >
    > > so it's probably the first few page allocations (setup_cpu_cache())
    > > going wrong already - suggesting a some fundamental borkage in SLAB?
    >
    > Well, I think it suggests some fundamental borkage in the page
    > allocator.
    >
    > That first warn-on is from the "alloc_pages_node()" returning NULL at
    > bootup. Sure, it could be that the arguments are bogus, but that
    > sounds unlikely since none of that is dependent on any kconfig stuff.
    >
    > The fact that it happens with both SLUB/SLAB makes that even more
    > obvious.
    >
    > Now, you don't have fault injection on, so it can't be that, and your
    > debug entry for *z == NULL didn' trigger in alloc_pages, so it's no
    > that one either.
    >
    > However, if __alloc_pages() failed, I would have expected to see the
    > "memory allocation failed" printk. Why didn't it? Is
    > printk_ratelimit() broken at boot (last_msg start out as zero - maybe
    > i should start out as a negative number)?

    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. (i.e. we use
    section chunks of 128 MB instead of 64 MB before) I've given up on
    analyzing the crash site - it seems rather random and uninformative and
    just suggests page allocator borkage.

    So this seems like a general sparsemem borkage. PAE uses a shift of 30
    due to page->flags shortage (which masks this bug), 64-bit uses 27 which
    too probably masks this bug.

    Since this is a !NUMA config and !PAE as well, NODES_SHIFT is 0,
    ZONES_SHIFT is 2, so the theory of running out of bits in page->flags is
    wrong as well.

    I also tried a hack to double the size of all sparsemem mem_map
    allocations (on the theory of an overflow there) - but it didnt help.

    So i think we need to go down further into the page allocator. Perhaps
    the buddy bitmaps are wrongly sized somewhere. I'm grasping at straws.

    Btw., Mel Gorman has reproduced crashes with my bzImage on his box (and
    a hang with my config, using his build), so i think we can eliminate hw
    and build environment specialities as a cause.

    Ingo


    \
     
     \ /
      Last update: 2008-04-15 18:19    [W:4.117 / U:0.360 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site