diff options
| -rw-r--r-- | ChangeLog | 14 | ||||
| -rw-r--r-- | DEVELOPMENT | 10 | ||||
| -rw-r--r-- | i386/i386at/model_dep.c | 5 | ||||
| -rw-r--r-- | i386/intel/pmap.c | 9 |
4 files changed, 35 insertions, 3 deletions
@@ -1,3 +1,17 @@ +2006-05-08 Thomas Schwinge <tschwinge@gnu.org> + + * DEVELOPMENT: Document Samuel's patch. + +2006-05-08 Samuel Thibault <samuel.thibault@ens-lyon.org> + + * i386/i386at/model_dep.c (mem_size_init): Limit memory to what can + actually be used (minus a little extra for virtual mappings). + + * i386/intel/pmap.c (pmap_bootstrap): Extend the virtual mapping area + according to memory size for at least being able to manage it. But + look out for wrap and limit it to kernel adresses. Remove duplicate + computing. + 2006-04-27 Richard Braun <syn@hurdfr.org> Manuel Menal <mmenal@hurdfr.org> diff --git a/DEVELOPMENT b/DEVELOPMENT index 9a13217..e596276 100644 --- a/DEVELOPMENT +++ b/DEVELOPMENT @@ -13,6 +13,14 @@ within the native Mach NE2000 NIC device driver, see Support for NORMA was removed on 2006-03-20. <URL:http://lists.gnu.org/archive/html/bug-hurd/2006-03/msg00007.html>. - Be sure to check the ChangeLog and have a look at the repository at that tag's state if you want to work on those parts of GNU Mach. + + +Starting with the application of the patch from +<URL:http://savannah.gnu.org/bugs/index.php?func=detailitem&item_id=7118>, +GNU Mach's usage of the machine's memory equipment is currently forced to +be somewhere below 1 GiB, to make GNU Mach work at all on systems with +such enlarged RAM installations. This is--of course--not optimal. See +the calculation of and with `kernel_virtual_end' and `morevm' in +i386/intel/pmap.c and `phys_last_addr' in i386/i386at/model_dep.c. diff --git a/i386/i386at/model_dep.c b/i386/i386at/model_dep.c index 8975805..362ba7f 100644 --- a/i386/i386at/model_dep.c +++ b/i386/i386at/model_dep.c @@ -207,6 +207,11 @@ mem_size_init() printf("AT386 boot: physical memory from 0x%x to 0x%x\n", phys_first_addr, phys_last_addr); + /* Reserve 1/16 of the memory address space for virtual mappings. + * Yes, this loses memory. Blame i386. */ + if (phys_last_addr > (VM_MAX_KERNEL_ADDRESS / 16) * 15) + phys_last_addr = (VM_MAX_KERNEL_ADDRESS / 16) * 15; + phys_first_addr = round_page(phys_first_addr); phys_last_addr = trunc_page(phys_last_addr); } diff --git a/i386/intel/pmap.c b/i386/intel/pmap.c index fc56e87..540070b 100644 --- a/i386/intel/pmap.c +++ b/i386/intel/pmap.c @@ -627,7 +627,12 @@ void pmap_bootstrap() * and extends to a stupid arbitrary limit beyond that. */ kernel_virtual_start = phys_last_addr; - kernel_virtual_end = phys_last_addr + morevm; + kernel_virtual_end = phys_last_addr + morevm + + (phys_last_addr - phys_first_addr) / 15; + + if (kernel_virtual_end < phys_last_addr + || kernel_virtual_end > VM_MAX_KERNEL_ADDRESS) + kernel_virtual_end = VM_MAX_KERNEL_ADDRESS; /* * Allocate and clear a kernel page directory. @@ -656,7 +661,7 @@ void pmap_bootstrap() * to allocate new kernel page tables later. * XX fix this */ - for (va = phys_first_addr; va < phys_last_addr + morevm; ) + for (va = phys_first_addr; va < kernel_virtual_end; ) { pt_entry_t *pde = kernel_page_dir + lin2pdenum(kvtolin(va)); pt_entry_t *ptable = (pt_entry_t*)pmap_grab_page(); |