Messages in this thread | | | From | nathan.zook@amd ... | Subject | RE: 2.3.4[67] does not boot with PAE36 | Date | Fri, 25 Feb 2000 14:28:43 -0600 |
| |
"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
- 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/
| |