aboutsummaryrefslogtreecommitdiff
path: root/include/asm-i386/e820.h
AgeCommit message (Collapse)Author
2007-07-29Replace CONFIG_SOFTWARE_SUSPEND with CONFIG_HIBERNATIONRafael J. Wysocki
Replace CONFIG_SOFTWARE_SUSPEND with CONFIG_HIBERNATION to avoid confusion (among other things, with CONFIG_SUSPEND introduced in the next patch). Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-07-21i386: do not restore reserved memory after hibernationRafael J. Wysocki
On some systems the ACPI NVS area is located in the first 1 MB of RAM and it is overwritten by the i386 code during the restore after hibernation. This confuses the ACPI platform firmware that doesn't update the AC adapter status appropriately as a result (http://bugzilla.kernel.org/show_bug.cgi?id=7995). The solution is to register the reserved memory in the first 1 MB as 'nosave', so that swsusp doesn't touch it during the restore. Also, this has been done on x86_64 for a long time now, so this patch makes the i386 restore code behave like the x86_64 one. [akpm@linux-foundation.org: build fix] Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Acked-by: Pavel Machek <pavel@ucw.cz> Cc: David Rientjes <rientjes@google.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-07-12Make definitions for struct e820entry and struct e820map consistentH. Peter Anvin
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>
2007-05-02[PATCH] x86: fix amd64-agp aperture validationJan Beulich
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>
2006-12-22[PATCH] compile error of register_memory()Yasunori Goto
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>
2006-12-07[PATCH] i386: Move memory map printing and other code to e820.cbibo,mao
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(-)
2006-12-07[PATCH] i386: Move e820/efi memmap walking code to e820.cbibo,mao
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(-)
2006-12-07[PATCH] i386: Move find_max_pfn function to e820.cbibo,mao
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>
2006-09-26[PATCH] x86: Remove incorrect comment about ACPI e820 entriesAndi Kleen
They cannot be actually freed because the FACS table has a shared-with-the-BIOS lock. Signed-off-by: Andi Kleen <ak@suse.de>
2006-04-09[PATCH] x86_64: Introduce e820_all_mappedArjan van de Ven
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>
2005-05-01[PATCH] Increase number of e820 entries hard limit from 32 to 128Venkatesh Pallipadi
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>
2005-04-16Linux-2.6.12-rc2Linus Torvalds
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!