Hi,
Yes, according to the spec, the MP tables can be ANYWHERE in RAM, even where
the loader loads the OS. But since in practice no one ever makes an OS
relocatable, there is an understanding that between 1MB to 16MB (if
available) will not be touched by the BIOS. This is actually because
Windows loads at 1MB too.
Best Wishes,
Lyle
++++++++++++++++++++++++++++++++++++++
Systems Programmer, Compaq Corporation
(Not speaking for Compaq)
>"Anywhere in RAM"--to include where we load the kernel by default? If this
>is the case, not only does the bootloader need to scan and avoid, but
>setup.S needs to be made relocatable--to include the "empty" zero page.
>
>After settling these issues, it should be relatively easy for the memory
>initialization code to avoid these tables. Give us a hook, and we can
>reserve them.
>
>Linus, I'm not certain that a bios would return the area reserved, as
>reserved regions are designated eternally. If these tables can be
>overwritten once read, they would be AddressRangeACPI - like. Unless these
>tables ARE to be held reserved forever, which would explain why there is no
>AddressRangeSMPTable type in the ACPI standard.
>
>Nathan
>
>
>http://www.teleport.com/~acpi/DOWNLOADS/ACPIspec10b.pdf
>
>
>
>
>
> > -----Original Message-----
> > From: Lyle Coder [mailto:x_coder@hotmail.com]
> >
> > 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 Mar 07 2000 - 21:00:13 EST