aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorIngo Molnar <mingo@elte.hu>2008-09-16 09:58:02 +0200
committerIngo Molnar <mingo@elte.hu>2008-09-16 09:58:02 +0200
commit1e22436eba84edfec9c25e5a25d09062c4f91ca9 (patch)
treeb667c5955656e3939d2bbcd0fb32f26c44e1b63c
parent5649b7c30316a51792808422ac03ee825d26aa5e (diff)
x86: reserve low 64K on AMI and Phoenix BIOS boxen
there's multiple reports about suspend/resume related low memory corruption in this bugzilla: http://bugzilla.kernel.org/show_bug.cgi?id=11237 the common pattern is that the corruption is caused by the BIOS, and that it affects some portion of the first 64K of physical RAM. So add a DMI quirk This will waste 64K RAM on 'good' systems too, but without knowing the exact nature of this BIOS memory corruption this is the safest approach. This might as well solve a wide range of suspend/resume breakages under Linux. Signed-off-by: Ingo Molnar <mingo@elte.hu>
-rw-r--r--arch/x86/kernel/setup.c11
1 files changed, 9 insertions, 2 deletions
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 3109ca37a67..33719544a22 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -732,10 +732,10 @@ void start_periodic_check_for_corruption(void)
static int __init dmi_low_memory_corruption(const struct dmi_system_id *d)
{
printk(KERN_NOTICE
- "%s detected: BIOS corrupts 0xc000, working it around.\n",
+ "%s detected: BIOS may corrupt low RAM, working it around.\n",
d->ident);
- reserve_early(0xc000, 0xc400, "BIOS quirk");
+ reserve_early(0x0, 0x10000, "BIOS quirk");
return 0;
}
@@ -749,6 +749,13 @@ static struct dmi_system_id __initdata bad_bios_dmi_table[] = {
DMI_MATCH(DMI_BIOS_VENDOR, "American Megatrends Inc."),
},
},
+ {
+ .callback = dmi_low_memory_corruption,
+ .ident = "Phoenix BIOS",
+ .matches = {
+ DMI_MATCH(DMI_BIOS_VENDOR, "Phoenix Technologies, LTD"),
+ },
+ },
{}
};