kernel.git/arch/x86/boot/memory.c, branch linux-2.6.28.y

x86, setup: mark %esi as clobbered in E820 BIOS call

2009-05-02T17:56:40Z

upstream commit: 01522df346f846906eaf6ca57148641476209909 Jordan Hargrave diagnosed a BIOS clobbering %esi in the E820 call. That particular BIOS has been fixed, but there is a possibility that this is responsible for other occasional reports of early boot failure, and it does not hurt to add %esi to the clobbers. -stable candidate patch. Cc: Justin Forbes Signed-off-by: Michael K Johnson Signed-off-by: H. Peter Anvin Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman

x86: fix build warnings in real mode code

2008-08-18T07:20:14Z

This recent patch commit c3965bd15118742d72b4bc1a290d37b3f081eb98 Author: Paul Jackson Date: Wed May 14 08:15:34 2008 -0700 x86 boot: proper use of ARRAY_SIZE instead of repeated E820MAX constant caused these new warnings during a normal build: In file included from linux-2.6/arch/x86/boot/memory.c:17: linux-2.6/include/linux/log2.h: In function '__ilog2_u32': linux-2.6/include/linux/log2.h:34: warning: implicit declaration of function 'fls' linux-2.6/include/linux/log2.h: In function '__ilog2_u64': linux-2.6/include/linux/log2.h:42: warning: implicit declaration of function 'fls64' linux-2.6/include/linux/log2.h: In function '__roundup_pow_of_two ': linux-2.6/include/linux/log2.h:63: warning: implicit declaration of function 'fls_long' I tried to fix them in log2.h, but it's difficult because the real mode environment is completely different from a normal kernel environment. Instead define an own ARRAY_SIZE macro in boot.h, similar to the other private macros there. Signed-off-by: Andi Kleen Signed-off-by: Ingo Molnar

x86 boot: proper use of ARRAY_SIZE instead of repeated E820MAX constant

2008-05-25T08:55:11Z

This patch is motivated by a subsequent patch which will allow for more memory map entries on EFI supported systems than can be passed via the x86 legacy BIOS E820 interface. The legacy interface is limited to E820MAX == 128 memory entries, and that "E820MAX" manifest constant was used as the size for several arrays and loops over those arrays. The primary change in this patch is to change code loop sizes over those arrays from using the constant E820MAX, to using the ARRAY_SIZE() macro evaluated for the array being looped. That way, a subsequent patch can change the size of some of these arrays, without breaking this code. This patch also adds a parameter to the sanitize_e820_map() routine, which had an implicit size for the array passed it of E820MAX entries. This new parameter explicitly passes the size of said array. Once again, this will allow a subsequent patch to change that array size for some calls to sanitize_e820_map() without breaking the code. As part of enhancing the sanitize_e820_map() interface this way, I further combined the unnecessarily distinct x86_32 and x86_64 declarations for this routine into a single, commonly used, declaration. This patch in itself should make no difference to the resulting kernel binary. [ mingo@elte.hu: merged to -tip ] Signed-off-by: Paul Jackson Signed-off-by: Ingo Molnar

x86: remove pointless comments

2008-04-19T17:19:54Z

Remove old comments that include the old arch/i386 directory. Signed-off-by: WANG Cong Acked-by: H. Peter Anvin Signed-off-by: Ingo Molnar Signed-off-by: Thomas Gleixner

x86: handle BIOSes which terminate e820 with CF=1 and no SMAP

2008-02-26T11:55:52Z

The proper way to terminate the e820 chain is with %ebx == 0 on the last legitimate memory block. However, several BIOSes don't do that and instead return error (CF = 1) when trying to read off the end of the list. For this error return, %eax doesn't necessarily return the SMAP signature -- correctly so, since %ah should contain an error code in this case. To deal with some particularly broken BIOSes, we clear the entire e820 chain if the SMAP signature is missing in the middle, indicating a plain insane e820 implementation. However, we need to make the test for CF = 1 before the SMAP check. This fixes at least one HP laptop (nc6400) for which none of the memory-probing methods (e820, e801, 88) functioned fully according to spec. Signed-off-by: H. Peter Anvin Signed-off-by: Ingo Molnar Signed-off-by: Thomas Gleixner

i386: move boot

2007-10-11T09:16:45Z

Signed-off-by: Thomas Gleixner Signed-off-by: Ingo Molnar Signed-off-by: Thomas Gleixner Signed-off-by: Ingo Molnar Signed-off-by: Thomas Gleixner Signed-off-by: Ingo Molnar