| Age | Commit message (Collapse) | Author |
|---|
|
Make definitions for struct e820entry and struct e820map
consistent between i386 and x86-64.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Under CONFIG_DISCONTIGMEM, assuming that a !pfn_valid() implies all
subsequent pfn-s are also invalid is wrong. Thus replace this by
explicitly checking against the E820 map.
AK: make e820 on x86-64 not initdata
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Signed-off-by: Andi Kleen <ak@suse.de>
Acked-by: Mark Langsdorf <mark.langsdorf@amd.com>
|
|
register_memory() becomes double definition in 2.6.20-rc1. It is defined
in arch/i386/kernel/setup.c as static definition in 2.6.19. But it is
moved to arch/i386/kernel/e820.c in 2.6.20-rc1. And same name function is
defined in driver/base/memory.c too. So, it becomes cause of compile error
of duplicate definition if memory hotplug option is on.
Signed-off-by: Yasunori Goto <y-goto@jp.fujitsu.com>
Cc: Andi Kleen <ak@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
This patch moves e820 memory map print and memmap boot param
parsing function from setup.c to e820.c, also adds limit_regions
and print_memory_map declaration in header file.
Signed-off-by: bibo,mao <bibo.mao@intel.com>
Signed-off-by: Andi Kleen <ak@suse.de>
arch/i386/kernel/e820.c | 152 +++++++++++++++++++++++++++
arch/i386/kernel/setup.c | 158 ---------------------------------
include/asm-i386/e820.h | 2
arch/i386/kernel/e820.c | 152 ++++++++++++++++++++++++++++++++++++++++++++++
arch/i386/kernel/setup.c | 153 -----------------------------------------------
include/asm-i386/e820.h | 2
3 files changed, 155 insertions(+), 152 deletions(-)
|
|
This patch moves e820/efi memmap table walking function from
setup.c to e820.c, also this patch adds extern declaration in
header file.
Signed-off-by: bibo,mao <bibo.mao@intel.com>
Signed-off-by: Andi Kleen <ak@suse.de>
arch/i386/kernel/e820.c | 115 +++++++++++++++++++++++++++++++++
arch/i386/kernel/setup.c | 118 -----------------------------------
include/asm-i386/e820.h | 2
arch/i386/kernel/e820.c | 115 +++++++++++++++++++++++++++++++++++++++++++++
arch/i386/kernel/setup.c | 118 -----------------------------------------------
include/asm-i386/e820.h | 2
3 files changed, 117 insertions(+), 118 deletions(-)
|
|
Move more code from setup.c into e820.c
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Andi Kleen <ak@suse.de>
|
|
They cannot be actually freed because the FACS table has a
shared-with-the-BIOS lock.
Signed-off-by: Andi Kleen <ak@suse.de>
|
|
Introduce a e820_all_mapped() function which checks if the entire range
<start,end> is mapped with type.
This is done by moving the local start variable to the end of each
known-good region; if at the end of the function the start address is
still before end, there must be a part that's not of the correct type;
otherwise it's a good region.
Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
The specifications that talk about E820 map doesn't have an upper limit on
the number of e820 entries. But, today's kernel has a hard limit of 32.
With increase in memory size, we are seeing the number of E820 entries
reaching close to 32. Patch below bumps the number upto 128.
The patch changes the location of EDDBUF in zero-page (as it comes after E820).
As, EDDBUF is not used by boot loaders, this patch should not have any effect
on bootloader-setup code interface.
Patch covers both i386 and x86-64.
Tested on:
* grub booting bzImage
* lilo booting bzImage with EDID info enabled
* pxeboot of bzImage
Side-effect:
bss increases by ~ 2K and init.data increases by ~7.5K
on all systems, due to increase in size of static arrays.
Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.
Let it rip!
|
