Commit Graph

10 Commits

Author SHA1 Message Date
H. Peter Anvin
bca23dba76 x86, setup: revert ACPI 3 E820 extended attributes support
Remove ACPI 3 E820 extended memory attributes support.  At least one
vendor actively set all the flags to zero, but left ECX on return at
24.  This bug may be present in other BIOSes.

The breakage functionally means the ACPI 3 flags are probably
completely useless, and that no OS any time soon is going to rely on
their existence.  Therefore, drop support completely.  We may want to
revisit this question in the future, if we find ourselves actually
needing the flags.

This reverts all or part of the following checkins:

     cd670599b7
     c549e71d07

However, retain the part from the latter commit that copies e820 into
a temporary buffer; that is an unrelated BIOS workaround.  Put in a
comment to explain that part.

See https://bugzilla.redhat.com/show_bug.cgi?id=499396 for some
additional information.

[ Impact: detect all memory on affected machines ]

Reported-by: Thomas J. Baker <tjb@unh.edu>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Acked-by: Len Brown <len.brown@intel.com>
Cc: Chuck Ebbert <cebbert@redhat.com>
Cc: Kyle McMartin <kmcmartin@redhat.com>
Cc: Matt Domsch <matt_domsch@dell.com>
2009-05-22 11:14:02 -07:00
H. Peter Anvin
cd670599b7 x86, setup: guard against pre-ACPI 3 e820 code not updating %ecx
Impact: BIOS bug safety

For pre-ACPI 3 BIOSes, pre-initialize the end of the e820 buffer just
in case the BIOS returns an unchanged %ecx but without actually
touching the ACPI 3 extended flags field.

Signed-off-by: H. Peter Anvin <hpa@zytor.com>
2009-04-01 11:35:00 -07:00
H. Peter Anvin
c549e71d07 x86, setup: ACPI 3, BIOS workaround for E820-probing code
Impact: ACPI 3 spec compliance, BIOS bug workaround

The ACPI 3 spec added another field to the E820 buffer -- which is
backwards incompatible, since it contains a validity bit.
Furthermore, there has been at least one report of a BIOS which
assumes that the buffer it is pointed at is the same buffer as for the
previous E820 call.  Therefore, read the data into a temporary buffer
and copy the standard part of it if and only if the valid bit is set.

Signed-off-by: H. Peter Anvin <hpa@zytor.com>
2009-03-28 18:20:07 -07:00
H. Peter Anvin
32ec7fd08b x86, setup: preemptively save/restore edi and ebp around INT 15 E820
Impact: BIOS bugproofing

Since there are BIOSes known to clobber %ebx and %esi for INT 15 E820,
assume there is something out there clobbering %edi and/or %ebp too,
and don't wait for it to fail.

Signed-off-by: H. Peter Anvin <hpa@zytor.com>
2009-03-28 18:18:20 -07:00
Michael K. Johnson
01522df346 x86, setup: mark %esi as clobbered in E820 BIOS call
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 <jmforbes@linuxtx.org>
Signed-off-by: Michael K Johnson <johnsonm@rpath.com>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Cc: stable@kernel.org
2009-03-28 12:45:39 -07:00
Andi Kleen
1b72691ce3 x86: fix build warnings in real mode code
This recent patch

commit c3965bd151
Author: Paul Jackson <pj@sgi.com>
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 <ak@linux.intel.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-08-18 09:20:14 +02:00
Paul Jackson
c3965bd151 x86 boot: proper use of ARRAY_SIZE instead of repeated E820MAX constant
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 <pj@sgi.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-05-25 10:55:11 +02:00
WANG Cong
cf9b111c17 x86: remove pointless comments
Remove old comments that include the old arch/i386 directory.

Signed-off-by: WANG Cong <xiyou.wangcong@gmail.com>
Acked-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2008-04-19 19:19:54 +02:00
H. Peter Anvin
829157be59 x86: handle BIOSes which terminate e820 with CF=1 and no SMAP
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 <hpa@zytor.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2008-02-26 12:55:52 +01:00
Thomas Gleixner
96ae6ea0be i386: move boot
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2007-10-11 11:16:45 +02:00