Messages in this thread | | | From | "Saxena, Sunil" <> | Subject | RE: 2.3.4[67] does not boot with PAE36 | Date | Fri, 25 Feb 2000 13:25:56 -0800 |
| |
Hi Linus, Ingo,
I believe we understand the issue and would love to hear your opinion on this:
Linux is not paying any attention to the memory descriptors of used and available memory. Hence, if the boot loader provided the information about the memory descriptors from the MPS table then we would not run into this problem. Based on the descriptors, paging init will be able to set up the needed 1:1 translations that would be needed to access MPS table etc. The MPS spec states:
The MPS floating point Structure could either be in EBDA or system base memory (minus 1K). Boot loader should be able to search and pass that inforamation to kernel. The MPS table by definition is either stored in non-reported RAM or with in the BIOS ROM (for the cases when the H/Wconfiguration is not changeble).
We would be happy to prototype a change and provide you a patch if you think this would solve both the problems.
Thanks Sunil
-----Original Message----- From: Ingo Molnar [mailto:mingo@chiara.csoma.elte.hu] Sent: Friday, February 25, 2000 8:13 AM To: Linus Torvalds Cc: Christoph Rohland; linux-kernel@vger.rutgers.edu Subject: Re: 2.3.4[67] does not boot with PAE36
On Thu, 24 Feb 2000, Linus Torvalds wrote:
> > (the bug was that we allocated and initialized secondary PAE page tables > > outside the 8MB initial virtual memory - bootmem_alloc_pages() prefers to > > return addresses above 16MB on x86.) > > Ingo, there are other problems with the "map only a limited part of the > physical memory" approach: the SMP tables are in high memory on newer > systems from intel etc. Instead of this patch, I'd much rather get a patch > that moves "paging_init()" from init/main.c into setup_arch().
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 :-)
> ("paging_init()" is really an arch-specific thing anyway: many > architectures do not need any page table setup at all due to having a 1:1 > hardware mapping for the kernel address space already, so this makes sense > from a bigger architectural standpoint too, I think).
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.
Ingo
- 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/
- 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/
| |