Messages in this thread | | | Date | Fri, 25 Feb 2000 10:22:35 -0800 (PST) | From | Linus Torvalds <> | Subject | Re: 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..
Linus
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |