Date: Fri, 25 Feb 2000 11:13:12 PST
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Linus,
The actual MP table which is pointed to by the floating point structure CAN
actually be anywhere in the RAM. Only the floating pointer is in the places
you mentioned. The correct approach may be to scan the tables in the boot
loader.
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
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
-
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/
This archive was generated by hypermail 2b29 : Tue Feb 29 2000 - 21:00:13 EST