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

    * Pekka Enberg <penberg@cs.helsinki.fi> wrote:

    > On Tue, Apr 15, 2008 at 9:25 AM, Ingo Molnar <mingo@elte.hu> wrote:
    > > so it's probably the first few page allocations (setup_cpu_cache())
    > > going wrong already - suggesting a some fundamental borkage in SLAB?
    >
    > I think it's still pointing to the page allocator and/or setting up
    > the zonelists...

    i did a .config bisection and it pinpointed CONFIG_SPARSEMEM=y as the
    culprit. Changing it to FLATMEM gives a correctly booting system.

    if you look at the good versus bad bootup log:

    http://redhat.com/~mingo/misc/log-Tue_Apr_15_07_24_59_CEST_2008.good
    http://redhat.com/~mingo/misc/log-Tue_Apr_15_07_24_59_CEST_2008.bad

    (both SLUB) you'll see that the zone layout provided by the architecture
    code is _exactly_ the same and looks sane as well. So this is not an
    architecture zone layout bug, this is probably sparsemem setup (and/or
    the page allocator) getting confused by something.

    why are there no good debug logs possible in this area? To debug such
    bugs we'd need an early dump of the precise layout of all memory maps,
    what points where, how large it is, where it is allocated - and then
    compare it with how the rest of the system is layed out - looking at
    possible overlaps or other bugs. This 8-way box is a pain to debug on,
    it takes a long time to boot it up, etc. etc.

    Ingo


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