[lkml]   [2000]   [Feb]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: 2.3.4[67] does not boot with PAE36

    On Fri, 25 Feb 2000, Ingo Molnar wrote:
    > i'd love to do this as well, but there is one big problem: the SMP-config
    > parsing code has to run ASAP, before any memory is destroyed. It can be
    > anywhere in the BIOS sections of the lower 1MB RAM. So allocating and
    > initializing page tables will cause problems. We could allocate page
    > tables from above 1MB, but this is just yet another implicit 'reserve
    > memory' thing we tried to get rid of via bootmem :-)

    Sure. It needs to get solved, though, and for future systems we will
    simply have to initialize the page tables first: I already have intel
    engineers knocking on my door telling me that the systems they have in
    their labs can't do SMP because of this. Let's assume that they are on the
    market in another few months..

    Note that the SMP tables really should _not_ be in just any low memory
    area: if that were true then we'd have trashed them much earlier during
    the bootloader anyway. Currently the SMP tables should be either in the
    extended BIOS area (really low memory) or in the 640kB-1M region (or just
    below, in the "high BIOS area", which we should have full knowledge of
    from the e820 BIOS memory information)...

    In fact, right now we don't even search for it in any other areas than

    low 1kB (extended low BIOS area)
    1kB just under 640kB (extended high BIOS area)
    last 64kB of the first 1MB area (BIOS section)

    and sure, the physical hardware table can be anywhere (and this is the
    part that _will_ be in high high memory on newer boards), but it should
    still all be in reserved BIOS memory that we wouldn't touch anyway.

    So I think that the problem you refer to is the old problem of Linux not
    having the complete memory map, so Linux would always assume that memory
    up to the 640kB mark was usable. That is definitely not true, but that bug
    got fixed with the introduction of the e820 memory table parsing..

    > yep, i agree. I gave it a quick shot and we crash in smpboot.c line 864,
    > which crash can be explained because smp_boot_cpu_id is taken from the MP
    > config table.

    Not surprising. We probably have tons of small ordering assumptions that
    just never came up..


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:56    [W:0.022 / U:61.140 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site